Demystifying The Unified Name Space with Ignition

Speakers

Arlen Nipper

President & CTO

Cirrus Link Solutions

Nathan Davenport

Director of Sales Engineering

Cirrus Link Solutions

Unified Namespaces (UNS) have the power to streamline OT data by breaking through communication barriers between devices and applications. By leveraging the Ignition platform and MQTT, UNS can open the door to transformative potential for operational and enterprise applications. But what even is a UNS? Join Cirrus Link as they leverage Ignition and MQTT to implement UNS and their transformative potential for applications, and share details about the core functionalities of UNS. By the end of the session you'll be equipped with the knowledge to harness the power of unified data and unlock new possibilities for your industrial operations.

Transcript:

00:04
Susan Shamgar: Hello, welcome to today's session, "Demystifying the Unified Namespace with Ignition." My name is Susan Shamgar. I'm a member of the technical writing team here at Inductive Automation, and I'll be your moderator for today. To start things off, I'd like to introduce our speakers. Arlen Nipper has been designing embedded computer hardware, software, and SCADA infrastructure solutions for 47 years. He was one of the early architects of pervasive computing and the Internet of Things, and in 1998 co-invented MQTT, a publish-subscribe network protocol that has become the dominant messaging standard in IoT, designed to optimize and make use of data for both OT and IT. Throughout his career, he's been an industry leader advancing SCADA technology. Nathan Davenport has more than 18 years of experience in the software industry. He graduated from Portland State University with a Bachelor of Science in Computer Engineering and worked for the first 13 years of his career at Microsoft. In 2019, he joined Cirrus Link Solutions as a Senior Software Engineer to focus on IIoT and the challenges and opportunities it presents. In 2023, he took on the role of Director of Sales Engineering at Cirrus Link as a technical leader and strategist for the company's sales engineering team. Please help me welcome Arlen and Nathan.

01:29
Arlen Nipper: Thank you very much. Appreciate it. Hello, everybody. Welcome to ICC. This will be my ninth presentation here at ICC. And first of all, thank Inductive Automation for all the cool stuff that you guys do. It's awesome. I mean, this show, we get to meet all of our customers, talk to them about new ideas. And a lot of what we've got in the Cirrus Link product line actually came from talking to customers here at ICC. So, really enjoy it. So today we're going to be talking about demystifying the Unified Namespace with Ignition. So, before that, real quick introduction to myself, Arlen Nipper, and Nathan Davenport. Nathan will be out here in a little bit helping me with the demo. So, Cirrus Link, we were founded in 2012. Right after that, we became a Strategic Partner with Inductive Automation. So, that has been great. So, really, when you think about it, when we started Cirrus Link, we needed a platform. We had a good idea. We wanted to leverage MQTT for industrial computing. All we needed was a platform. So, with that, really what we do is our development team works on the Ignition platform, developing MQTT technology modules to run on the Ignition platform.

03:03
Arlen Nipper: Now with that, we have a few standalone products that we do. One is the Chariot Sparkplug-aware MQTT broker, and the other is the new product we're going to introduce today, is a free MQTT client. So, we work with this all the time, and I'll go through this in a little more detail, but finally having a first-class MQTT client that we can all use as these MQTT networks get bigger and more complex and bigger and more complex going forward. Also, this is the 25th anniversary of MQTT being published into open source. So, I was thinking about that, I was...

04:00
Arlen Nipper: Yeah, it's pretty wild when I think about it, I mean, Andy and I were trying to solve a problem for Phillips 66. There was no cloud, nobody was... There was no security. Security was security by obscurity. But as I was thinking through this now, 25 years later, if Andy and I would have built a kill switch into MQTT, I figure right now there's anywhere from three to five billion clients running right now as we're talking. A billion of them. So, if we turned it off, that means there was a billion Facebook Messenger applications that would quit working, car telemetry would quit working.

