Unified Namespace for Industrial IoT: The Masterclass

Full transcript of Episode 33: Kudzai Manditereza’s Interview with Walker Reynolds on UNS

This article contains a full word-for-word transcript, including relevant links, of the conversation between Walker Reynolds and Kudzai Manditereza about the Unified Namespace (UNS) concept. You can watch the full video here.

I decided to create this transcript because the Unified Namepace concept will be a game changer for any organisation that wants to go fully digital. I hope this transcript will serve as a useful point of reference for anyone who wants to dig deeper into the idea and learn from the best. Below you will find a table of contents and the full transcript follows that. If you would like a detailed summary of the contents, you can find that in my latest article titled Summary of the Unified Namespace for Industrial IoT Masterclass.

Contents

· Origins and Evolution of Unified Namespace

· A Description of the Unified Namespace

· Why MQTT is the De-Facto Protocol for UNS implementation

· The Role of MQTT Sparkplug in UNS Implementation

· The Role of OPC UA in UNS Implementation

· Workflow for Designing a Unified Namespace for IIoT System

· Mapping Physical assets and Devices to a Unified Namespace, Tools and Techniques

· Metadata Definition for Consistency and Accuracy Across Different Systems and Devices in UNS

· How MES Fits into UNS Architecture, Specific Functions, and Capabilities

· Challenges in Implementing a Unified Namespace, and Mitigation Strategies

· Impact of Industry4.0 Community Discord Platform

· Industry4.0 Influencer Lists

· Impact of ChatGPT on Digital Transformation

· About 4.0 Solutions

Now you can see the topics this transcript covers, let’s get down to the nuts and bolts — the full word-for-word transcript of the interview. I’ve also linked some of the people, ideas and companies referred to so it makes it easier to navigate the content. I hope you find it useful!

Transcript

Kudzai Manditereza: In this episode, we discuss the application of the unified namespace concept as a framework for digital transformation in manufacturing. We first take a “back to basics” approach and then we dive deep into the details of how to implement this powerful concept for your digital transformation strategy. My guest on this episode is Walker Reynolds.

Walker is the president and solutions architect at 4.0 Solutions and board chairman at Intellic Integration based in Dallas, Texas. He coined and popularized the unified namespace concept in the context of industrial IoT. Walker’s career spans more than 20 years, with time spent in mining, steel, printing, and Tier 1 automotive before transitioning to systems integration and ultimately becoming a business owner and educator.

This episode is made possible by our friends at HiveMQ, who are providers of an Enterprise MQTT platform. Please do check them out to help support this podcast. Welcome to the fourth-generation podcast here on Industry40tv, which is a series of interviews designed to help you learn about industrial IoT from some of the world’s leading practitioners. So, if you’re new here, please do make sure to subscribe and click on the notification bell so that you never miss any of the interviews.

Now, here is my interview with Walker.

Origins and Evolution of Unified Namespace

Kudzai Manditereza: Okay, Walker, thank you so much for joining us on the show today. It’s great to have you, and I’m looking forward to having an interesting conversation with you. So, welcome.

Walker Reynolds: Thank you for having me, man.

Kudzai Manditereza: Okay, so, I mean, as you might be aware, the unified namespace concept has been getting quite some traction lately, thanks to you. I mean, you’ve really kind of put the message out there. I mentioned this also on your podcast, that you have been pounding this message for years and years. So, I think it’s really finally coming together; people are starting to realize that. That’s why I thought it was timely for us to actually have this conversation here to establish a back-to-basics understanding of the unified namespace, to lay the foundation for those who want to get a solid understanding of the concept.

Walker Reynolds: Perfect, awesome, yeah. You know, it’s funny. I was having this conversation the other day. I was talking about the unified namespace, and I told a story before about the very first unified namespace I ever built. It was completed in 2005 and it was built using Dynamic Data Exchange (DDE). We used Excel spreadsheets and it was done in a salt mine. In that whole concept, where I was, we had Data Highway Plus connecting every … all of the infrastructure, from the Stamlers which break up all the salt, all the way down through the conveyor systems, down to the screen plant, going up through the hoist. Everything was Data Highway Plus and if we were all using … we were all Rockwell infrastructure. So there was the ability to acquire the data, even over DH Plus. It was slow but you could still acquire it.

And one of the things I … I was young. At that time, I was in my early 20s when I first looked at the mine and thought it made no sense that I had to drive down to the screen plant, walk into the control booth to look at the HMI in that control booth. I had to drive at a speed of almost 15 miles an hour and then drive all the way up to each of the panels. The panels is where the mining team works. I had to drive up to the panel and go to the panel office, which was really nothing but a skid, to look at the HMI there and see the status of the Stamler. I thought it made no sense that we did that, right?

So, I was like, what we really need to do is we need to unify all operations in this salt mine, which continues to extend, by the way. In mining, you know, you’re never in one place too long. In the production environments, they continue to expand. We were six to seven miles in, you take a skip down, and you’d be six to seven miles in. But 40 years earlier, they were mining right where we came down at the bottom. So, I thought, well, the first thing I need to do is connect to everything and put everything in one place.

That was really the very first concept, and I said, “How do I, how could I do that?” And the answer was, “I’ll use RS links to grab all the data over Data Highway Plus, and then I’ll just use a connector to get it all into Excel. And then once I’ve got it in Excel, I can use Dynamic Data Exchange as my unified namespace. ISA-90, I didn’t use ISA-95 then. I just used a concept of ‘Hey, I’m going to organize the business. So the parent company, and then the division, and then you know, location, the site, and then, and then break it up by area, and then break it up by operational function.’ That’s, that was the first unified namespace in 2005.

And I’ve been, my entire career, that’s all I’ve ever done. It wasn’t until you know, every solution I’ve ever built, whether it’s for Starbucks or whether it’s for Toyota or whether it’s you know, enter in another company name, I’ve always used UNS. The difference was, I wasn’t doing enterprise class solutions until 2013. And so, my first enterprise class solution was 2013. And I, you know, I won a major award for it. We built the largest standalone SCADA system in the world. This is why people listen to me. We built the largest standalone SCADA system in the world in 2013. You know, 11 million tags, 11 million data points, 2000 concurrent users, 2 million daily alarms covering five states, 15,000 locations, 40,000 devices. We did that whole thing in 18 months for USD 1.6 million, and the next closest bid, which was Wonderware by the way, was USD 50 million. The Rockwell bid was almost USD 100 million.

So we win this major award, you know, and we used Ignition to do it. And Ignition had to develop technology to make it even possible. In 2013, they, Ignition, had to develop the technology. So that was the Gateway Area Network that you guys now know as EAM, but it was originally Gateway Area Network. Kepler also had to develop an API so that you could hit Kepler’s server service and be able to configure devices without having to go into their local client. There was technology that had to be developed and it was developed on that project.

And then a year later, we were introduced to MQTT. So in that big project that we did in 2013, there were limitations because it had to be OPC UA, so it was Modbus converted to OPC UA and then we had to do all sorts of load balancing to make it even scalable across that network. And then we, and then Arlen Nipper presented the next year at ICC, the year after we won our award, and everything changed. It was like, “Oh, that’s the solution.” And so, 2014 was when we really started scaling it. We did it with three huge companies. We did two, three huge global implementations and then we were like, “This is the way to do it.”

Everyone … and what happened, companies started hiring us to come behind other integrators and do what we do. And so what I started observing was that everyone’s making the exact same mistakes. We’re like, “Okay, we should start educating the community on this so that they don’t make those mistakes.” And that’s where it all started. I mean and so yeah, I’ve been blowing the horn as loud as I possibly can since 2018.

But anyway, that’s the history of the UNS, if you were going to ask.

A Description of the Unified Namespace

Kudzai Manditereza: Yeah, absolutely, yeah, I was going to ask. But it’s really fascinating to hear the history of the UNS and how it all came to be. So maybe let’s kind of like take a step back and define the term. How would you describe the unified namespace, and maybe in relation to like a traditional industrial architecture?

Walker Reynolds: Yeah, so the best way to describe a UNS is, think … you know, we have to start with the automation stack. So if we start with the automation stack, one of the things I find is that most people who don’t work in manufacturing … you know, I just had a meeting with an ERP company yesterday, Odoo for example. I met with Odoo’s one of their sales engineers and he’s an IT guy, lives in San Francisco. He’s a software developer, he’s never worked in manufacturing. One of the things that’s very interesting is that people who don’t work in manufacturing don’t know how manufacturing actually works, right? So the automation stack is very much unique to manufacturing and industry, right?

