What the Heck Is a Unified Namespace?

My job is to keep up with all the tools, technologies and strategies for implementing automation systems. That’s pretty broad but it’s a job that I like a lot.

I can honestly tell you that it’s harder now than it was 10 or 15 years ago. In the past, things were introduced at what now seems to be a leisurely pace. I could count one major, new introduction every year or so. Now there is something I haven’t heard of every day. Just today, I was introduced to Margo. That’s not the new barista at my coffee shop. It’s an architecture for coalescing data at the edge. Ugh!

I try to keep up on that stuff. Collecting data is what the RTA gateways do but this was something new to me. It took a while, but it looks to be a new architecture for standardizing the interface to manufacturing systems – probably the 15th one introduced this year.

Probably a year ago now, I started hearing more and more about the “Unified Namespace (UNS).” No idea what it was. Just like when I heard about Margo. I couldn’t tell you if it was some tool, a piece of software, a new IEC standard or someone’s implementation strategy. The strange thing, this happens sometimes, is that the more time I spent on it, the less I knew.

So, I started reading articles. I looked at YouTube. I checked automation.com and the confusion really set in. Then I figured it out. There really is no definition. It’s whatever you want it to be. Microsoft thinks it’s this or that. OPC UA has some other idea. Rockwell and Siemens are somewhere else entirely. I can tell you precisely what EtherNet/IP is. I can tell precisely what CESMII is, but UNS? No way. It was just a term with no real meat behind it. It’s strategy if you want it to be strategy. It’s a philosophy if you want that. Or it’s implementation if you want it to be that.

I came to the conclusion that it is a term devoid of any real standard meaning. It’s whatever you want it to be. Kudzai Manditereza in this blog has one definition for it. I have another in this article.

Let’s start with models. A lot of organizations, vendors and trade associations are all competing to develop standard models. Models are simply hierarchical structures that organize data in a way that makes sense and makes the data easy to use.

Models aren’t new. A long time ago when the CAN application layer DeviceNet, was introduced, it came with some standard “models” for things like drives, photoeyes and other pieces of factory floor equipment. That modeling was duplicated in EtherNet/IP. Those models were nothing more than the structure of the data passed in and out of a device, but they were a start.

In the newest adaptation of models, they can apply to a single entity like a scale or a valve or to the packaging section of a machine, a production line or a factory. CESMI is standardizing these models in cooperation with the OPC UA Foundation. User organizations are creating models too. Vendors are creating their own models and manufacturers are creating models specific to their production environment.

I don’t like standard models. Manufacturing isn’t the IT world where we have a bunch of PCs, routers and switches and all these devices follow a consistent architecture because the IT system is pretty much identical from company to company. For example, a standard router model that is accessed over SNMP makes sense because router functionality doesn’t really vary all that much from router to router.

Manufacturing is a whole different pie – lots of different pies as a matter of fact. Nearly every production system is different than every other production system. Production systems that manufacture the same kinds of parts are different. I guarantee you that the Huggies manufacturing system at Kimberly Clark is a whole lot different than the Pampers manufacturing system at Procter and Gamble. Now, within each manufacturer they strive to make those systems as identical as possible, but when you roll out plants or upgrade plants over years, the manufacturing processes evolve. I guarantee that the last Huggies machine that Kimberly Clark put in is vastly different than the first one. It has to be. Components become obsolete. Prices change necessitating different parts. Processes get better and faster.

Because everything changes so much even for machines that make the same product, I can’t fathom how standard models are going to help. But that’s a story for another day. Back to the UNS.

My definition. The Unified Namespace isn’t a standard. It’s not a technology. It’s sort of a philosophy and practice of unifying your data into a group of related elements in a way that makes the unified data more useful.

The part you must get right when you do this is to name it appropriately. Naming means developing a standard way of referring to all this data. You want to name it in such a way that it can be easily recognized and accessed when needed. OPC UA and MQTT both have ways of doing that.

MQTT wasn’t always very good at that. In fact, it didn’t have a way to do that at all. I complained loudly about that. Now (because of me), the Sparkplug enhancement fixed that. It provides us with a standard topic structure that normalizes the data from all these different sources. Sparkplug is a vast improvement to the usefulness of MQTT in factory floor applications. It is one way of connecting data from varied sources to a manufacturing system and using a standard naming system to create a UNS.

I like to have precise definitions. In this case there wasn’t one, so I made one up.

I now define a Unified Namespace as: a method of organizing data from different sources into a coherent model (structure) that can be communicated and easily consumed by different kinds of data consumers.

There it is. I took my sword out and slayed the UNS dragon!