04:44
Arlen Nipper: You wouldn't be able to talk to your Alexa to turn your lights on and off. You wouldn't be able to open and close your Genie garage door. So, it's pretty incredible when you think about an open technology, very understandable, very simple, and how it scaled to all of the different applications that it's in today. So, we... Kind of who's using the MQTT Sparkplug technology today. So, at this point, we, Cirrus Link, have over 2,000 discrete companies that are using MQTT Sparkplug. And if I were to put this slide up six years ago, that would have probably been 60%, 70% oil and gas. That's where we came from, that's where our customer base was at the time. But if you'll notice, where the growth is, is in manufacturing, and manufacturing really, with SCADA in oil and gas, where we have remote telemetry, we almost had to have a UNS. We had to name at least our stations and our polling where we could have everything at least on a network when we're polling down that network to have it organized in somewhat of a hierarchy. But in manufacturing, basically, it was the wild west. I mean, they were everywhere with that. And really, I think that's one of the driving factors around the whole notion of the UNS and the popularity that it's gaining today.

06:22
Arlen Nipper: So, with MQTT as an enabling technology, it's interesting that something so simple that customers start using it immediately. So, I demoed in, I think, 2015, the first MQTT module, and immediately customers started using it. But more interesting to me is what they were doing with it and how they could innovate with it. And so as we proceeded, we went from, again, the first demo that we ever did was we kind of proposed the notion of, "What's the problem?" Well, the problem is that we have devices connected to applications, i.e., protocols are evil. If I have a protocol, I have to have a driver. The driver talks to the device, brings back the data. Well, the data sets within that application. Now I want to use it somewhere else, so I have to write something else to get it out of that polling engine into something else. So, that was the problem. And what we said is that really what we're proposing, at least in year one of this journey was, hey, we should look at connecting devices to infrastructure, not to application.

07:42
Arlen Nipper: And with that, we could start unlocking some of the stranded data that was out in the field. Because, you know, in 2015, we figured that 80% to 90% of the valuable data that the company could use was probably being left stranded out in the field. Now, as we progressed the next year, we said, well, let's put some tenents out there. The first tenent is let's decouple and connect to infrastructure.

08:10
Arlen Nipper: And the second tenent was, well if this is going to expand, if we really are going to explode to the Industrial Internet of Things, we better be able to show that this is a superior OT system to begin with. Because if we couldn't replace conventional legacy poll response systems, there would be no adoption in that. So, as we move forward, we also had just started in 2016, the Sparkplug specification where we could start saying, okay, well, MQTT is pretty cool. You can publish anything you want on any topic and it's got a problem though. You can publish anything you want on any topic. So, Sparkplug came out. We started trying to define what would be the best way to use MQTT in industrial automation architectures. So, by 2017 ICC, I think we had all the ingredients that we needed to kind of, for the emergence, if you will, of a UNS.

09:21
Arlen Nipper: Unified Namespace. So, we have the three tenents now. Connect your devices to infrastructure, not to applications. Be able to demonstrate a superior OT solution, and with that be able to provide a single source of truth. And we came out with this tenent, a single source of truth. And now it's being used everywhere. Oh, we're going to have a single source of truth. We're going to have the single source of truth from the edge, and that's the only way it's going to expand. And here we said the transformation to IIoT, it won't be IT down to OT. It will be enabling OT to put together an infrastructure that's ready for cloud enablement. And I think that's where we're going. That was kind of the evolution, if you will, of UNS. So, we'll go back to the problem that UNS solves. Well, the UNS kind of solves the problem of trying to get rid of data silos and stranded data. Now, if we go back, even go deeper into kind of the origin of the problem is, we had this automation pyramid, call it the Purdue model, you can call it the ISA-95 model, where basically you started with your sensors, your PLCs, you moved up to SCADA from SCADA, you moved up to your manufacturing operations.

10:55
Arlen Nipper: Get the data up to there. Well, we kind of stopped at level three for a little bit, and well, we need to get it up to the enterprise, so we must define a DMZ level. And then we can finally get it to the business networks, and they can start seeing that data. And ultimately now we'd like to get it to the cloud. Now, the problem with this, as you can imagine, is that, we'll start at the SCADA level, is that first, from an operational standpoint, we're only getting the data that operations need. Well, the business looks at it and go well, wait a minute, you're not pulling in this other value, say, from a tank level or this other value from how long a pump's been running. A pump. The pump is there, I'm controlling it, but you're not telling me how long it's running. And operations go, well, we like the way we're polling. We told you when we put in the SCADA system that we would change our polling algorithm.