So, it’s basically five or six layers. We use a five-layer stack, but there’s essentially five or six layers. We’re going to go ahead and use five-layer stacks. So, on the very bottom, down on the plant floor or the edge, is PLC HMI. It’s the automation of equipment. At the layer above that is supervisory control and data acquisition. That is the place where supervisors control, monitor, and manage automation of equipment. So, supervisory control and data acquisition is a layer directly above that.

The layer directly above that is the manufacturing execution layer, and that’s really like the plant level. And that is where you are taking a sales order from the business and converting it into manufacturing. So, MES is going to apply, for like, apply to an entire plant. And then the layer above that’s ERP, which is really business; that’s where IT starts.

So, at the IT layer, that’s really where CRM, so the sales process, the planning of manufacturing, inventory management, getting paid, finance, all that kind of stuff: that’s where all that starts. And then directly above that is cloud; that’s the newest layer.

So, the where the unified namespace lives is, imagine that you were to take that stack, that five-layer stack, and you were to put a vertical bar right along that stack that connects all those things together. And instead of the data talking up and down layers to one another, it talks right and left, right and left. What’s inside that box, is the structure of the business and all of the events. Okay, so the unified namespace is the structure of the business and all of the events in the business.

All an event is, is something that happened and when it happened. And the structure is a semantic hierarchy. It’s the way we organize our business. We don’t just organize our business for business function. We, so a unified namespace contains many namespaces. So, if I have a PLC, a PLC has a namespace inside of it. Okay, some PLCs, that namespace looks like there’s a system namespace. It’s got all the information about the system on the PLC. And then there’s really a flat namespace that’s nothing but a bunch of arrays which equals registers and values, that’s it. So it would be flat, would be like device dot system, all that stuff, device dot you know, input table, and then all the array, or the array of all those values.

There’s a namespace there. What we want to do is, the way that we currently do integrations is, you have to know how that namespace is built in order to retrieve the data out of it. You can’t just hit a PLC and say, “Hey, give me everything,” unless you’re using a technology that can browse that namespace, right. And you can look at the browse feature. This is what OPC UA was supposed to do for us, right. OPC was supposed to give us the ability to browse everything. The problem is, in the implementation of OPC UA, they made so much of the standard optional. Many of those features are never implemented, especially in the hardware layer.

So, what a unified namespace stands to do is to take technology all across the business and structure it in a way that you can navigate it, and then just put all the events there. So, whenever I look at a unified namespace, what I’m looking at is the current structure of the business and all the events as they stand right now. It’s the current snapshot in real time.

And the best way I describe it to non-technical people is, imagine you had a file share that you could go to and the root node was the enterprise. Then below, and if I clicked on that folder, there’s a folder inside of it which is all of our sites. And also, if I clicked on a site, just clicked on it once, it would highlight all the parameters, all the state, all the events of that site right now, including what’s the OEE of that site. And then if I double-click on that folder, it shows all the areas. And if I double-click in the area, it shows all the production lines. And if I double-click on the production lines, it shows all the cells.

That’s what a unified namespace is, except it’s not in a file structure; it’s in a semantic hierarchy. It’s a topical structure, and that’s what UNS is.

And then what you do is you take all the smart things, and you have the smart things talk to one another through that unified namespace. Which, the obvious question is, “Okay, if I’m using a unified namespace, does that mean I don’t have two pieces of software ever talking directly to one another? They only talk to one another through a unified namespace?” Of course not. You may have software talking to one another, but the rule is that software has also got to talk to the unified namespace and put all of its data and information there. If that connection you create between those two pieces of software creates other data and information, then one or both of those nodes has to put it in the unified namespace. So that somebody who wants to see the structure and the events of the business can see everything in one place.

And so we call that the single source of truth for current state, and that’s, you know, and then you build all your solutions on top of that.

Why MQTT Is the De-Facto Protocol for UNS Implementation

Kudzai Manditereza: Interesting, this is very interesting. So now, maybe like, as you have already described that you kind of like started off building this unified namespace using Data Highway Plus, which kind of like means that you could use any protocol really to build the unified namespace. But it seems MQTT has become the de-facto protocol for the unified namespace. So, what I would like to find out is what features of MQTT enable a superior implementation of the UNS?

Walker Reynolds: All right, so that’s a long answer, but it’s really four things. I always try to keep my answers to three things, but it’s going to be four things. So, hopefully, I remember all four of them. All right, so one of the things that we discovered was that when people, when organizations tried to transform a whole business, they wanted to make their business smart, they would run into problems in basically three areas.

Number one, scalability: Could I literally collect all data and scale or am I just going to plug up my network and then I got to spend hundreds of millions of dollars, you know, investing in expansion of infrastructure, etc., etc.? So that’s number one, can I scale?

Number two, time to value: I mean, you know, technology is to the point where you can build anything. I mean, there’s literally no idea you can come up with that we can’t build. It’s a function of time and money, right? You know, do you have the time, and do you have the money? So, time to value, short time to value, was the second piece. If I’m not seeing a return fast enough, then my money, you know, eventually a business says the investment’s no longer worth it.

I mean, if you, if you want to build a home, okay, and you plan on spending, you know, a million dollars to build a, your dream home, and it takes 10 years to build that house, okay, and by the time that house is built — by the way, Bill Gates learned this the hard way, he tried to do this in Washington, he never got his dream home actually built, he had to build a different one. If it took, if your contractor told you it was originally going to take you 18 months for you to get the value out of that million-dollar investment and it’s 10 years later and you still haven’t gotten the value and now they want more money, that means the time to value is too long.

What we want is we want the time to value to be really, really short. Okay, and that, you know. And then the last piece is security. You know, you can’t, you know, if you’re going to connect everything together, you have to make sure that you are secure. That the moment you connect things together, if some idiot takes a USB thumb drive that’s got malware on it and plugs it into something on the network and everything’s connected together, it could infect everything. So security was the next piece.

So, MQTT met our minimum technical requirements. We learned that if we wanted to solve those three things, then what we needed was a technology that was edge driven. So that is, that’s the security piece. So edge-driven means, and it, and it’s cheaper, time to value goes edge-driven, and time to value. Cheaper, it’s cost and time to value, time to value and secure.

So, edge-driven means that the thing on the edge is what establishes connections out. There’s nothing out that can talk to the thing on the edge except for the thing that it has already connected to. Okay, so rather than the PLC responding to somebody it doesn’t know, some smart thing it doesn’t know, has never met before, it establishes a connection with a thing that it knows it’s safe to talk to. And that’s the only thing it talks to because it only talks through that connection it established. So, security. Report by exception, that goes to scalability.

You know, most people don’t know this but if you look at any benchmarking studies from the CSIA or you do this on your own, if you look at the average PLC program, okay, only 7 percent of all the values inside of a PLC program change at least once every 60 seconds.

So 93 percent of the values, the constants, the parameters, the variables inside of a PLC change at least one change once more than every 60 seconds. Only seven percent of those values are going to change at a really high frequency.

If you look at the way OPC UA is implemented, if you look at the way drivers are implemented, you’re never requesting one tag. If I request one tag, I’m not actually getting a response on one tag. What I’m getting is a block of data of which one tag is the thing I care about.

Okay, so it goes to scalability. Report by exception means we only send the things that we that changed. And then the last thing is lightweight. That is when you’re establishing a connection between the client and whatever server, the header — there’s always information at the beginning of that connection — has to be really small. Don’t send a lot of wasted stuff, right?

So when we said edge driven, report by exception and lightweight, what we were talking about was broker technology — we just didn’t know it at the time. Pub sub, right? So then we went and looked, what are all the possible protocols and MQTT was the one that was developed for Phillips 66 by IBM.

So Andy Stanford-Clark at IBM and Arlen Nipper who’s really more of the, you know, he’s the guy that everyone knows invented MQTT to solve a very unique problem for Phillips 66 in the industrial world. If you go to Phillips 66 to this day, Philip 66 infrastructure is MQTT.

So when we looked at it and we thought, holy shit, that’s the protocol that we should use here. And at the time it just happened to be when Arlen came back and said, all right, we’re going to go ahead and scale MQTT in industry. It was originally built for industry in in the late 90s but it really got adopted like on the commercial side on the user side. It went to hackers, you know, to people doing hackathons and stuff and it went to, you know, Facebook Messenger. You know, MQTT is a staple protocol. You are, you’ve been using it for your whole life. If you’re using, you know, Facebook Messenger or Instagram messenger and you see people the literally ellipses when people are typing, that’s only possible because they’re using an edge driven report by exception protocol which is, in this case, MQTT.

So since 2014 MQTT has been developed more and more, especially once Sparkplug was developed and it went to the Eclipse Foundation as an industrial protocol and standard. So the reason I’m a fan of MQTT is because I haven’t been able to break it yet.

The reason I’m not a fan of OPC UA is because I can break it easily.

The Role of MQTT Sparkplug in UNS Implementation,

Kudzai Manditereza: Oh interesting, and what, what does a Sparkplug … is there any special thing that Sparkplug brings into the picture that makes it even more suitable for UNS or it doesn’t matter really whether it’s flat MQTT or Sparkplug?

Walker Reynolds: All right, so here, here are the three things that Sparkplug B, Sparkplug B is really this. There was a Sparkplug A, believe it or not, but it was sort of just like the wireframe of the standard, right? What Sparkplug B gave you out of the box that most of us that we didn’t have in flat MQTT was, number one, it gave you broker side state of broken connections.

So you could, you know, with death certificates and birth certificates you could see the state transitions of when a node connected to a broker and then disconnected, which by the way you couldn’t really see that in, you know … flat MQTT didn’t care if and no disconnected, in fact it expected nodes to disconnect all the time so it didn’t keep any type of event history on that. Spark plug B baked that into the specification.

Encryption is another big one that was baked into Sparkplug B. And then compression. The problem with Sparkplug B was that when they wrote the specification they made it device centric so they assumed Sparkplug B was going to be something you put on a PLC. So the PLC would become a Sparkplug edge of network node, but the problem is that we’re using Sparkplug B in things other than devices.

So you have to do workarounds right, and this is where Sparkplug 3 has improved, I think in my opinion greatly improved the Sparkplug specification. The problem that we … the limitations which I think you’ll ask is, you know, hey, what do you lose by not going with Sparkplug?

Well, I would say the biggest thing … or going with MQTT. Here’s the biggest advantage OPC has over MQTT, and it’s OPC methods. You can run a method on any object in OPC. So for those of you who are not software developers, you know, a method is basically … think of it as a function.

I could, you know, let’s say I created a digital object called a tank, which is a node inside of an OPC server. That object has a bunch of methods that are on it. So if I went to the OPC server and I went tank dot whatever OPC method I care about, I want to see its parent, I want to see its children. I want to, whatever it is, I can run a method on that tank and get more information about that tank.

You are limited in MQTT to only the information that you can acquire in the topical namespace. So unless you create a topic that tells you what the parent is or you browse up to the parent, you can’t run a method that tells you what the parents are. You also can’t run a method that tells you what all the subscribers are. There are no methods on MQTT. That’s one of the challenges.

And so, when you hear guys like Rick Bullotta or me or anybody else talking about we need the need for microservice support in MQTT, we’re talking about stuff like that. Probably the biggest limitation, in my opinion.

The Role of OPC UA in UNS Implementation

But when you compare that … because at the end of the day most people are making their choice between two protocols in their infrastructure. When they’re doing digital transformation, they’re really picking between two.

There are more than two, but if you look at the vast majority of the market, it’s either we’re going to be an OPC infrastructure or we’re going to be an MQTT infrastructure. What I’ll say is this, is you can have a wholly OPC UA infrastructure, okay? You can’t have a wholly MQTT infrastructure right now because there isn’t enough. What you’re really doing is converting OPC UA into MQTT. You’re converting REST into MQTT. You’re converting SOAP into MQTT, right?

Because MQTT is so much newer to the game, that, you know, while there are thousands of platforms out there that support it, you know, there are, there’s only a handful of PLCs right now that’ll plug natively into an MQTT infrastructure without having to go through some type of gateway. But all of that’s changed.

If you look at the growth, OPC UA is down, MQTT is up, right? And I think a lot of people misunderstand. They think I’m not a fan of OPC UA. No, no, I am a fan of OPC UA. I’m critical of the OPC Foundation. I think the OPC Foundation could do a better job. I’m critical of the limitations of OPC UA, but we use it all the time.

We just use it on the edge. We limit our use of OPC UA to that second level. So when, you know, PLC HMI SCADA, we transform from OPC UA by the time we get to that second level. So, yeah, MES, ERP, Cloud, that’s all MQTT. There’s no OPC UA there whatsoever.

And what we’re doing is we’re transforming from OPC UA to MQTT at level one, which is the PLC HMI, and at level two, which is the SCADA layer.

Kudzai Manditereza: Absolutely, yeah. It’s really interesting. Like you mentioned, that a lot of people tend to think that maybe you’re kind of like hating on OPC, which is kind of also for me the same feedback that I get, you know. For me, OPC UA, as you would know, I kind of have probably the most watched series on OPC UA. I’m even actually promoting OPC UA more than anyone else because I kind of understand it’s best placed within the plant flow. But when you come to MQTT cloud connectivity, this is where kind of it’s not an issue of only MQTT.

Walker Reynolds: It’s not, what I say all the time is, you don’t have to pick one or the other, you have to use one and the other in the right place. That’s what I say. Like we use OPC UA all the time but if you were to talk to the average person they’re going to say “oh, I hate OPC UA”. No I don’t. Just I’m very critical of Rockwell Automation all the time. Why? Because there’s lots of reasons to be critical of them, and I have a responsibility to criticize the organizations who can have the biggest impact but don’t necessarily choose to have the biggest impact. But that doesn’t mean that I hate Rockwell Automation; I love their PLCs. There are certain things they create that I really love. By the way, I think one of the greatest pieces of industrial software ever created was developed by Rockwell, and they actually developed it, and it was Asset Center.

I think Asset Center was one of the greatest pieces of software ever developed for industry in all time, and Rockwell developed that. I’m a huge Rockwell fan. I’m a huge OPC UA fan, as long as you use it appropriately. I am not a fan of how the OPC Foundation conducts business. I think Microsoft has way too much of a say in how the standards are written, and Microsoft doesn’t, you know, again, I don’t want to be critical, you know, I don’t know if you have a relationship with Microsoft, but in my opinion, I don’t think Microsoft cares about what’s best for the industry.

I think Microsoft cares about what’s best for Microsoft, right?

Workflow for Designing a Unified Namespace for an IIoT System

Kudzai Manditereza: Absolutely, okay. I mean, we could go on for four hours with the issue of OPC UA and MQTT, so maybe let’s kind of get back to the unified namespace. Now, for those in the audience who want to kind of like get a clear picture of the workflow, what would you say are the primary steps involved in designing a unified namespace architecture?

Walker Reynolds: Right. So the, so from a nuts and bolts, there is no one-size-fits-all solution for any organization. This is why the unified namespace is so important. You know, manufacturers, if you look at a manufacturer that doesn’t have digital solutions, so start with them and, you know, and I don’t know, I know that you’re an integrator, I don’t know your experience as an integrator, so I don’t know how many manufacturers you worked with that had no digital infrastructure whatsoever, like they didn’t even have a single switch on the plant floor, right?

But I’ve worked with a lot who are like that. If you go and look at companies like that, if you go look at manufacturers like that and they are not constrained by the limitations of rigid software structure, they innovate their manufacturing processes at, you know, at N squared to anybody else, okay? Because they’re doing paper processes. They can just, they can literally just decide overnight, you know, hey, I’m going to put a conveyor between this machine and that machine and we’re going to route stuff from this machine, you know, I mean they can just do that at the speed of light, right?

So their competitive advantage is in A, the way they manufacture, their manufacturing number one. That’s, it’s where it boils down to how efficient are they on the plant floor and how good are they at squeezing out more efficiency, right? When you’re creating a digital infrastructure, I want to build a UNS, I go to that company and for the last two decades, they’ve been completely unconstrained. They have no rules whatsoever. It’s just production is king, get the stuff out the door, right? And they do whatever it takes, you know. They do whatever it takes.