11:57
Arlen Nipper: But now that you want to, we really don't wanna do that. And then you go up to the next level and you go, well, we finally got our data up to this level we need to go down, and we need to change some other applications. And now we've got it up to the next level. So, as you can imagine, as Travis said this morning, "Dream it, do it." But with this model, you could, it's like, "Dream it, forget about it." It was never going to happen. And then we finally get to the cloud level, and I think we started seeing this about five or six years ago.

12:34
Arlen Nipper: This notion of well, I've got all my process variables down here. If I wanna get them up through this pyramid, I'll finally get them up. And then I'm going to just take my whole, all the process variables that I got and I'm going to put them in a data lake. And this is going to be the most beautiful data lake and we're going to put all of our data in there and everything will be great. And over time we'll be able to use that data and take advantage of it. And then suddenly we figure out after a couple of years that it's turned into a data swamp and nobody uses it. And we have terabytes of data that are landing in data swamps because think about it, I've got a discrete register value, I wanna go look at it, now I've got to do a query of where did it come from? I've got to do another query of, well, what's the engineering units? I've got to do another query of on what was the deadband on that measurement? And by the time they try to get this data, it just becomes without context, without a UNS, data, literally, a data lake turns into a data swamp.

13:51
Arlen Nipper: So, we get to the definition, if you will, of a Unified Namespace. And really, it's all about taking your information and getting it organized in a way that you can use it within your company from the very edge where your single source of truth is up through all of your business systems, through your manufacturing systems, so that ultimately when you get to the enterprise, everything is organized in a way that we've got contextual data. And of course, we're doing that, a lot of that with Ignition, with the ability, you know, originally it was just the tag definitions. We could organize their tags, we could give them properties, we could give them engineering high, engineering low, dampening, or deadbands.

14:40
Arlen Nipper: Then we came along with UDTs, so we could take user data types and define a model, and then that model consisted of the measurements and the measurements had the contextual information along with them. So, with that, if we could take that, imagine if we could have that context all the way at the edge where the engineer defined the equipment and get that all the way up to the enterprise, all the way through the SCADA, then we literally would have a UNS. So, as I think about it, really kind of how this all came evolved, if you will, is that with protocols we got registers and we could define them, but they always were kind of standalone. When MQTT came along, we had to, is the nature of MQTT, we had a topic and a payload, and the topic again, by its very nature became hierarchical. You could use slashes and so you could have, I still remember Phillips 66, 1999. We probably had the first properly named UNS, if you will. If you go by the ISA-95 hierarchy, we had a pipeline. You know Pipeline 1. In Pipeline 1, we had booster stations, Booster Station 1, and booster stations we had PLCs.

16:08
Arlen Nipper: And then PLCs, under that we had flow computers. So, we had this hierarchy by the very nature of how MQTT worked and how we were getting that into an organization. So, from Walker Reynolds, to David Schultz, to Matthew Paris, everybody's had really good ideas now of leveraging what you can do with MQTT, but do it in a way that we can have that UNS go all the way up to the enterprise level. So, here's my Phillips 66, 1999 UNS. Now, one thing that kind of comes up in conversations when I'm on with the customer and go, "Well, Arlen, we've got our broker here. So, that's our UNS database." And remember that an MQTT broker is just for routing messages through your infrastructure. It is not where all of your historical data is. So, I just wanna point out here that if you put all your tags into an MQTT broker and you set the retain flag on all the tags, all you're going to get is last known good. So, within a UNS architecture, we still have to think about where is our UNS database going to be in that whole architecture.

17:35
Arlen Nipper: So, a lot of you, I think I've done about 200 Snowflake demos here since we introduced Snowflake last year at ICC. And this is kind of the architecture drawing that I've used in all 200 of those demonstrations. You can see where we've got this notion of Ignition, Ignition Edge, native devices like Opto 22, like Phoenix Contact, they can do Sparkplug B and being able to take the edge of network and publish that up to an MQTT broker. That engine is subscribed to on an Ignition gateway. And from there we really start using Ignition as the enterprise connectivity platform to create a data model i.e., a UNS, instantiate that, creating our digital twin. Now, I hate that word "digital twin." It has so many connotations you can't...