The, you know, take this motor from that thing and put it over there, put this conveyor going to the, you know, put a line of people and hand the stuff, I mean, I’ve seen this in printing operations, literally, you know, in the stitching operations where they would stitch books. I literally saw a machine that broke down halfway through the stitching machine. It literally went at midway, the last 12 cells were broken down, and what they did was they put a line of people between cell 10 of line one and cell 11 of line two and they literally hand … the book would come down, they’d pick it up and they’d hand it by people, and then resume it on cell 11 of line two.

Okay, if you’re using a digital manufacturing execution system, okay, that’s off the table. If what you say is, we’re digital where SAP is king, we’re going to operate our business based on SAP. SAP is king, that’s no longer an option, right? So what I started thinking was okay, any digital infrastructure has to be a reflection of what you do on the plant floor, not an enforcement of how you should do it. Because it, I’ve worked enough on the plant floor to know that even the most stringent executive or plant manager who says, you know, we’re process based, you know, we’re going to stick to the rules, no, that goes out the window the moment a machine breaks down. You come up with some creative way of getting the goods out the door, right?

So, the infrastructure’s got to be a reflection of the reality, okay? So that means it’s got to be driven from the reality. So what’s the first thing we do? We generally go to the, we do a digital transformation maturity assessment. This is how we do this, but we’ll go to the IT side of the business, which is generally very, very structured, okay. We’ll look at the ERP, we’ll look in the ERP, and we’ll say how has the ERP structured the business? If I were to look at an ERD inside their ERP, how did they structure it? What’s the relationships? Oh, well, it in general, it’s ISA-95 part two. If you look at SAP, it’s ISA-95 part two. If you look at Epicor, it’s ISA-95 part two. They all use the same standard for organizing businesses, right? Enterprise, site, area, line, cell, and then what they do is a site will have parameters, metadata that gives you more information. So like, what business unit is a site a member of? Well, that’s metadata under the site. It’s not, it’s not an entity. Like business unit’s not an entity, it’s a piece of metadata.

So what we do is, we structure their unified namespace based on how their ERP has structured their business, generally. Okay, then what we do is, we look at the OT side and we look at all of the namespaces that already exist. What are the functions? What are the definitions and what are the information? Those are the three types of namespaces we create, and then we plug them into this hierarchy and then we figure out a way to integrate it all together and we use MQTT to do it. But where do you start? The first place you start is, how is your business already organized? Believe it or not, it’s already organized, right? I mean, accountants have to know exactly how much you spend on every asset. If you’ve got a machine on the plant floor, okay, they have two types of numbers they track on that machine: how much capital do they spend to put that asset on the plant floor and then how much do they spend to operate, that’s called Opex. They’re tracking those numbers based on that asset. There’s a serial number, there’s a model number, it’s in some piece of software somewhere, and everything you do, every replacement part you put on that has a cost associated with it. All that goes somewhere.

What we do is, we look at how the business is already organized and we structure the unified namespace based on the way it’s organized. Then we plug in the functions. We plug in the functions, we plug in the definitions, we plug in the information that people need, like in dashboards or software needs, in order to consume and produce more information, learn, get smart for a business.

Mapping Physical Assets and Devices to a Unified Namespace: Tools and Techniques

Kudzai Manditereza: So it seems to me that a big part of designing a unified namespace involves mapping data from these various namespaces, and some of them, antiquated as you have already alluded to, like, into one unified namespace. So what tools or software can be used for this process of mapping these unified namespaces into these various namespaces into that unified namespace?

Walker Reynolds: Alright, so that, it’s a really good question. So the answer to that question is, what software do you use is generally a function of which layer you’re operating in, okay? So what I’ll do is, I mean, the list is long and distinguished, so I’m going to give you like the most common example of an architecture. The most common example of an architecture is, you’re going to install an IIoT platform either in the business, just one platform, one location, maybe redundant, two servers, or you’re going to, you’re going to do a layered distributed approach where I have one platform at every site and then what I’m doing is aggregating everything there and then I’m transmitting to a higher level and then I’m subscribing back down to my lower level so I can see the whole business. But I’m going to do the simplest type of implementation.

So what you’re going to do is, you’re going to put, you know, you’re going to put some OPC server on the plant floor, right? You’re going to, you’re going to use Kepware, that’s the one that we use the most. So KEPserver by Kepware, we’ll put it on the plant floor. They have all the drivers to talk to all the legacy hardware, industrial hardware.

Then, what we’ll do is, we’ll connect that OPC server to an IIoT platform. The most common one we use is Ignition, but there are many examples. But you hear me talk about Ignition all the time. The rules are that it has to be an open platform to do CI/CD, scripting, programming. Okay, it has to talk REST, it has to talk SQL, it’s got to talk all the open protocols, it’s got to talk OPC UA. You unify all those things in that one place, okay, so just the connections.

Then what you do is you build your unified namespace. Okay, now we use tools like HighByte; we use tools like Cogent DataHub. I mean, they’re … The reason I try not to mention is because I always feel bad when I leave one out that you could use, right? I mean, there’s so many, there’s so many you could use. But a really common infrastructure is Kepware on the edge, Ignition in the middle as your IoT platform, okay, and then we’re connecting to Azure or AWS in the cloud. That’s the most common.

All right, so what I’ve got is OPC UA into Ignition, conversion into unified namespace. Ignition is connected, as an IoT platform, is connected to all the things that support our native protocol MQTT. It’s also connected to all the things that don’t. It becomes our de facto gateway, okay? Now, not always, believe me. At scale it doesn’t look like this, but if you’re in a mid-sized plant or a small size plant, this is going to be your integration steps. You’re going to build a unified namespace inside of Ignition using Ignition tags and mapping to all the stuff. You’re also going to connect Ignition to your ERP using a business connector.

Let’s say you’re using SAP; you’re going to use SAP connector and the business connector. The business connector is going to take the SAP API, and you’re going to be able to map it into tags inside your unified namespace using that module. Then what you’re going to do, let’s say you’re using AWS or you’re using, let’s use Azure as an example, you’re going to use the Azure IoT connector inside of Ignition to connect to Azure. But long-term, what you’re going to do is you’re just going to take native MQTT from Ignition, and you’re going to transmit to the broker, which is the way we normally do it. We’ll transmit to the broker, and then Azure is going to subscribe to the broker inside of the Azure IoT Hub.

So, and then what you’re going to do is in Ignition, you’re going to build visualizations that are going to be visual representations of namespaces. So, there are three types of primary namespaces. There’s a functional namespace. So you’re going to create a functional namespace called OEE, and inside of OEE are all the parameters, all the inputs, the outputs, and all the memory: the intermediate parameters that you need to calculate OEE. So if I wanted to visualize any of those things, all I do is create a window that points to the OEE path, and then I visualize all the things that I care about on that window.

So that’s an import. That’s a functional namespace. You have informative namespaces where that data is only consumed, there are no inputs. So it’s really the abstracted data and information that’s going to be consumed by some consumer, either software, a visualization, data lake, whatever. And then the last type is a definitional. So, the definitional namespaces are basically, they’re essentially parameters and they rarely or never change. So, it might be something like a namespace: what was the install date of this asset or what’s the model number or what’s the serial number or the manufacturer? These are definitions that rarely or never change, okay?

Those are your three biggest types of namespaces, and they can live anywhere in the hierarchy. And then you have the last one is ad-hoc namespaces. This is a very important concept. So, you know, you have two types of solutions in a business: you have homogeneous solutions which apply no matter where you are in the business. So, like, let’s say OEE is a function, we’re going to calculate at every line, every area, every site, and across the enterprise. Well, that function, the best-case scenario, the best practice, is to calculate OEE the same everywhere. Okay, so define the function one time and use it everywhere. That’s homogeneous.

So, that means the way I visualize OE is always going to be the same, the way I ingest the events, so that I can store them, is always the same. That’s homogenous. And then you have heterogeneous features which are unique.

So, it may have a manufacturing process that only applies to one area and one plant and nowhere else in the organization. Well, that’s a heterogeneous feature. It’s unique; we call that blue. Everything that’s homogeneous, we call red.

So, red is the things that you’ve defined at the enterprise level, and they’re generally managed by your digital transformation group. Blue is the stuff that’s created by everybody else. So, if you’re an engineer on the plant floor and you need to build a solution for just you, you can go to a place in the namespace, create a blue namespace — that is the Kudzai namespace — build your function, put in your definitions, consume data from wherever you need to consume it from, and build the solution.