18:36
Arlen Nipper: But the difference here is we try to do... If you look out there, AWS has digital twin technology. Microsoft Azure has digital twin technology. Google has digital twin technology. But the problem is those digital twins are the way that they thought you should do a digital twin and they probably don't know what you do. And the interesting thing with what we can do with UDTs and Ignition is those are digital twins, the way that we as you, the customers use it. And that's the way that you can start leveraging really a digital twin using Ignition UDTs and then of course still keeping track of our real-time data. So, the digital twin that I create on Ignition Edge out in the field can be published to an Ignition gateway automatically. I don't... It's automatically that UDT is published up. We discover that, now I've got the UDT there. Now I can point that at a transmitter that goes to a broker that's connected to the Snowflake, the IoT bridge for Snowflake. And now going into Snowflake we literally have that UDT recreated where we can take advantage of that.

19:56
Arlen Nipper: So, that becomes really... Snowflake is really the kind of the ultimate UNS database so that you can go back and get all the historical data, but you still have all the real-time contextual data there as well. Now just to go into a little more, we are listening. So, over this year, last year we've had a lot of requests and we've added some features to Engine, Transmission, and Chariot that customers have been asking for. So, first thing is that the UNS enablement of MQTT Engine. Now what we did was as you know, if you can have edge devices again, you could have Ignition Edge and all of the native devices again, the Advantechs, the Opto 22s, the Eurotechs, the Phoenix Contacts, publishing that information into Ignition.

20:56
Arlen Nipper: Now we've got to keep track of that, that's an individual edge node and we've got to keep track of the metrics and that's the namespace that came in. And then you've got another edge node and this could be in a factory, another cell. And when you display that in the MQTT Engine, you've got all that information, but it's not really the UNS that you wanted. You would like to collapse that so that you could truly define that and have it all together by the time you get it to Ignition. So, what we have here is Edge Node 1 and Edge Node 2 and they're both going to connect to a broker, start publishing information and those are going to flow into Ignition in an MQTT Engine. Of course, you're going to have your Sparkplug view of G1, D1, E1, ACME Inc. Stillwater Coyote properties for my Coyote Property for Wile E. Coyote. And then we have our Anvil Production Plant and then down to the actual UDTs. And that's all good. But what I would like to do is have it in a new UNS view. So, now in Engine you can set it up and say, "Okay, I know you're going to have all the Sparkplug metadata there, but what I wanna deal with is a UNS view."

22:21
Arlen Nipper: So, now we can go in and start making really clean view right in Engine. You don't have to do tag copies or anything like that. Is that, that will show up in Engine exactly the way. So, think about it, what we're doing is obfuscating the group Edge Node ID and we're presenting at a hierarchical namespace just the way that you named it. So you can start having all of these edge nodes contributing to a single UNS.

23:03
Arlen Nipper: Okay. The second thing is a lot of customers have, especially in manufacturing, they have it set up where they're familiar with MQTT, but they have small devices, Raspberry Pi's, they've got very simple MQTT clients and they would like to connect their clients to a broker just to get some of the information that we can publish out of Ignition. So, with the Transmitter module now, you've got the ability to point to tag providers, folders, individual tags, and literally publish those one tag per MQTT message. So, in here I'm showing that we've got ACME Inc. Stillwater Coyote, Anvil Angle, JSON payload of a value and a timestamp and those can be published on retain and you can choose to publish the properties as well.

24:02
Arlen Nipper: So, you get the engineering units, engineering high, engineering low, those will be setting there in your broker so that as other MQTT agents come or clients come around and they connect to the broker, they're going to immediately get last known good. And then they can subscribe just to the data that they want. Maybe they just wanna subscribe to the Anvil Angle and that's all they wanna subscribe to. So, they don't have to be aware of Sparkplug and they can get very granular in how they actually use MQTT at that level. Now we've given you a double-barrel shotgun and you can shoot both feet off. So, this is going to create a lot of traffic and a lot of... If you can imagine if you had a million tags and you're going to retain all of those in a broker. That's probably going to blow your broker up. But we do have a lot of customers wanting this feature to be able to start really going out and getting very granular in the way that they can subscribe to topics that are coming out of Ignition. Number four. Oops, I think I skipped over one.