What does your digital transformation team do? They monitor all the blue stuff and they go, “Oh, what’s this thing Kudzai built? What’s this thing Kudzai built at that location in Belgium, you know?” And then they reach out to you and they say, “Hey Kudzai, tell us about this. Oh wow, that might scale, that might apply to this other facility we have in South Africa.” So now, we may turn that blue feature into a red feature.

Right, so people ask CI/CD, how do you manage change management? It’s all done from within namespace.

Metadata definition for consistency and accuracy across different systems and devices in UNS.

Kudzai Manditereza: Fascinating

Walker Reynolds: Yeah.

Metadata Definition for Consistency and Accuracy Across Different Systems and Devices in UNS

Kudzai Manditereza: Now, some of the systems that you’re going to be pulling data out of are going to be like maybe talking protocols like Modbus where you can kind of just have like a value, not even the units, which means that you’re going to need to define some metadata for these sources of data. Now, do you have some guidance on how best to approach that metadata definition so as to ensure consistency and accuracy across the different systems and devices in your unified namespace?

Walker Reynolds: Alright, so this is the part where we’re really missing the standard, right. So the answer is here: how do we take a Modbus data point, which is really just a register and a value, right, and how do I turn that into something with more context, right, or the metadata I want to associate with that thing?

So for example, a really good example would be, you know, I have a rectifier from China sitting over there on that table over there, and it’s just built, some son and father built it in some shop somewhere, and they sold it to a manufacturer. And part of the documentation is a Modbus register table, okay. So you can talk Modbus RTU to it, and you can make a request for a Modbus register, and it will return the value; there’s no other context whatsoever.

So what we did is we create an object which is that rectifier. So what we’ll do is we’ll create a data type which is that rectifier, and we’ll create a namespace which is the Modbus namespace. And then what we’ll do is we will define in a data set, this is the Modbus register table. So this register equals this value, this register equals this value — it’s a lookup table, okay.

Then what we’ll do is we will create another data type which is the inputs for the Modbus table. So that is the stuff that’s input to the table that we can read; we’ll read all those inputs in and then we use a lookup table to give you the description from the documentation. And then we have another one which is the outputs, and then we have another one which is the internal registers, okay.

So you have three namespaces: input, output, and internal register. And then we use the lookup table to give you the context. So what you end up with is the name of the tag is the context in the lookup table, okay.

Another thing we do is we just add topics that are metadata to that device. So it could be something like a topic which is asset; it could be a topic called model number, serial number. Those are all things that you’re not going to get from the Modbus table, but they’re all put together. There’s no standard for that, right.

So when you build a namespace for that rectifier, you’re literally using your experience and knowledge to decide how to build that, right. What’s most important is how do you handle the difference between how I would define it and how Kudzai would define it. Both of us would define it in a way that works for the business, but we’re not going to define it the same way.

And the answer is, you and I have to be part of the same team operating under the same rules. So you and I would both be on the digital transformation team. We would have one owner of the digital transformation of the organization, and one architect, and we would reconcile our deltas through that mechanism, through that team. The team would decide which way we do it; we both give our ideas and then we would just say, “Okay, here is our internal standard for how we’re building, how we’re mapping Modbus registers to this namespace.”

Kudzai Manditereza: Oh, interesting!

Walker Reynolds: So, one of the things that you do as an organization is you start out with minimum technical requirements. So there’s a document called MTR and it’s a document that you give to all internal stakeholders. We call it a digital primer. It’s a many things; it’s our digital strategy and it’s our architecture, and then it’s our minimum technical requirements. That’s your digital primer. It’s sort of the it’s your Bible in the organization for how we’re going to be a digital company.

Minimum technical requirements are the rules that you give to engineers and vendors to say, “If you’re going to build us a digital solution, you got to follow these rules, right?” So our protocol is this; our hierarchy is that. Now, in the beginning, you don’t have a lot of rules. You have five or six, seven rules to get started, but you expand the minimum technical requirements to include specifications that come up like that.

So when I come up to this, alright, how are we going to define a Modbus object? Well, now what we do as a digital transformation team is talk about that. We may go to our architect, the, you know, 4.0 Solutions or Intellic integration, whatever your solutions architect and ask them, “How do your clients normally handle it?” Well, they handle it in one of these five ways and pick from one of these five ways. Our recommendation is to use way number four, but you don’t have to do that, you know. There’s a lot of flexibility.

The idea is, and this is why I’m so critical of off the shelf solutions. The digital infrastructure, you know, digital transformation for an organization is about becoming smart. And what is becoming smart? Connecting everything together and then finding patterns of data we can’t see with the naked eye and then improving the business based on those patterns. That’s all it really is.

The second step is plugging into a digital supply chain, taking that infrastructure I created and connecting it to other businesses. So that in a digital supply chain, I’m no longer limited to just the links upstream that I already know and the links downstream I already know. Instead, when I have something I need to be supplied to me, what I’m doing is I’m going to my digital infrastructure and I’m making a request out into the ether. And all of the possible suppliers reply to that request, not just the ones I know, right?

That’s digital supply chain, right. Digital supply chain for the consumer downstream is all about, “How do I collect data from the things I make after my customer has them in their hands? Or how do I make products better after my customer buys them?”

A perfect example right now would be if you look at Ford and General Motors and Tesla. You compare those three. After a customer gets a product, and the product is the car, how does Ford handle improving the vehicle? How does General Motors handle improving the vehicle, and how does Tesla handle improving the vehicle?

So, I happen to have a Ford F250 diesel pickup truck. I happen to have a Tesla. Tesla fixes all my problems in my garage as soon as my car is connected to Wi-Fi. So, any improvement is done over the air and nearly everything, even limitations and sensors, are improved over the air, okay. Ford requires that I go to a dealer and it takes me two weeks to get in and they’ve got to connect it to a computer and they’ve got to look at all these tech notes and then they decide whether or not that’s a repair that’s covered under the warranty or not covered under the warranty or it was a recall or it’s not a recall.

When you look at the two, Tesla makes products that get better after you buy them. Ford makes products that they only fix when they’re afraid they’re going to get sued for not fixing it, okay. Who’s going to survive? I mean, either Ford’s got to do it the way Tesla does it or Ford will die, right? It’s just, it’s just that simple, right.

You know, it’s a super, super important concept. The reason we are a digital company changes over time. The more mature we become as a digital company, the reasons — the value proposition for being digital changes. The more mature you are, the more focused you are on making products that get better after your customer buys them. The more focused you on plugging into a digital supply chain, but the less mature you are in your digital journey, the more focused you are on simple things like just having visibility into data you don’t have visibility into.

Tesla takes for granted that everyone has access to all data and information in the organization digitally and in real time. They take it for granted. Ford doesn’t take it for granted, neither does General Motors, but that’s because they’re very immature organizations. By the way, when people ask me why are you so critical of Ford and GM? Well, I have their digital maturity scores and I have Tesla’s digital maturity score. Tesla’s digital maturity scores is an 86. Ford’s digital maturity score is a 41, which is under the mean. General Motors is a 37. Across 10 Industry 4.0 pillars. You know, it doesn’t take a rocket scientist to go, “Okay, if I’m not digital, I’m not going to be successful.”

How MES Fits into UNS Architecture, Specific Functions and Capabilities

Kudzai Manditereza: Interesting. It’s really interesting. Yeah, so, maybe moving on, I know you have currently got an MES educational program going on at 4.0 Solutions, kind of like teaching how to build a custom MES. Correct me if I’m wrong, right? So, what I would like to find out is, how does an MES system fit into a unified namespace architecture? And can you explain the specific functions and capabilities of MES that are relevant to the UNS?

Walker Reynolds: Sure. So let’s imagine what I’ve done is, my level of digital maturity is this: I am connected to everything on the plant floor. So, based on that architecture that I have, I’ve connected my OPC server over native drivers to everything. I have an IoT platform that talks to that edge. I have an IoT platform that talks to all the business solutions, and I have a unified namespace put together. It’s incomplete, but it’s put together.

I have all my edge data. I’m connected to the ERP; that is, I can retrieve work orders and bill of materials, that kind of stuff. And I have a unified namespace that is enterprise, site, area, line, cell. If I look inside my production line, I’m going to have edge and I’m going to have ERP, right?

So, I’m going to have edge, which is going to be all the stuff on the edge, the stuff in the PLC. And the ERP is going to be all the stuff that I have from the ERP — in my unified namespace. And now what I want to do is, I want to calculate OEE, right? So I want to do it on this asset and all other assets.

So, the first thing I’m going to do is, I’m going to say, “Alright, where are we going to calculate OEE?” There’s lots of off-the-shelf stuff, right? In Ignition, you could just add a Sepasoft module which calculates OEE. So, do I want to buy the Sepasoft module, put it in, and then Sepasoft creates tags that you can put inside of a unified namespace? Do I want to use Sepasoft to do that?

Alright, maybe — maybe I don’t. In this case, let’s say, we generally say it’s not worth it. At the end of the day, those modules are too expensive and they’re too restrictive. You know, you want your manufacturing execution system to be a reflection of what’s really on the plant floor. You don’t want to try and fit your business into someone else’s data model; you want to build a data model that reflects your business.

And this just goes to people not understanding how software is built: back-end, API, UI, right? So, what we would do is, we would say, “Okay, we’re going to go ahead and calculate OEE ourselves.” So, what are all the things that we need?

Okay, well, we’re going to need some place to store transactions. So we’re going to need to store the events. So, we’re going to need some SQL database to do that. Great, our platform talks to a SQL database.

We’re going to need a namespace so that in that namespace, we can ingest from the machine the things we need: infeed, outfeed, waste, and state. We’re going to need a namespace that our OEE calculator, which we might write in Python or we might write in .NET, we might use it off the shelf, is going to write values back to.

What was all the unplanned downtime in seconds? What was all the planned downtime in seconds? When did this production run start? And then we’re going to need a part of our namespace that connects to the ERP stuff, all the work order, what’s our work order information? What was the schedule, what’s the standard rate, all that kind of stuff?

So now what I’ve got, I’ve just designed an MES namespace that’s got an OEE namespace that has three levels of connections. Okay, one input, one output, and one definitional from our ERP system, right? Now, all I got to do is write an engine that consumes from those three namespaces, produces the result, goes to the database to get any historical transactions, produces results, and writes back to our values. That’s how it works. You’ve created a functional namespace called OEE, and that functional namespace is copy-pasted everywhere.

Kudzai Manditereza: Awesome, awesome.

Walker Reynolds: So you see, here’s the most important thing I say, you know, people will say, “Where does ERP go? Or where does MES go? Or where does SCADA go?” Well, let’s ask the question, why does the word ERP even exist, or why does the word MES exist? And the answer is, MES isn’t a thing, and neither is ERP.

What it is, is just a name for a group of functions. So, what we’re doing is saying, “Get away from that name MES, and let’s focus on the functions of MES.” So, what does MES do? We’ve shot videos on this, you know, what actually is MES?

The biggest difference between MES and SCADA is that SCADA is the same no matter where it’s implemented. It is always the same thing: it is always supervisory control; it’s always data acquisition. 100% of the time, it is always the same thing: alarm management, trending, some local historical data, but SCADA is SCADA is SCADA.

MES is not MES is not MES. There are basically four core functions of MES. You know, everyone has scheduling, everyone has work orders, everyone has OEE, everyone has downtime tracking. Other than that, it’s carte blanche. We have bond management, we may have recipe management, we have formulation generation, quality management, statistical process control, statistical process analysis. You may have many other functions that are MES, but the core four are the ones we focus on.

And then, let’s say we want to do SPA, statistical process analysis. So, we don’t want to use statistical analysis to control anything, we just want to use statistical analysis to reveal — to inform people. That’s SPA. We might add that as a function of our manufacturing execution layer, right? And then you build SPA and you have an SPA namespace.

Kudzai Manditereza: Oh, nice, nice. Interesting. That really makes a lot of sense, now that you put it that way. It really makes a lot of sense.

Walker Reynolds: What we do is focus on function; we focus on function and we create functional namespaces that you can copy everywhere. “Oh yeah, I need SPA over here now.” Copy the namespace from here to there, make the connections.

Challenges in Implementing a Unified Namespace, and Mitigation Strategies

Kudzai Manditereza: Awesome, now. So, I mean clearly, you’ve been in this space long enough and have been involved in UNS implementations long enough to know what challenges are most likely to arise for someone who’s doing it for the first time. So, do you have any insights to share in that regard? What are the challenges that someone is doing for the first time is likely to come across, and how they would overcome that?

Walker Reynolds: That’s a really good question, dude. Alright. I mean, that’s an excellent question. That question right there will be the one everybody says, “This is the most valuable thing here.” Alright, so the answer is twofold.

Number one: let’s mitigate the impact of the challenges first off, okay, before we try to overcome them. So, the most important thing when you’re first starting in a digital transformation journey, the most important thing is that you start with a digital strategy. Why is it you want to be a digital company? A three-sentence statement of why I want to be a digital company? Why is this going to be good for our customers? Why is it going to be good for us?

Number two, you have to have some type of architecture. I described architecture to you, but the most important thing about architecture is that it’s unified namespace, hub and spoke, single source of truth. All smart things talk to one another through a common infrastructure: unified namespace, structure, and events, okay. Architecture is number two.

Number three, minimum technical requirements. The rules for if we’re going to build something, we’re going to build within these rules, okay. And you know, if you’re in mastermind or mentorship, you’ve seen this a million times. We have these example MTRs. Like, they vary from organization to organization. It’s more about teaching them how to create MTR, how to teach them how to create a digital strategy, teaching them how to architect correctly.

Number two, the proof of concept needs to be small. The first time you’re going to try to implement your infrastructure, do a small one, okay? It needs to be small, small team, no more than say 10 to 12 people. Ideally, you’ve got four to five people on your Scrum team to solve whatever problem you’re going to do, okay.

Also, you want to have complete control over the area you’re in. You want as little involvement from external departments and groups as possible, okay? Because you don’t want to fight theoretical battles, you want to win the results war. And the way to win a results war is to start results. You need to have a result. You have nothing when you first start. All you have is a dream and some stuff on some PowerPoint slides, okay. And then, the last thing is, solve a major business problem.

Okay, so this is all about compartmentalizing and mitigating the challenges. Make sure that you’re solving an ideal, a major problem. This is a really good example: this one company brought us in, a really large manufacturer, huge, everybody knows the name, right?

They bring us in and we’re like competing against 11 other integrators for some project. I didn’t know that, but my business development guy brings me in and he’s like, “Hey, they want this. The corporate director engineering wants to meet you”.

We get in there and he’s like, “Hey, we have all these integrators, you know. Show us your slide deck on who you guys are.” I’m like, “Yeah, we don’t do that. We don’t have PowerPoints. First off, I fire anybody who creates a PowerPoint in my company. What I can tell you is what we’re here to talk about: problems. If you want me to show you some slides, I’ll show you some presentations, but let’s talk about your problems, right? So, let’s talk about why are you even having 11 companies here. Like, what problem are you trying to solve?”

And then, on a whiteboard, I just sort of sketched out that solution. And then I said, “This is what your unified namespace would look like.” Then, I’d say, “What is a problem you’ve had in your business for a decade, two decades that you have not been able to solve yet? People have tried to solve but they haven’t fixed it.”

And he said, “Oh, I know just the place. It’s this facility we have in Northern California. You know, we have, we have problem X, Y, and Z. Okay, they were major issues.” I said, “I want to go there and let’s solve that problem.”

So, what we did was we picked a major business problem and then we just hit a five-run home run, right? Kept it small, we picked one little, small area of that facility that had a major problem. It had to do with energy consumption. We solved the energy consumption problem, made it fully visible to the business. And the moment you do that, everybody’s like, “Okay, now you got political capital.”

But the first thing you want is you want to make sure you’ve containerized your challenges. Biggest challenges you’re going to face, okay. Number one is if you don’t have your team made up of true believers, you’re going to get a lot of people who resort back to the old way of doing things: linear point-to-point integration, pull response, OPC UA. You can get away with that in the beginning. You can’t get away with it when you try to scale. So the moment you try to scale, “Hey, let’s deploy this to the whole plant. Let’s deploy this to the entire business unit.” Then all of a sudden, now the IT Department’s complaining because the, you know, network congestion, vulnerabilities, you name it, right?