25:19
Arlen Nipper: Got them out of order here. Number four. For the last seven years people have been wanting to do alarms over MQTT. So, now with... And we had to have some infrastructure help from Inductive Automation and Inductive, thank you very much. But now we can generate alarm at the edge, publish that into Engine and then at Engine we can acknowledge that alarm and take it all the way back.

25:54
Arlen Nipper: So, now you can. Thank you. So, now you can use MQTT as your single secure connection into a hub-and-spoke architecture. And finally, I probably should bring Nathan out about this time. Nathan basically isn't all... Gets a lot of the customer calls where we're starting to design something or get into a debug situation where we've got different kinds of brokers, different kinds of clients out there, and we're having to debug them. So, we are announcing here at ICC that we now have the Chariot MQTT Client.

26:37
Arlen Nipper: So, it's free. Uniquely, you can subscribe to multiple MQTT servers. I think all of the other very simple MQTT clients, you can just subscribe to one broker. But when you're trying to solve a complex problem, you wanna subscribe to multiple brokers.

27:00
Arlen Nipper: Of course, it's got a built-in Sparkplug decoder, we can publish messages from it, and again it's free. So, if you download Chariot, which is our MQTT broker, the client is part of that, and you don't have to use Chariot broker at all, but you can run the client, and you can use that for free. You'll be able to download it as of today, I think. Right, Nathan?

27:26
Nathan Davenport: Yes.

27:27
Arlen Nipper: All right. So, with that, we are coming to the demo. So, I figure after eight years of doing live demos and never having a problem, I was probably pushing my luck. So, if we have a problem, I'm going to let Nathan demo it today.

27:57
Arlen Nipper: So, and I know a lot of you know Nathan, the guy is just incredible. He can, man, he can debug anything. So, really, what we're showing here is that we've got... It doesn't show up on the screen, it's being cut off. We've got three actually, hit escape on there. It'll show up. There we go. We've got three edge nodes publishing data. They will be publishing data. They're set up in a Unified Namespace that'll be going to one broker up into Engine to Ignition. From Ignition, we've got Transmission, where we'll be using the new feature of the UNS transmitter to transmit some of these tags out where you can subscribe just to individual tags. And then we've also got another transmitter going to another Chariot broker, going to IoT Bridge for Snowflake. And then ultimately, we'll get the entire UNS into our Snowflake data cloud platform. So, Nathan.

29:00
Nathan Davenport: Thank you, Arlen. Hi, everybody. I feel like every time we do these demos, Arlen makes them more and more complex, as you can see by the topology diagram. So, hopefully, the demo gods will cooperate today. We'll see. We'll see who's pushing their luck. All right, so as Arlen said, you see, we have three Edge gateways here. They're all hot. They're all connected to Chariot MQTT Server 1, and they're waiting for MQTT Engine here on the central gateway. Let me select it here so you can see, to come online, publish a state message on the appropriate topic. And that's the trigger that's gonna tell these gateways and the Sparkplug transmission clients, now is the time to go ahead and publish your birth messages and subsequent data messages. So, let's pivot over here to the Engine gateway. You can see it's disabled right now. And I'm gonna pivot back over to... And somewhere in here in the central gateway is MQTT Engine. Now, I have no UDT definitions here at all. I have no tags in the traditional Edge Nodes folder, and I have no UNS namespace. So, I'm gonna go turn on MQTT Engine, and you're gonna watch all the data flow.

30:23
Nathan Davenport: Let me get back to the topo diagram. From the three Edge gateways single source of truth all the way up to Engine. And we will take that single source of truth, that single stream of data, give you your standard edge nodes view with the Sparkplug overlay. And then we're also gonna give you the UNS hierarchy and topic namespace with that overlay removed. So, we go turn on MQTT Engine. Give it a second or so. That's about all it takes. And here, you can see your traditional... Oh, sorry. Trying to full screen, but that did not work out, so let's try it one more time. And here you can see your traditional Sparkplug nodes laid out much as you would expect them. Your group, your edge node, your device, and then your UNS namespace, right? So, as we drill down through your UNS namespace here, we're gonna go just a little bit deeper so that you can see that these tags here are in fact under the standard Sparkplug edge nodes folder with the Sparkplug overlay, and they're updating now in real time. And within your UNS namespace, you have that Sparkplug overlay removed.

32:01
Nathan Davenport: All right. We start at the enterprise, site, the area, and so on. So, we give you both copies of these tags, the Sparkplug overlay, without the Sparkplug overlay. And these tags very much behave just like you would expect them. If you were to write to this load tag, for example, that's going to send a Sparkplug command message down to the edge. Transmission's going to unpack that, write to the tag, that's gonna create an OPC UA right down to the PLC, and that write is going to bounce back all the way to Engine, and this Engine tag is gonna update. So, let me prove to you that this is actually working. The load's gonna go from 44 to 46 let's say. You see it go all the way down, come all the way back. Now, this is the perfect time, I think, to go ahead and demo alarms across MQTT. So, I'm not gonna show you the alarm at the edge, but Arlen went ahead and put an alarm on this load tag at the edge, and once we cross a set point of 50, I believe.

33:11
Arlen Nipper: 50.

33:13
Nathan Davenport: That alarm's gonna fire. So, let's say all of a sudden our load jumps to 51. This alarm that you see here came all the way from the edge all the way down to Engine, and then we basically via Engine, wrote it into the alarm status table. So, from here, from the Engine side, we can go ahead and acknowledge this alarm, which is then gonna fire another command back down to the edge to acknowledge it at the edge. So, let's do that. So, the alarm's been acknowledged. Now let's say that the load drops back down below our threshold. You'd very much expect this to be cleared. So, we drop down to 40, let's say. Well, 40, let's say. And that alarm has been cleared. You can see it here in the table. We've cleared that alarm. We have alarms across MQTT. You guys have been asking. We finally brought it to you. Thank you.

34:25
Nathan Davenport: Like Arlen said, it took about seven years and a little bit of help from Inductive, but we got it finally. All right, so let's. Oh, and I probably should have showed you as well that of course we have your UDT definitions over here as well. We can't create the instances without the definitions. You get all of that single source of truth. Let me pop back over to the topology diagram. So now, what I'd like to show you guys next is, we're gonna turn on Transmission here on this gateway where we also have Engine. We have a traditional Sparkplug transmitter. It's gonna push your data up through MQTT server number three, through the IoT Bridge for Snowflake into your Snowflake back in that Sparkplug Protobuf. And then we also have another transmitter. I'll show you the transmitters here in a second so we can kind of anchor you in, in reality in the product itself. We have another transmitter, UNS transmitter, specifically configured to consume the Engine UNS tags. So, let me show you what I mean. Pivot back over to Transmission. We're not enabled yet. You guys know what a traditional transmitter looks like. This is the transmitter right here going to Snowflake.

35:44
Nathan Davenport: It too is picking up the UNS tags, but it's Protobuf encoding them, while the UNS transmitter also pointing to exactly the same folder. But what we're gonna do is we're gonna shred these tags. We're gonna publish out one message or a message per tag on a topic that is the full UNS path all the way down to the leaf tag. So, now you have full control for consumers of your data. Maybe one MQTT client wants to simply consume the load tag, maybe another wants to consume the angle tag. And let me also show you that there's no data here in our Snowflake backend as well. I'm gonna refresh it just so you believe me. These three schemas here or folders are sourced by the bridge, produced by the bridge, but we should be seeing our ACME INC. schema folder, all of its views, all of its UDTs, all of that. We don't see it yet. We're gonna go here, we're gonna turn on Transmission, and we are going to publish this data out. So again, let me pop back over to the topo diagram. So, how can I convince you guys that the UNS transmitter publisher, has in fact published all of those tags, one topic per tag? Well, we're going to use the free client that we built for you guys, the free MQTT Chariot Client, to basically view this data at the server.

37:24
Nathan Davenport: Okay. Let me see whether my session has expired yet. So, we're gonna refresh just to be sure. I'm gonna turn this server on. It's not actually accepting connections yet. Now it is. And here is the MQTT Client built into the Chariot server. Looks like we need to connect to localhost, and we do. So, I have the Chariot Client here connected to localhost, this server right here, MQTT server number 2, and the MQTT Server 3, the server that's serving up the tags to Snowflake. Sparkplug data. So let's go back. Real quick we'll pivot through this view. Looks like we have an active QoS 1 subscription on hash. If I go over here into the topic tree viewer, you can see we're connected to both servers. We have the top server and its topics. I'll expand them here in a second, showing you the data coming into Chariot server number 3, the one all the Snowflake data is flowing through. And then all of your UNS data is here on the local box. And you see your UNS reconstructed here. And as we drill down through this topic namespace, you're gonna find exactly the same data that you would be seeing in Ignition right now for these tags.