So, number one, you want to make sure that you understand that your propensity for resorting back to the way you used to always do things is going to be high. So, number two, you’re going to run into some functional problem that you don’t know how to solve, okay. And what you’re going to do is resist the urge to bring in somebody who can answer the question for you. Don’t do that, okay.

And then, number three is “cavemen,” the citizen against virtually everything, the person who comes up with 10 reasons not to do something. Yeah, yeah, the “CT no” is what we call it, right, in an organization — CT No. You know, are you in an organization where the chief technical officer says no to everything first? If so, then you have to account for that.

And the last thing is going to be scope creep. This is probably the biggest one. The moment you start showing value to an organization, they want all their problems solved yesterday. You have to protect the sprint at all costs. Digital transformation is an iterative process on one common infrastructure. So just the way I explained, you know, you build an OE function. Now, I have a new problem that’s going to be solved by another function. You’re going to build that function. That’s done iteratively, right? You have to make sure that when you’re in each iteration, you are protecting what it is you’re delivering. We call this “protecting the sprint at all costs”.

If there is any problem that pops up over and over and over and over and over and over again in digital transformation, especially when you’re building with UNS because the value is so high, once people see the capability, their mind is blown, right? Top to bottom, data scientists, you know, I didn’t talk about using Kafka to turn everything into time series and stream it into a data lake, and your data scientists don’t have to do any normalization or cleansing of data anymore. They literally just have access to full events that are already fully normalized and scaled and, you know, everything is reliable. We know that it was the actual state at that time. You talk about any of that stuff, but the moment people see the value, they — what they want is a functional one. They know, they know more now. They want more.

Scope creep is your biggest problem. You have to have a mechanism to manage that. So, I would say all of the questions you asked here, with the exception of that last one, I’ve been asked, you know, lots of times, mostly privately. No one ever asks them publicly, you know what I mean?

Impact of Industry4.0 Community Discord Platform

I think this podcast, man, you’re going to — there’s a lot, there’s a lot of gold in here and, you know, I — you know, what I would say is this: you know, we have a huge community. You know our Discord server’s got whatever, 5,000 people in it, you know. We have, we have 9,000 students at IoT.university and 800 of them, more than 800 of them are in either mentorship or the mastermind program, right? Mastermind is where we teach what we do, teach what our architects do, you know.

That’s a two-and-a-half-year journey so far, you know teaching how to do DTMAs all nuts and bolts. You know, I don’t know how many hours of contents are on there, but I… you know, each month we meet for four and a half hours and we’ve been doing it for two and a half years, so whatever that is right, you know, 20–48, you know, hundreds and hundreds of hours of content on digital transformation.

You have to become part of a community, like you can’t do this on an island. You know, just go to the Discord server and look in the unified namespace or the digital transformation channel. You’ll, you know, Dave Schultz says, “I learn more here by accident than I do most places on purpose”.

If you want to mitigate these problems, stay part of the community, communicate, bring in the experts, you’re golden.

Kudzai Manditereza: Yeah, absolutely. I mean, I totally agree there with you. I’m always astonished just by the amount of information, in real world practical information, that I get from the 4.0 Community there because people are actually trying these things out there in practical, not some marketing piece that you’re reading from a company. It’s real people who have experimented with the technology and then they’re providing feedback, and then you get to understand it for what it really is. So, I think for me that’s really the most important thing about the industry 4.0 community. So thank you so much for keeping that going. It’s a really valuable platform for the community,

Walker Reynolds: I appreciate it man, thank you. It’s grown into, if I, you know, if I’m just being frank, like when we, when we did that I think that was in 2019, we created the Discord server mid-summer of 2019. And the idea was just originally hey it’s a place where we can just connect, you know, everybody who follows us on YouTube and has questions we don’t have to answer every question in a comment. We could, it’s just a place for us to all, everybody could just go. That grew, I never expected the Discord server to grow into what it did. It wasn’t my idea, it was Zach’s idea.

He was like, hey we need a Discord server. I said let’s do it. When we did our first Mastermind session in August of 2019, that meant that Mastermind session came from the community in the Discord. They said hey would you do like a four-hour Mastermind, we’d be happy to pay for it if you did X, Y and Z. At the time, I was still at Intellic. 4.0 wasn’t my full-time job, it wasn’t I did it was I was trying to educate in my spare time.

And then all these people showed up, you know, and then we created the mentorship program. What came out of the Mastermind was hey can you teach people how to do this to teach them the technical skills they need, what are the technical skills? And if you look industry 3.0 versus 4.0 the big thing is you’re adding in change management version control software skills in industry 4.0 right.

You need no UNS, you need no architectures, you have to have full stack fluency, you know, like in industry 3.0 you only had to be good at one thing, PLC programming or whatever, a SCADA developer. In industry 4.0 you have to have full stack fluency. You don’t have to be an expert in the whole stack but you have got to know the whole stack and you got to know what functions are there and what the pitfalls are.

So they said, you know the community said would you create this mentorship program and everything that you see at IIoT.university everything you see in Mastermind, everything you see in mentorship, all the other programs, you know we have a ChatGPT workshop tomorrow, well I don’t know when you’re going to broadcast this but Thursday the 23rd we’re doing this this ChatGPT workshop.

All of that stuff, the core MES boot camp, the advanced MES boot camp, it all comes from requests from the community. It’s all “hey would you teach us how to do this?” And then we do it. What’s amazing to me is if you look at the people who’ve elevated in the community, the guys like Jeff Schrader who went to Highbyte, Matt Paris who works at GE, if you know Mario ishigawa at Pac IoT and Dave Schultz and Kevin Jones at Ectobox, all those people in this community and originally when they first came, they came to learn.

And then they took what they learned and they just ran with it, you know. And I think the reason our Discord server works is one of the things that we do maniacally is we don’t allow any active selling.

So if somebody says, “Hey, I have a problem”, and HiveMQ is the solution to that problem, it’s totally appropriate for someone at HiveMQ to say, “Hey, our broker will solve your problem.” But HiveMQ can’t go to the Discord server and say, “Hey guys, if you’re interested, we’re doing this web… blah blah blah blah,” they can’t do that, no active selling. So all the conversations are centered around problems and solutions, and I think that’s what keeps people coming back.

Industry4.0 Influencer Lists

Yeah, but let me say this, I wanted to say this, man. Industry 4.0 influencer lists, you know, the… I got a message this morning from one of the guys, you know, the Analytica thingy came out yesterday, right? The influencers in Industry 4.0 thing, and so one of the guys who was on that list, he reached out to me and he said, “Hey man, what do you think of these lists?”

You know, he’s like, “What do you think?” He’s like, “I notice you never mention it, like you never go, ‘Hey, I’m really honored to be on this list or whatever’.” And I said, you know, “I… it’s obviously an honor to get picked to be on those lists, but I don’t know how valuable that list is. When I look at that list of people, some of the people on there who I think are incredibly influential and I mean I… you, and you’re one of them. I watch your shit, okay. You know, I didn’t see Tim Wilborne on that list, right?”

Yeah, and I think of all, if I look at any type of industry content, Tim Wilborne makes some of the best content in the entire industry, and he’s not on that list, so I don’t know how I could put, you know, put too much weight into that. But what I told this guy this morning is I said, ‘There are some people on that list I really, really respect and I love their content and I think they’re providing immense value”. You’re one of them, industry40tv. I’ve mentioned, you know, if you look back at my content, I’ve mentioned your content for years. I love what you do, man. I can’t say the same for everybody, you know what I mean, but you happen to be one of those people.

So I am constantly saying, ‘Hey, listen, you need to follow Kudzai’s stuff, you know. The stuff that he says, it’s important. He’s touching, he covers all the topics you need to be paying attention to, right?’ I think you, Tim Wilborne, Jake Hall, I love, I love Jake Hall’s stuff, The Manufacturing Millennial, there’s a lot, you know, there are a bunch of people on there that I really respect. But the conversation this morning was centered around, ‘What do you think, you know, and you’re on that list, you and I are on that list together, and while it’s an honor, you know what I mean, I put way more weight into this, this right here, this conversation.

You asked all the right questions, I mean, and I didn’t, I didn’t expect you not to, but you asked all the right questions to maximize the value for the audience, right? And that’s, you know, that’s invaluable, dude, I mean, it’s really invaluable because hell, we’ve been doing Mastermind for two and a half years. I mean two and a half years of content. I mean, there’s no way to, in one hour podcasting, teach everything, you know. So you have got to, you have to have somebody ask the right questions so that you’re giving the right answers.