38:56
Nathan Davenport: So I turn on most recent, just so we can stick on angle. And every time the angle tag updates and the UNS transmitter publishes out a message, we're gonna auto-update the JSON payload down here. So what are we giving you? This payload at the very bottom is updating, I don't know, about once a second. We give you the qualified value. Timestamp, quality, an actual value. We give you the data type, and then we give you the full UNS path all the way down to the tag. You can retain it, publish on QoS 0, 1, 2, whatever you guys want to do. It's completely up to you. Like Arlen said, be a tad bit careful. If you got 20 million messages, it could be a little bit heavy. And now imagine if you also wanted the properties for that tag. So you guys remember possibly that Sparkplug is going to push all of the additional tag metadata. Things like engineering units, engineering high, engineering low, tooltip documentation, all that stuff comes in a birth message. But this is in Sparkplug. So we had to give you a way of retaining these properties. So as you can see here, we will also give you the ability to go cherry-pick out the metadata around a tag as well.

40:06
Nathan Davenport: Here in this example you've got engineering high and you have engineering units. So at this point now you can lock consumers down to topics, and they can consume one tag only if you want, or however many tags that you may want them to consume. Okay, and then as you can see here, the rest of your UNS is here as well. We got a little bit more time here, so I'm gonna show you a couple more things before we pivot over to Snowflake. Along with the connections view and the topic tree viewer, we give you the ability to subscribe to any topic you want and maybe publish out a message. So let's say, hey, we want to publish out a message on, I don't know, how about Arlen/Nipper with "Hello ICC 2024!" Bang. So I'm gonna publish that out there. I think I saw it, but things are streaming so fast. I can't quite tell. There it is, there it is. So we're gonna give you the ability to connect to multiple servers all at once, stream that data through, give you the topic tree viewer, give you the ability to publish out raw messages when you want to.

41:15
Nathan Davenport: I'm hoping here in the near future we'll get you a Sparkplug simulator into the publish side of this as well, so you can kind of simulate your own Sparkplug devices. Not here yet. Coming soon. Now we got to pivot over to Snowflake. I'm gonna refresh this view. Now here is the schema or the folder that contains all the views for ACME Inc. But before I go show you those views, let me show you where you find your UDT definitions, your models within Snowflake. The models are what we use to dynamically create the views such that we can hydrate them properly. So, if you scroll down into the views here, into the Stage_DB schema, there is a node machine registry. And if we preview this data, you'll find every UDT that was on that Engine gateway now up here in Snowflake on the cloud. You have your full context, your full UNS path, and there's all of your machines, your palletizer, your wrapper, your stamper, your drop test, your paint booth, your grinder, and a few other models there that are injected by the bridge themselves. Now, if I drill into the ACME Inc. view here, and let's say we drop into... Oh, how about the grinder, I think, and we preview this data.

42:36
Nathan Davenport: Here is all of your live tag data in Snowflake. Full UNS. It's still here. Yeah, we've stitched through the Sparkplug IDs, but your full UNS has been rehydrated here on the Snowflake side. And if I scroll all the way to the right, you'll find all of your UDT member tags as columns in this particular view. Let's pop back to the topo diagram. Again, a single source of truth. Three Edge gateways. In a couple of seconds, we can go all the way up through Engine, build you out your UNS, unroll that back out into another server via the UNS publisher, send data all the way up into your Snowflake Historian backend database in a couple of seconds.

43:28
Arlen Nipper: Awesome. Thank you, Nathan.

43:30
Nathan Davenport: Thank you.

43:36
Arlen Nipper: You made it through one.

43:37
Nathan Davenport: Woo. Nine more to go. And you can bet they're gonna get more and more complex too.

43:43
Arlen Nipper: That's right. That's right. So, I guess we're just about out of time, so if there are any questions, I think we could take a few and then we can call it a wrap.

43:54
Nathan Davenport: I think so.