Kudzai Manditereza: Absolutely.

Walker Reynolds: So anyway, I appreciate you, brother. I really do.

Kudzai Manditereza: I appreciate you too, man. Thank you so much, thank you so much.

Impact of ChatGPT on Digital Transformation

Kudzai Manditereza: Yeah, so I mean, kind of like to wind down, I think we’re way over time here, but I mean, you’ve already spoken about ChatGPT a bit, and we also spoke about it offline before we jumped onto this call. And there are many other technological developments that are currently underway. Do you have any insights into what the impact of that shift is going to be in like digital transformation going forward?

Walker Reynolds: So let me talk about the risks first. So the risks of the new technology. So let me say this, you know, ChatGPT is to me is as important a technological innovation as the internet was. A lot of the pundits are saying, you know, if you listen, hey, it’s the biggest thing since the iPhone. I agree, it’s the biggest thing since the iPhone. But I would take it one step further. ChatGPT is the biggest thing since the internet, okay? And it will be remembered as such, for both good and bad reasons, okay.

Just like the internet has had a huge positive impact on our lives, more definitely more positive than negative, but also has had some significant negative impacts on our lives. So I’m going to start with the risks. Number one, right now, because most people are ignorant to the technology. They don’t know how the technology works. Number one. Number two, they don’t know how to leverage the technology. They don’t know how to get the most out of it. It’s… there’s a lot of unknowns out there. There’s a lot of people out there who are representing like they are experts on this technology when they are not.

And the only people who know that they’re not experts are the top one-tenth of one percent of technologists, right? So one of the big risks is people listening to the wrong people, okay? That’s number one. Number two, you know, you shouldn’t share any privileged information with ChatGPT. Most people don’t understand that. If you know, say you want to use ChatGPT to help, you know, do a proposal for a project, and you copy and paste a request for proposal from one of your customers into ChatGPT, okay, ChatGPT learns from that. That’s not a private conversation between you. So if somebody asks a question later on about your customer, ChatGPT may reply with a response but with privileged information you gave to ChatGPT. Most people don’t know that, right?

So there’s a lot of risks there. There’s a lot of risk. Number three, technologies like ChatGPT are not 100% reliable. So the most valuable users of ChatGPT are the ones who know whether or not ChatGPT is telling the truth. So you want to be an authority in the space. You know, I can use ChatGPT to be a better software developer or a faster software developer because I’m already a world-class software developer. I already know how to write the code. So I know when ChatGPT screws up, and then I can say to ChatGPT, “Hey, what about line 13 there? You know, why don’t you do this with line 13?” “Oh yeah, thank you for telling me, reminding me,” boom, and then they fix it, okay.

So let’s talk about the upsides. So, those are the downsides, right? The… what are the… and there are many other downsides. Let’s talk about the upsides. Right now. ChatGPT can give you 10x to 100x return on your efficiency. I mean, and I was just doing an exercise on my team this morning, showing my team how I can do in 60 seconds what just six months ago would take us three days. So as an organization, we went from three-day turnaround on thing X to 60-second turn around, right?

So you can get 10x to 100x return on your efficiency, okay, massive returns on efficiency. Number two, you do get very smart in terms of the way, you know, you treat ChatGPT sort of like an apprentice who knows everything but is completely useless if you don’t guide them, right? So you become the supervisor of ChatGPT as a user, right? You become smarter being that supervisor, you know. So the… in terms of what you learn, it’s really staggering.

And then the last thing that I would say is, ChatGPT connects you to infra data and information that you would have to search for, you know, you could spend hours and hours and hours searching for on say Stack Overflow or in an MBA textbook, right? And you have access to that instantaneously in a form that’s consumable. So in a nutshell, everyone needs to be using ChatGPT or generative AI. By the way, OpenAI is not going to win. Let me just say this, Microsoft will ruin OpenAI. I mean it’s just… let’s just be honest about it. It’s going to be some other winner. It’s going to be some other winner, okay.

But so generative AI is probably what we should use right, in terms of a term, instead of ChatGPT. Where I really see us going is, if you see, over the course of the next three years, I mean, just by the end of this year, our world will look so different, but three years from now, generative AI will become an integral part of every single person’s life, no matter what it is you do. I mean, to the point where, you know, go to any public space and don’t look at your phone. Go to a public space, pick your head up, and look around at everybody, and ninety percent of the people are looking down at their phone and doing something, okay? And that phone is a gateway into all of human knowledge.

Three years from now, that’ll be the same thing with every single person in generative AI. Yeah, every person, every operator on the plant floor, every supervisor, every single person will be using generative AI to make all their decisions. HiveMQ, right? HiveMQ has a huge advantage in the MQTT market, in the broker market, because HiveMQ’s documentation is all wide open, right?

So it was used to train ChatGPT, yeah, and so if you ask specific questions about HiveMQ and how to work with HiveMQ’s broker, ChatGPT can give you the answer because it had access to the documentation. But there are many brokers out there that don’t; their documentation is behind a paywall, it’s behind a login, it’s behind a sign-in. And by the way, ChatGPT didn’t have access to any of that. It only has access to what’s public.

So all companies are going to make their documentation public so you’re not going to have to sign in to look at support pages. Go ask ChatGPT anything about how to do something specific on a Rockwell firmware version X, Y, or Z; it has no access to any of it because you have to log into Rockwell’s support center to get that, to get to the knowledge base. ChatGPT wasn’t trained on any of them. So anyway, that’s the big — those are the big implications. ChatGPT, generative AI, will by far have the biggest impact on our lives over the next three years? No exceptions.

About 4.0 Solutions

Kudzai Manditereza: Amazing, amazing. Yeah, so I mean, in conclusion, can you maybe tell the audience about 4.0 Solutions? What is the company about? What services do you offer and so on?

So, 4.0 Solutions is a sister company to my integration company, to Intellic Integration. You’ll notice all of our original content was Intellic Integration. 4.0 Solutions does education and outreach. So, we’re a consultancy firm. We provide architectural consulting for organizations, digital transformation maturity assessments. Our clients are vendors, OEMs, end users, and integrators. So we help everyone; all things Industry 4.0. But our primary focus is IIoT.university.

So, you can go to IIoT.university and we create educational products. And the idea with those educational products is we try to give away as much as we possibly can for free. And all of the really advanced stuff, that requires us — you know, if I got to spend forty thousand dollars to produce something — then we have to charge for it. But what we’re really doing is we’re teaching two groups of people. We’re teaching people who are going to lead digital transformation and we’re teaching people who are going to support digital transformation on how to be the best resource possible.

And that educational content continues to run. So, it — you know, as industry changes when we do a mentorship call every month or we do a mastermind call every month or we do a specific workshop, we are incorporating changes in the technology into those educational products. What I do is, I’m the primary educator. I’m the guy in front of the camera, you know? I do the podcast, I do the whiteboard videos, but the big thing is I consult.

I mean, I do a lot of like peer review for integrators. I do a lot of digital transformation maturity assessments, a lot of consulting for businesses, a lot of — I do consulting also for people like you or other integrators who say, “Hey, can we jump on a call and I want to run a couple of ideas by you?” I do that all the time. In fact, I have a guy who will be here in our office at two o’clock to do just that. And I think he came here from … he flew here from South Africa to have this call, so yeah.

So, I do that kind of stuff quite a bit. I mean, we’re — you know, we’re a pretty large organization, but we’re based in Dallas and we have lots of strategic partners all over the world. So, you know, integrator partners everywhere; the biggest ones are Gallarus Industrial Solutions based out of Ireland, Skellig Automation which is in the Hudson Valley in New York state, Ectobox with Kevin Jones, Kopar out of Mexico — you know, so we have lots of partners all over the world that we collaborate with.

Kudzai Manditereza: Awesome. So, again, Walker, thank you so much for your immense contribution to the industry. It’s really, really, really appreciated. Thank you so much. And thank you so much for joining me today for this call.

Walker Reynolds: Thanks Kudzai. It was a pleasure being here, man. I’d love to do it again.

Kudzai Manditereza: Thank you.

For a detailed summary of the key points discussed in this interview, click here:

Click here to join the Industry4.0 Discord server to learn more about the Unifed Namespace concept.