43:55
Audience Member 1: I have a question on the Ignition Edge. It looked like you're just publishing the Sparkplug metric at that point. So, I noticed that your group edge node and device were G1, E1, D1.

44:05
Nathan Davenport: Correct.

44:06
Audience Member 1: And that's just getting stripped. So, when I bring it into the Engine in that middle one.

44:10
Nathan Davenport: Yes.

44:11
Audience Member 1: Okay. So, that's what's happening. So, that becomes the UNS piece.

44:14
Nathan Davenport: Exactly.

44:14
Audience Member 1: Okay, perfect.

44:15
Nathan Davenport: We still keep the context of where these particular tags in the UNS layout come from. We actually will have custom properties on those tags that'll tell you what your group ID, your edge node ID, and your device ID are so you don't lose context. But we remove that overlay to give you full UNS flexibility.

44:35
Audience Member 1: Okay, perfect. Just want to make sure I saw what I thought I did.

44:39
Nathan Davenport: You did.

44:40
Audience Member 1: Second one is that UNS transmitter. It looks like that's just using what used to be like the system.transmission component. So, it's flattening things. It's publishing a flat.

44:49
Nathan Davenport: Yes, it is flat, and it is similar to the Transmission, but we leverage the same code, our underlying agent code, that we use in the Sparkplug transmitter within the UNS transmitter.

44:58
Audience Member 1: Okay, perfect. Just want to make sure I understand that. The third thing is a comment. Does Rick Bullotta know what you just did?

45:03
Arlen Nipper: I hope so.

45:04
Audience Member 1: Yeah. There you go.

45:05
Arlen Nipper: Rick if you're watching.

45:07
Audience Member 2: Great products. You guys are awesome. But I have a question. So, your Unified Namespace. I mean, correct me if I'm wrong. It can filter out a lot of the stuff that's higher up in the tree so users only see the important parts that they want to see. What if I change my structure that I'm transmitting? I change a folder name or whatever, does that break everything or does it still work? How do you handle that?

45:35
Nathan Davenport: If there are no collisions, if you make a tag a folder, or a folder a tag, we have a hard time kind of resolving those types of collisions, if you will. But if you're simply adding other folders and so on, they should just pop in right in the middle of this UNS structure and it should function much like you would expect it to.

45:52
Audience Member 2: What if you delete, though? You change something.

45:55
Nathan Davenport: Worst-case scenario, what you do is you probably come back over to the Engine side, you'd blow all those tags away, you'd refresh from the edge, and we'd recreate that UNS in milliseconds from the ground up.

46:05
Arlen Nipper: And we've talked about this back and forth. 50% of the people we talked to say, "Oh, you should delete it." And the other 50% said, "Hey, just stale it." So, the customer did know it went away, and then he can go and delete it. So, we went with the staling.

46:21
Arlen Nipper: And that's all the time that we have.

46:22
Susan Shamgar: I think we have time for one more question.

46:24
Arlen Nipper: Okay, one more.

46:26
Audience Member 3: So I'm just trying to wrap my head around it a little bit more. Is SPB-V1 still there in the background, or is it like...

46:33
Arlen Nipper: It can be. But once we... In Engine, if you select the fact that you only want a UNS view, then you'll have metrics on G1, E1, D1. But those will only be for debugging. But the actual namespace that we created does start at ACME Inc. And so there's nothing. It's gonna stay that way.

47:01
Audience Member 3: So, then bridging that namespace should be a cakewalk.

47:03
Nathan Davenport: Yep. Should be. And as you can see it here. Just as Arlen said, for the UNS publisher, we strip off those pieces, and we republish on the full UNS topic. So this is the topic that the UNS transmitter's publisher is publishing.

47:14
Arlen Nipper: Well, I think he means the, in Engine, your UNS, the actual UNS tags.

47:20
Nathan Davenport: Ah, got it.

47:22
Arlen Nipper: Yep.

47:23
Audience Member 3: Thanks.

47:25
Nathan Davenport: Good question.

47:26
Susan Shamgar: All right, great. Thank you so much. And can we have another round of applause for Arlen and Nathan?

47:30
Arlen Nipper: Thank you, everybody. Good job.

47:37
Nathan Davenport: Thank you, sir.