Jeff Knepper 0:02
Jeff, everybody, how are you? Are you ready to end day one? I am ready to end day one, if I'm being honest. Thank you for staying behind. Thank you for being here. My name is Jeff Knepper, and I am your reluctant Fireside Chat host. Thank you. I have got a distinguished group of panelists beside me, let's go. Matthew Paris, Matthew is the Director of Advanced Manufacturing for GE Appliances. Beside him, Jonathan wise, Jonathan is the Chief Technology architect for sesme. If you don't know who the gentleman on your far left is the exit door.
Jeff Knepper 0:46
Can I get a round of applause for Arlen Nipper?
Jeff Knepper 0:54
And I think that rounds out our group, right? All right, so I thought we'd start out with a little bit of fun. I'm just curious. Do me a favor if you would. Can we thank ecudine for sponsoring this event? Ecudine,
Jeff Knepper 1:21
out here. Constantine, are you here? Where are you? Constantine, thank you so Constantine and ecodyne. They are the architects of the UNs chat bot, and that helps you run your factory. Literally, by talking to it, you can get a feel of what that looks like. I'm sure they're ready to show you a demo. They are over at Booth 22 echo done. Constantine and the team the chat bot, go check it out, please. Thank you. Constantine, yeah, absolutely. Thank you. Now we're going to have a little bit of fun. I need you to scan the QR code. It's going to unlock a little quiz for you, as you're doing that, I want you to think about your first worst job. Very few of you, very few of you came out of engineering school and just started slaying it. I was a dishwasher for a summer at a church camp. I was up to my elbows in spaghetti plates. It was gross $5 an hour, but amongst our esteemed panelists, we have quite the sordid history of terrible first jobs, and I would absolutely love to see what you think based on our panelists who spent 500 miles of paint, painting, pipeline, road crossings.
Jeff Knepper 2:49
We're really leaning hard on Arlen.
Jeff Knepper 2:53
Okay, that was a give me. That was a give me fair enough. All right, I think we all know it's Arlen. So Arlen that was from Medford, Oklahoma, to Houston, Texas, to mount Bellevue. You. You hand painted pipeline cross, cross. Words,
Arlen Nipper 3:07
yep, okay, cleaned all the weeds out, painted the post and drove to the next pipeline crossing. All right, somebody's got to do it. Somebody's got to do it.
Jeff Knepper 3:18
All right. Next question, please do
Jeff Knepper 3:23
who went now we're not going to reveal the answer on these next three until the end. Who do you think went from McDonald's drive through greeter, order taker to pinball repair man? And this is what jump started their career. By the way,
Matthew Parris 3:43
this looks like an AI chat bot trying to figure out confidences.
Jeff Knepper 3:48
I like it. I like it. All right. Five seconds, you're not going to reason this out. Go with your gut. All right. Let's go on to the next question. I
Jeff Knepper 4:03
who manned the prime rib carving station at the local country club. And bonus, that was Friday night. Sunday they were flipping omelets. That's cross discipline training.
Jeff Knepper 4:21
Interesting. Jonathan, they like you with a carving knife.
Jonathan Wise 4:24
I like some prime rib.
Jeff Knepper 4:30
All right. And final question, this is my favorite. Who started as a Taco Bell mascot, and by the way, this was on center this was on center ice at the hockey rink, but quickly pivoted go figure to doing computer repair for grandmas. All right, so with the with the panelists who started off with. If that beautiful smile and award winning personality at McDonald's turned Pinball Wizard, please stand up. It is me,
Walker Reynolds 5:15
and I will say that my certification as a pinball repairman was in five volt DC systems and learning how to read IEC drawings, which is the reason my supervisor at Cargill sent me to fix that roof bolter, because the drawings were in German and they used the IEC standard. And I went with the electrician and fixed the roof bolter. And that was the beginning of my career. There you go. Okay, go standard.
Jeff Knepper 5:47
All right, so that gives you two choices. Is it going to be Matthew or Jonathan? I have to know who was the Taco Bell mascot turned grandma it repair professional. Was it really so my question is, what does a Taco Bell mascot look like? Tell me it's a Chihuahua.
Jonathan Wise 6:11
No, it was a giant taco. Yeah.
Jeff Knepper 6:18
Well done. Hey, listen, just you want the you want, the little motivational inspiration speech from this little bit of knowledge, no matter where you find yourself,
Jeff Knepper 6:27
it could be worse.
Jeff Knepper 6:30
No, but seriously, take what you have right and do something with it, from painting pipelines to automating pipelines to inventing, frankly, the protocol that has us here today to organizing why we're here today based on what you learned in a hobby, turn career, IT background certainly serves you well. I'm still trying to connect the omelet GE Appliances, of course. All right, so hey, listen, we have a goal today, and it's to talk about data standards and their role in your day to day lives, what they mean for you as you're trying to go through a digital transformation. How could they can help and how they can hurt? But I think it would be really helpful before we start that we just define some terms. So I want to float a couple terms to the group, and then I just want you to speak to how you would use that term to explain it to how about a freshman engineer or a junior engineer right out of college? And we're going to start with, what is a namespace? What is a namespace?
Arlen Nipper 7:40
Anybody care to go? Well, I mean,
Arlen Nipper 7:44
ultimately that was the cool thing about MQTT is that, when I look back at it, you had to have a topic to be able to publish your data. And even though one of the radical things about MQTT is, okay, it's on TCPIP we're not polling anymore. We can just push stuff out, report by exception. That was great, but really what came along with it was the fact that, okay, I got a piece of data, but I got metadata in front of it, and really that was the name space. And we kind of took that for granted for a long time, I think, until we it started percolating down that, oh, well, if we organize that right, we can make a uns. So really, not so much the names, but when I think about it, was interesting. Phillip 66 we had a, basically a uns, because when we did we had pipeline one, pipeline two. We had booster station one, we had pump number one and the PLC number one. So we had a mini, basically uns, even when we did mtgt For Phillips in 1999
Walker Reynolds 9:01
I always describe the namespace as the thing. It's the representation of a organization of data, but the model is irrelevant. It is the place it lives within its representation. So it's the thing inside the brackets. I always say it's or it's the thing. It's the it's the object, the sub object inside of a JSON. Excuse me, but the name space is supposed to tell you it's representation within relative to other data. That's what I always say.
Jonathan Wise 9:37
I would modify it just a little. We use namespace as the declaration of the definition of the data. So what's really important is that although the data may travel with its namespace, the namespace is the definition independent of any one expression of the data, independent of an instance of the data. So
Jeff Knepper 9:57
if I if I could say it back to you. So I can understand a namespace without ever understanding a value of data
Jonathan Wise 10:04
Correct? Yeah. I can infer a namespace by looking at key value pairs, but I can independently understand a namespace by looking at its definition.
Jeff Knepper 10:15
Yes. So then, what about a What about a data model?
Matthew Parris 10:22
Data Model take a stab at that is objects that have members tied to those objects. And so data model is you're creating this entity that would then reside within a namespace. So a namespace is going to collect all your objects together, and those objects have certain definitions for them, and so the you're going to have object definitions, think of them like class definitions. When you're if you're programming code, you have your class definitions, and then you're instantiating them within namespaces.
Walker Reynolds 10:51
And what's important to note about data models is that they are limited to events that can be associated with values and moments, and when those values transferred, transitioned, as opposed to informational models, which give you context where you can make decisions.
Jonathan Wise 11:08
I like that distinction. Typically, we would define the data model as being more primitive than the information model. The information model is enriched with the context the data model exists, but it's an information model. When we have that complete context, you can't
Walker Reynolds 11:25
have an information model without a data model.
Matthew Parris 11:27
Correct. John, maybe data model UDT, right. Information Model is going to be higher up the stack.
Jeff Knepper 11:32
Oh, so using the using maybe, if you were familiar with ignition, a UDT at its base, base would be a data model correct
Arlen Nipper 11:42
right before it's instantiated. Once it's instantiated and you put a topic namesake in front of it, now, now you're publishing that into the UNs.
Jeff Knepper 11:51
Okay, Jonathan, I think if I if memory serves, three years ago, at a sesame event, I saw an example of a data model almost being like the name plate of a piece of equipment.
Jonathan Wise 12:05
Is that accurate? Yeah, that is a data model, yeah. And it would need to exist inside a larger information model. Just a name plate. Isn't that useful unless I know what it belongs to and what it's doing. But, yeah, I think that's fair. But capacity
Jeff Knepper 12:19
or a horsepower, sure, but not a production for the last hour.
Jonathan Wise 12:24
Yeah, yeah, not current horsepower, but rated horsepower, yes. Okay,
Jeff Knepper 12:31
data standards,
Jonathan Wise 12:35
I'll go first. So there are standards and then there are standards, right? So Walker referred to an IEC standard for pinball machines. So that's the highest level of standards, typically international standards agreed on by a standards body, arrived at via consensus and available, hopefully, to a wide array of users. But data standard could have a lower bar as well, which is organizationally, this is how we have decided to structure or name our data. So there's a ton of kind of synergies or similarities with a uns.
Matthew Parris 13:16
Yeah, data standard, I think, is going to take multiple contexts based on where you're talking about it. So you could have within your own organization, you have a need for a standard. And I would say this, the need is, anytime you have an interface between two things. So they could be two organizations in your company, where one is producing information or data, the other needs that information. You need a standard of this is what I need to produce to then consume. And if you change that standard, then you're going to break my consumption of it. It could be a definition, an interface that's defined between your organization and an outside organization, if we talk about digital supply chains, or supply chains that feed you material, and then you're producing parts that are being downstream. You may need to communicate information or data to those as well. And if you don't have a standard, you're going to find yourself in trouble pretty quickly when somebody makes some change.
Walker Reynolds 14:13
At its base level, a data standard is the rules and options for consuming, producing, structuring, and then sending and receiving data across the wire correct at its base level. So that, I mean, if we didn't have one where we had cell, hard wired phones, which you guys are probably not, you're probably the one who looks funny with a rotary dial phone, like you don't know how to use it. I do remember how that worked, but you know, that was all a series of switches, right? It was just, you know, when we and it was, click, click, click, click, a series of switches without a standard. Then there was no way that you could take a phone, put it on the wire and turn the rotary and. And have it communicate to the switch the number you were trying to call. So I think we complicate data standards too much. Where we really get into, you know, protocol standards are where things get complex. You know, data standards are pretty
Arlen Nipper 15:16
eyes, you know, before MQ, tt, I sit on the heart communications Foundation,
Walker Reynolds 15:23
one of the greatest, by the way, one of the greatest protocols, in my opinion, exactly, exactly.
Arlen Nipper 15:28
But nobody uses it right, right? So you talk about digital transformation in the fact that we've got 234, 100 points of data in a heart smart transmitter, and we're leaving it stuck out in the field, and we bring a four to 20 milliamp signal back. And that's my point. That was my frustration with the Heart Foundation is like they were so entrenched and it was so specific that it never got out to the public. Right? So there's, there's the problem of a data standard or protocol that's out there. It's the greatest thing since sliced bread, but nobody uses it.
Matthew Parris 16:11
And I think standardization really you need to look at, what are my interfaces, where I need a standard. I think the idea, or the way you're just we need to standardize for standardization sake is not a good approach. I think you'll you're going to create this initiative that's too heavy and it's going to die under its own weight.
Walker Reynolds 16:30
I'm a huge fan of,
Walker Reynolds 16:34
you know? I'm a huge fan of The Walt Disney philosophy of standardization. Right? When Walt Disney created Disneyland, which was the only Music Park he ever saw. Some of you heard the story, but the team asked him, Where should he put the sidewalks, and where should we put the sidewalks in Disneyland? And he said, we're not going to put in sidewalks. We're going to put in grass, and we're going to wait a year, and then wherever the path is beaten down, we're going to put in sidewalks. And I agree, I believe in that philosophy, that where we should standardize is where the path is beaten down. And when we have a conversation about, where are we in, in the need for standards in IIoT and industry four and uns, i My opinion is that we're still in the primordial soup stage. Maybe a little asset, some elements have bubbled up and create, you know, we have carbon and we have helium and we have hydrogen, but we're not, we don't have the full periodic table yet. And the question is, how many elements do you need before it's time to start standardizing? And I think we're pretty close. And I think the work that you guys are doing right now, which I hope we we touch on at some point, is, is very important work.
Matthew Parris 17:46
Yeah, and I would say data standards. Let's talk about a very one, that we all use the internet, right if we want to go get information from the entire world. We all know how to go do that. You open up your web browser and your computer or your phone, type in that URL, and then you immediately have information. We don't have that as an industry today that does not exist. If you talk to any integrator and they're brought into a customer and help us solve our problem, the first question there says, Well, how can I get at your data? Maybe, if the integrator is lucky, there's an API that they can get to. Maybe there's some protocol, like an OPC, UA or an MQTT, or, for heaven's sake, Modbus, that's all that there is. Or maybe it's just hardwired IO. But the fact that we're even having to ask that question 30 years after we have standardized how to get information from the entire world is ridiculous in my in my mind, and I think it's time that we all agree on this is how we're going to get information from software that's at this certain level of the stack, and then be done with it so we can move on and solve really interesting problems. If I
Jonathan Wise 18:54
could, I'd like to torture both of your analogies. So I love the idea of, like, paved the paths people are walking on, I think. To torture that analogy further, Disney also famously had a monorail, and there had to be a standard in place for that train to fit on so it could travel down it. So there are cases where we take advantage of a standard that already exists. To take your analogy a little further, HTTP and HTML gave us the internet and massively accelerated technology, but it also breaks down when systems need to interchange data, because HTTP and HTML only go so far in describing the data that may be transmitted over the wire. And after those 30 years, now we have llms beginning to make sense of a massive corpus of unstructured data. So there is a place where we need to use standards that exist, even if they're not perfect. And I deal with that every day. Lots of standards aren't perfect. Perfect, but they are accelerators that can let us move on to other problems that actually matter. But
Walker Reynolds 20:06
it is imperfection is okay as long as it's not prohibitive. My argument has always been, I'm okay with an imperfect standard, as long as me working with an imperfect standard doesn't prohibit me from a solving the problem and B innovating. And I think where, where we get into the area of the semantic, the war, the protocol wars and the standards Wars is when one group believes that a standard is prohibitive to both solving the problem and and innovating. And I think where we are right now. Think about what this show is all about. I mean, I can't state this enough. Fucking five years ago, we couldn't have done this. Think about it. 39 companies, 36 vendors, 36 use cases, 45 million messages per hour on a 10 year old server, and everybody was given 16 weeks, and every single thing that was produced is of value to this manufacturer. Think about that. It boggles the mind. And guess what? There's only one standard being used, and it is a simple standard that is MQTT 311, and MQTT five. Right now I will say to this point, we are using OPC UA. We are we have OPC consuming MQTT. We are serving out the UNs over OPC UA, but I wrote that server. I chose to write the server so that I could use the minimal elements of OPC, UA, because there were some things that I wanted to do, I think, where we are, and this is the work that you guys are doing that's so important. Is it future state? It's not even future state. It's current state. For many manufacturers like Tesla, the idea is, is that I'm going to take a namespace, data model, data standards, information models, and I'm going to land an asset on a plant floor, and I'm going to point it to an infrastructure, to a place in the ontology, which is the next word, and it is just going to start publishing into the infrastructure. And you want to know where we need standards, how to organize the data on that asset we landed on the floor before we pointed to the infrastructure, and that's the profiles you guys are working on. That profile standard at sesme Is it serves an important role in us being able to achieve that. Because if I'm going to land a grinder on the plant floor in Plant A, and I'm going to land a grinder on the plant floor in Plant B for Customer B, and they're going to publish into a digital supply chain, we should be able to identify that they're both grinders, and you can't do that without a standard, yeah,
Jonathan Wise 22:49
100% aligned with that vision of the machine comes on. It registers with the infrastructure, and I can discover what it is. The part I think needs to happen is that I need to know what it is before it starts broadcasting its data. I need to have that data definition, that data standard, independent of the machine first turning on, because I need to be ready for it when it gets
Walker Reynolds 23:13
or can you send it when it first turns on? Can you send the definition over the wire? Right? And that's what you guys are. And I think
Matthew Parris 23:19
it depends on the use case. So let's say I'm a UI developer, and the customer says I need a dashboard for for the grinder. Well, tell me your data model. Send that to me. I'm going to build the dashboard off that data model. And when I see that type come across the
Jonathan Wise 23:33
wire, I know I've got your dashboard, right? Yeah, and
Walker Reynolds 23:36
we call that self aware. That's right, right? Right? Now, that's non standardized, right? It's like I have to control the data model, the information model and the template that's consuming all three in order to do self aware visualization. But without standardization, we
Arlen Nipper 23:49
do that to a large sense. We have udts and ignition. We can publish those with spark plug. I would love for machines. I mean, my vision is, you know, we don't have middleware. You turn on the machine and it publishes all of the information that you need to your point. But the problem that I wrestle with on that is like an opcua definition, is that if I went to all the customers that I've got and said, Are you using the OPC UA model for a centrifugal pump? And the answer is, no, they don't even know what they've never even heard of it. So my problem with that is we could you the worst thing to do is to come out with like companion spec that opcua has. They're all sitting over here. Nobody uses
Jeff Knepper 24:49
them. Why is that? Why is that, before we move on? Why? Why is anybody using what's already
Matthew Parris 24:54
defined? I would argue it goes back to when do you define an interface? And I would argue. That is you need to serve the consumer. And in this case, it's the whatever application needs the data. So if the data, if the application that needs the data doesn't use this standard or use this companion spec, then why would I build it? And
Walker Reynolds 25:13
if you don't have the foresight, standards really help with scale, right? If I if it's scale and deployment, right, right? If I don't have the foresight in the beginning, when I we're in this 16 week stage, fuck. It's a wild west. We can do whatever we want, right? I mean, we can just nuke it after, but when we decide we're going to scale to 50 plants and 50,000 assets, right? And we're going to do change management, shout out to Emma Roloff. We're going to change management on those 50,000 assets, because we're going to make a change to the model, this ad hoc model that we originally created for our tank. How do you deploy that to if I've got 50,000 tanks and I've made a change in the model, how you deploy it to 50,000 models? Right? I mean, at the end of the day, I believe standards should be optional, and adoption should be the choice of the consumer. This is where we talk about heterogeneous and homogeneous development. You hear me talk about all the time. Homogeneous development is in uns is if I create a namespace that I define as homogeneous, it's red, it means it's not optional, but I can extend it with a blue namespace, which is ad hoc, which is optional, so I can have standard dot extension, which is Matt's extension. I didn't break the rule of the standard, right? I can, if I send it to the consumer, the consumer understands, oh, that is a standard tank object. It's got some extra shit. I'm going to ignore the extra shit, and I'm going to consume just what I need. But what I've done now is I have standard living alongside non standard. That was the beauty when you gave your presentation at inductive automation at ICC in 2014 I mean, when you gave, when you gave your presentation in 2014 I mean, we've told this story a million times. You know, Arlen's up on stage and he deploy. I don't remember how many PLCs it was, but was, but you know, we take it for granted now that we could do this. But when he showed at ICC that he could deploy 500 PLCs and populate ignition tags and visualize them on the screen, and he did it all in like 10 seconds, I was the first guy up to the front talking on the mic, turning back in front of me in front of everybody and saying, the whole the our world just changed, like it just changed, you know what I mean, and this, and part of the reason it changed was because what I saw in that moment wasn't just the edge driven, self aware component of it, which is obviously incredibly powerful. It was also standard with non standard together, because I knew the mechanism you were using was, hey, I can recognize, I can recognize the pattern in the standard part, but and I can accept that there's a non standard component
Jonathan Wise 27:52
to it that's really important there, and that's getting into the real computer science of name spaces. There was a question asked, and I made Walker promised me I wouldn't be the OPC UA whipping boy, but it's a good question that that that should be answered in IT software, when we develop a namespace, we make it up out of classes. Class definitions make up the namespace. Classes belong to a namespace. Classes are composed of sub classes, and that composition that allows us to put together parts that are standardized with parts that are not yet standardized with parts that will never be standardized. That composition that makes up a name space is a really important part of defining a namespace. And to your point in question, Arlen, the 160 companion specifications that have been published that are profiles of pieces of equipment or parts of pieces of equipment were initially developed as monolithic, homogeneous name spaces. It was Take it or leave it right. You need this whole thing where you could have none of it, right? And that's not how we build namespaces. Namespaces are these organic things where we iterate and learn. So you'll see the foundation and the supporting organizations like the bdma begin to decompose these things. Like here is a standard based on isa 95 for job control that has been expressed as a modular profile that can be implemented by machines that may or may not fulfill other standards. If we can break these things down into parts, then when I connect to a broker, I can begin to recognize the parts that are standardized and bind to them automatically. There will be parts that are not globally standardized, that maybe I can, maybe my vendor needs to do that for me, but we can start to have these repeatable Lego blocks that build up our architectures and make them interoperable. Yes,
Matthew Parris 29:50
and I think the key to a good
Matthew Parris 29:55
applause for your voice. So the key to, I think interoperability and industry. Three is to use spark plug as an example. It was great about standardizing a lot of the stack. So if you think about on top of TCP, they standardized MQTT, how to use MQTT, because you could use it in 1000 different ways, and if two people are trying to use it, they may not work together. So they standardized how to use MQTT. They standardized the encoding to use on top of MQTT, because that's left wide open. You could send binary bitmaps, ASCII, whatever you want, a standardized variable definition on how to structure your payload within the encoding. And they stopped there. They said, well, and then also on top of that, will have a mechanism for you to define a template, and they left it wide open. They said, Okay, we'll stop right there. That's very powerful to automate that much of the ingestion when you're trying to consume data, I think. But there's some limitations there, like if I want to query an endpoint to say what data is available there from right now for me to use. I can't do that in spark plug. The only mechanism I have is to subscribe, see some data, and then I issue some end bursts to then start to see the data.
Jonathan Wise 31:14
And to be clear, an end birth is like unto a class definition. Yes, I'm asking the object what it's correct is,
Matthew Parris 31:21
yeah, it's an in band way to communicate a namespace, yeah, which is
Jonathan Wise 31:27
perfectly valid, name, space, even, sure, sure,
Matthew Parris 31:31
so in terms of being able to query or to be able to read a specific value.
Walker Reynolds 31:36
So for those of you just so, not everybody is familiar with do we get too nerdy with spark plug, so
Matthew Parris 31:41
Jeff, you're supposed to
Jeff Knepper 31:43
be helping a break in the conversation.
Walker Reynolds 31:47
So obviously, Arlen is the expert here on and west of the expert. But I'll just in layman's terms, the beauty of spark plug is that it that is that on the first connection from the client, we are publishing structure, okay? We are saying this is all of my communications to you are going to be based on this structure, and that is very flexible. Okay? It is encoded. There's a whole host of other things. And then as I update all i As long as I don't break the rules on the original structure I sent to you, I didn't send a death message or and I didn't send a rebirth message. I promise that all the things I send to you are going to be on that first structure I said to you, right? That's that's spark plug. Spark Plug also has the ability to also publish definitions which are called templates. And they can say, I have templates within this structure, and those templates might be udts. And here is how you deconstruct those to the client that that's spark plug in a nutshell. I actually come from the school of and I think Arlen and I, Arlen Wes, and I probably agree here, because I know Arlen and you guys could have gone further with spark plug, A and B, but clearly chose not to go farther you. You, in fact, you went further with a and b, right? You went to a point with a, and then you said, Okay, well, maybe we and you held yourself back, and then you said, oh, we'll go a little further with B. And you went a little bit further with B, and I actually think had you gone further, you would have had a negative impact on adoption, exactly right? I think you would have had a negative impact and so at the end of the day, but we are at a point everyone agrees, the community now knows, understands, okay, oh, I've identified these limitations in spark plug, and you know them as well as anybody, right? I mean, you know, yeah. And now it's, what can we do about industry? Iterate and learn? Yes, exactly. What do we do about it? That's the question
Matthew Parris 33:38
at the end of the day. But it's super obvious. If you ask any of the vendors that integrated into this Pruvit infrastructure, how fast was it for you to subscribe to the MQTT flat, assume JSON versus if you had a consumer that understood spark plug when you subscribe to the spark plug name, space, how fast was it to get data there? Oh, sorry, I remember the discord, yeah, you said, Yep, we're publishing spark plug. And then it was Opto 22 that said, Yep, we've got it. It was
Walker Reynolds 34:08
like, just like, spark plug was clearly the superior integration mechanism for proven and
Matthew Parris 34:15
the reason for that is because they had a standard up the stack. Yeah, you don't have to ask these questions about, How did you do this? How'd you do this? Because
Walker Reynolds 34:22
if you go and you look at, if you look at all, if you go out to the touch screen, you can navigate the UNs, you can see all the various vendors and how they package their payloads. Some are using spark plug, but not many. And so if you go to atanta analytics, for example, who's in the flat MQTT namespace. It is the Wild West. It is the atanta standard. But if you go to spark plug, it is the spark plug standard, and they all follow the rules of group ID and but again, one of the complaints that we've always had about spark plug is that spark plug was really meant to be Device Centric, right? The. Edge node is, was meant to be a representation of a device, but it became more and more apparent. Wow, if it were instrument, if we had the option of it being device and or instrument centric, it would be so much more powerful. I am an instrument, or I am a device, but we don't, and that has to do with the group. Well,
Arlen Nipper 35:20
that was the name, that was what we came up with at the time, and that had come the spark plug spec. Okay, when Andy and I invented spark plug, I was a CTO for our comm, and we had a little red box called an R com director, and that's what we were using for protocol converters out in the field. So the first implementation of MQTT for Phillips 66 John Lujan and I wrote our own right. We completely off the wall, but we had the notion of a birth. We modeled the data as Modbus data, but it was binary, so we could smash it down, and that was so efficient for Phillips 66 in fact, they're still using it today. But the model of spark plug a where I started, I modeled it after what we had done 25 years ago. Can
Jeff Knepper 36:15
I want to just put a pin and stay on the spark plug vein? But first, can we recognize the vendors, and particularly end users that are in the room, that are com, that are
Jeff Knepper 36:29
part of the working group, that are contributing,
Jeff Knepper 36:30
that have have said, Yes, we will back spark plug. Is
Jeff Knepper 36:36
that a self plug? No, no, it should be. But if you're
Jeff Knepper 36:42
a vendor in the room, I don't want to miss any so this is kind of off the cuff. No, but okay. Inductive, automation, Opto, Opto, 22 canaries here, right? Hive, yes.
Jeff Knepper 36:56
Chevron, I don't think is here. No, a huge part. Who else
Walker Reynolds 37:00
I mean, hi, bite, ingest spark plug. So you got high bite.
Jeff Knepper 37:04
I'm looking for working group members,
Jeff Knepper 37:05
working spark plug, working making a financial pledge, making a time commitment pledge. Yep,
Walker Reynolds 37:13
I think that's it. That are here. Well, I'll say this, I get a lot of complaints about spark plug, and I always say, Talk to Harlan at Wes. But what I'll say is, why don't you join the working group? Yeah. I mean, I have an objection. No, you do? You do?
Jeff Knepper 37:27
Yeah, and that join the working group. And
Jeff Knepper 37:28
that's my point, because what
Jeff Knepper 37:30
I'm hearing is
Jeff Knepper 37:32
spark plug could fix a lot of problems
Jeff Knepper 37:36
in our need for a standard for fast uns connectivity with understanding the payload, but it's not perfect. Well, I
Walker Reynolds 37:44
would say that, what I would argue, and I haven't talked to John about that. John dyke about this in any way, any capacity. We had a great conversation last year at operations calling John is the guy who heads up, says me, and he's the chief technical architect at sesme. If you guys don't know, sesmi is the Institute for smart manufacturing. You know, it's federally funded United States. You know, it's all about creating standards for smart manufacturing. You know, I actually believe, if you want to know my opinion, where is standards going to land, it's going to land at the intersection of what you guys are doing with profiles that says me and what the spark plug working group is doing for the mechanism of transporting, transporting standards. Imagine you had the mechanism that we're using, that you use a spark plug, but yet what we're first sending in that initial message, well, not well is a is a profile from, I believe, Travis
Arlen Nipper 38:39
Cox already took the profile from sesme and we were publishing that in spark plug.
Jonathan Wise 38:46
Yeah, Travis can already ingest a standard space Exactly. Spark Plug method, yep, yep. So
Matthew Parris 38:53
where I see where it needs to head is an API. How many APIs do we have, and all the software that we have on the server. Like, how many vendors do we have? And that's like, at least how many APIs we have? Yeah, I would love, as an end user, to say I have one API definition. I have a piece of software, and I'm going to connect to that one type of API, and I'm going to be able to browse for what data that piece of software has available to me. I'm going to be able to read data. I'm going to be able to write data and subscribe to data and read historical data. Like, is there any more functions that we really need as an industry? And if I could standardize all that in a single API, the single endpoint I'm going to connect, bring up your application, you browse. Here's all the stuff. Yeah, that's interesting. Subscribe, subscribe. Have some rules. I want to query for types of this model. We talked about data models, so I'm interested in this piece of software, if it has data regarding model pump, and I want to query and give back to me all the pumps that exist. And now. Going to subscribe to pumps dot power, because I'm interested in aggregating all the power of the pumps. To me, there's no technical reason why we can't do that today, 30 years beyond where the internet has been. Oh,
Arlen Nipper 40:11
introduce you to the Eclipse Foundation. You can start a working group. We actually
Jonathan Wise 40:20
already have a working group. So if we can standardize the class definition, so that we can exchange class definitions, and if we can standardize the transmission of the data, we will have solved two big problems in our industry. We are at risk, as Matthew's calling out, of moving one of those problems up a layer. So instead of having protocol wars, if we can put that behind us, we need to avoid having API wars where everybody's contextual information platform has a different way of interfacing with that data. So the Eclipse Foundation is one potential recipient of another working group's effort that Matthew's referring to to standardize those APIs. And I think if we can get that trifecta, we can move this industry significantly forward. We
Walker Reynolds 41:08
there, Matt myself and Rick Balota have a DM, an ongoing DM on Discord, the three of us, and I don't know It's a year old now,
Jeff Knepper 41:17
right? Give context on who Rick belata.
Jonathan Wise 41:19
I mean Rick, you want to LinkedIn? Yeah,
Walker Reynolds 41:24
so Rick Pilat is one of the OGS he mean, honestly, if I'm being honest, Rick's probably done more. He has been more consequential to our industry than any other individual, person I could think of, than other than, maybe than Arlen. And I'm not pandering. I mean, Arlen you what you and Andy did? I mean fucking change the world, dude, for real. I mean legitimate, but you name a consequential product that shifted the direction of our industry over the last 25 years, and Rick belotta had a hand on it. What do you think SAP Mia, when you look at Wonder where version 10, when you look at ptc thing works, yeah. I mean, Rick has he's been an architect and had his hand on it. He's the asshole on LinkedIn. Is always picking fights, and he's a big he's a big investor in tech companies, but behind the scenes, Rick really cares about what's going on. And he's, he's, you know, he's the invisible hand in a lot of ways. Myself, Matt and Rick have been having this ongoing conversation about standards right before you join the working group. And a lot of the conversation, what you just said is a lot of you and Rick, you know, I was you guys talking about, here are the must haves, right? These are the things we absolutely have to have if we're going to standardize what I want to go back to just an original point here. There is a running joke in our industry that you're going to think about where every working group comes from, right? Every new standard is a is designed to fill a vacuum. And myself as an executive, when I take look, take a 10,000 foot purview, I look and I say, you know, we can prevent vacuums like we don't. The vacuum doesn't have to be there. And all in the way that you you eliminate vacuums is you eliminate restriction, right? Unless I have her medically sealed tank. I can't create a permanent vacuum inside that tank if I, if I allow the tank to expand and contract, and I leave enough flexibility, there's a shape there, but I leave enough flexibility, then I'm not going to create a vacuum where someone's going to defect from OPC UA, and they're going to, you know, from the OVC Foundation, and they're going to go create their own standards body. And our industry is littered with those examples. I mean, they're everywhere. And so I believe the long term solution is, Let's all stay a little flexible, right? Let, let's, let's not over standardize, but I think we're at a point where we must standardize. This is a, I mean, the reason I'm a huge proselytizer or spark plug is because of its flexibility, right, right? It's just enough standard, just enough, just enough. You've got 400
Jeff Knepper 44:14
end users in the room. What do they go home and do to help this process?
Matthew Parris 44:22
So for me, I joined the sesame API working group. How long have has it been ongoing effort, since November? Okay, so I joined in November is when I found out about it. The beauty of it is that it developed on GitHub. You can go to github.com/sesame/api, this spec will be there, and if you don't like something, open up a GitHub issue that will be read by the working group, and it will be answered on GitHub. It's not being developed by enclosed doors. It's not being developed by ideas from Select you know. System matter experts that we choose. It really is an open standard in terms of going through the development
Walker Reynolds 45:07
process. I don't think, I don't think it be, could be even more open? No. I mean, if you were to say, how are we going to make it more open? I'm not sure how you would do it. I'm like, Jonathan,
Matthew Parris 45:15
are you sure you're ready to, like, receive the audio? Who knows who, what somebody's going to publish on GitHub. But that's the point. Is that we need to hear these ideas, because I would love to fix this once and for all and not have to question it ever again, because there's so many more problems that we really need to be solving. We're parsing data and parsing it from this like that's just stuff that needs to get all and
Walker Reynolds 45:39
think about it. Think about the issue here, without the level one, level two, level three standards, right as we move up the stack, if l5 in the cloud is where digital supply chain is going to take place, where I be able to turn an entity, an enterprise and all of its subclasses into an object, a digital object, that I can then put onto the digital supply chain so that it can interact with other objects. I We have to go through the l1, l2, l3 those are the sub classes of that larger object. And if the goal is digital supply chain, and it is, you know, if you want to know Tesla's, you know, real, you know, mandate. It is, if you are a supplier of ours, you are in our ecosystem, you are on warp Tesla doesn't get on the phone and call sake Cobain about how many window passenger Windows they've manufactured to put in the model three they already know. In fact, they're predicting how many they're going to have as they're rolling cars off the line a month from now. They're on a digital supply chain, but what it is is Tesla created the standard, and then they're just making their suppliers adhere to it. That is not the future. The future is an open standard that all of industry is adopting.
Matthew Parris 46:53
And my challenge to everyone here is, go on GitHub, get involved in the sesame API. If you're an end user and you're seeing something that and that's not going to work because of my experience in X, Y and Z. Make that known. If you're a system integrator, let us know why what we're planning to do is not going to work because of your experience with this project. If you're a vendor, tell us why it's not going to work with your product, because all three of those are going to align. For this, the schedule for this is to release the definition in November, and I would love, more than anything, is to see it prove it 2026 next year, all the vendors are integrated around this API to more readily automate the ingestion of that information, both real time telemetry and the historical data. And there's going to be lots of ways to get that data and information into those softwares, but then to exchange that between the vendors. Would be fantastic. Of see that done in the standard. I'd
Jonathan Wise 47:49
affirm that and broaden it so not just the API, but if you are building your uns, if you're on your industry transformation, it is fair to say this standard doesn't work for me, but it's not fair to say that if you haven't tried it, if you haven't provided the feedback to the working group that's guiding these things. I don't know if Arlen wants the email directly for spark plug B, but we do need the feedback. I sit on about six working groups, and our primary job is to understand the industry consensus, the industry feedback, and try to steer the standards towards things that can be useful, that can allow interoperability, and we we can't get there in a vacuum.
Walker Reynolds 48:37
Yeah, I would always say this, just like all of you who are integrators or your your solutions providers. So there's a rule I have for all of my teams and all of my students, and that is, you should never build a solution that makes the operators job harder. You should never, you should never make more work for them. And I am my and what I say to standards bodies is you shouldn't write a standard that makes it, that makes using the standard harder than not using the standard. Agree,
Jeff Knepper 49:07
would you prefer that people just complain about spark plug V on Discord?
Jeff Knepper 49:12
That's the most helpful.
Walker Reynolds 49:16
That's where Rick does it. Yeah, that's
Arlen Nipper 49:17
real. That's real helpful. What? What?
Jeff Knepper 49:20
Two part question for you. ARLEN,
Jeff Knepper 49:23
what are we doing right now on the spark plug working group to try to make it easier for end users, vendors, even integrators? Yeah. Part and what action would you like your end users to take that believe in spark plug with their vendors?
Arlen Nipper 49:39
Right? So we are changing. So before to join the spark plug working group, you had to become a member of Eclipse before you could join the spark plug working group, and it was pretty costly. So what we're setting up is more of a spark plug Association, where. The entry level is a lot lower. We're going to make it to where part of the caret, especially if you're a vendor, is we have a lot of vendors that have said that, say they've implemented spark plug, but not quite. They're still using the spark plug logo. So it'll make it. The carrot will be, hey, if you pass the TCK, you get the spark plug B logo to go along the spark plug logo, we won't call it B. So really, again, the one of the people look at and go, Well, you know, a lot of people are just taking the work that we've done, all that work, that serious Link has committed to this, to the spark plug working group now, what clips, what Eclipse did for us, we now have an international standard. So spark plug is an ISO IEC international standard, and the next version of spark plug for coming out, they'll work through that same organization to get international standardization for that. I think the more, again, what we don't want is a version of, you know, you buy a vendor's software, you plug it in, and your system blows up, or you get into a reverse storm, or anything like that. So, you know, if you don't nothing, if you don't do anything else, at least download the TCK and pass it, because if you're not spark plug compatible, it will tell you where your problem is. And
Walker Reynolds 51:34
by the way, I want to encourage you know, I complain about standards all the time, but believe me, I didn't start bitching about OPC, UA, until I built a server and a client from scratch. I mean, until I wrote my own server, until I wrote my own client, I didn't start complaining publicly, so that when someone pushed back, I wasn't like, Oh, I'm just complaining for no reason. It's no i i tried to implement this, and I was able to get these parts. I've also built a spark plug client, and I'll say this. You wanna know the hardest part about implementing spark plug, it is fucking easy, dude. Seriously, it is so easy. The hardest part is protobuf encoding and decoding, and that's not even that hard, like it's just that's the biggest hurdle you jump, is protobuf encoding decoding, I mean, and even with OPC, making an OPC client or server is not that difficult, as long as you go with bare bare bones, OB, and you're not. I'm not using this part of the spec with my client, but I'm not using it with my server, right? Yeah, and I know we're out of time and but do we definitely want to get to some of
Jeff Knepper 52:35
these questions, so we're going to shift, okay, and start hitting some of the questions. We're not going to hit every question, but we're going to hit the good ones. How's that?
Jonathan Wise 52:42
It was a really good one that flew by. I was like dying to answer, okay, what do you think about a standard for namespace documentation? That standard exists. Come talk to me if you can't find it.
Arlen Nipper 52:55
Oh, no.
Walker Reynolds 52:59
So obviously the top one is what makes MQTT so popular for industrial applications, and why does it beat the likes of NATs, Kafka or cloud provider, message brokers? I mean, obviously we all have opinions here, but at the end of the day, it does. It just doesn't get easier. So
Matthew Parris 53:18
the simplicity of
Arlen Nipper 53:20
the simplicity, the if we're talking pure Spark, MQ TT, the spec is 18 pages long, like you said. I mean, most college kids can get MQTT up and running in a day. The other thing wife why for industrial is stateful. People don't realize they they do all, they publish it, and they subscribe, and then they go off, and they go, whoa, whoa, whoa, where Didn't you read the you know, the ping and so it's stateful. So down at the bottom there's a death certificate, and that's how you know your MQ, TT session is up. So Andy and I had to figure out how to do publish or how to do report by exception, but know that the node was still out there to say, you know, in case something did happen. So that's really why MTT is so popular and industrial, no matter where you look. Is it kind of was designed for a mission critical real time pipeline control system, but
Jonathan Wise 54:25
it's it was designed for that yet a college student can pick it up, right? So a big part of what sesame does is workforce development, and there is no faster way to illustrate the concept that we're trying to communicate then see a sensor come to life on a on MQTT. Everybody here is using MQTT Explorer, which is a great piece of software. We use it all the time. Donate to the author, because it makes all of these concepts instantly visible. And
Walker Reynolds 54:55
Thomas Norquist, who did MQTT explorer like he just does it on. Side. I mean, it's a phenomenal tool, and he's a great guy. You should reach out to him and talk to him. I mean, he he added spark he built spark plug support, took it out, and then added it back in, had the group added back in, and now explorer completely decodes spark plug B natively, if you as long as you're using the
Jeff Knepper 55:18
beta version, that's why my version
Jeff Knepper 55:20
isn't doing, yeah, you want to
Walker Reynolds 55:21
make sure you're using the beta version. It'll decode spark plug, as long as it's Google protobuf encoded.
Jeff Knepper 55:28
Let's look at
Walker Reynolds 55:30
there was one in there that was, yeah, we lost it where there was a really good one that that missed. Well, we deleted a question that was really, I don't remember. Do you remember what the second question
Jeff Knepper 55:42
was, once it's gone, it's gone.
Walker Reynolds 55:44
Well, how do you balance theory with reality? When it comes to protocols for industry four, start with reality and find the theory that fits. I mean, what role do you see data formats as YAML or Tamil or JavaScript JSON playing in the UNs now and in the future, I would say they're inextricably linked now. JSON is probably, I think you guys would agree. Jason's the the the ideal
Walker Reynolds 56:14
payload format, I mean, for most well,
Arlen Nipper 56:17
and people don't realize these the protobuf encoded payload. I mean, come on, that's JSON going in, and one line of Java code is JSON on the other side. So all we did was take the protobuf to get it down. Because remember, just on the wire, just on the wire, yeah. Because in our world, my notion is bandwidth is neither free nor unlimited.
Jonathan Wise 56:42
JSON is actually a great example of imperfect being good enough. Yeah, perfect. There's lots of things JSON could improve on, but it's good enough that we can use it.
Jeff Knepper 56:51
Question of, why not expand rest? Why write a new standard for an API with rest having
Jeff Knepper 56:59
the adoption it already has.
Matthew Parris 57:01
For one thing, I would say rest does not support subscription. Yeah, so if I would
Walker Reynolds 57:06
say that's the reason, well, rest
Jonathan Wise 57:08
is a style of API. Rest doesn't tell you what interfaces your API must have, and yes, it doesn't support so
Matthew Parris 57:15
I'm going to call rest and it's going to collapse. Call it again collapse, you know. So just pull, you know. Talk about pull response. That's what rest is. So I want an interface that I can connect and then I get a stream of data coming back. And by the
Walker Reynolds 57:30
way, the there was a thing in there. Most, most vendors are already using rest for their API. That's because it's easy to bolt onto their their the API they're using internally in their software. Again,
Jonathan Wise 57:39
it's a style of API that doesn't stop every vendor from having their own implementation of their API over rest, with different interface, correct
Jeff Knepper 57:47
or standard. Bottom question, great are standards old news? If llms can do arbitrary translation between them? No,
Arlen Nipper 57:56
absolutely not. No,
Walker Reynolds 58:00
that. It's a great question. It's an outstanding question, but it reveals gaps in the understanding of llms.
Matthew Parris 58:08
So I need some assumed structures right to then be efficient. Are
Jeff Knepper 58:12
you not interested in running a factory with an LLM providing you perfect information all the time? Well, I
Walker Reynolds 58:18
mean, right now, we're cheating it. We're getting around standards, because large language models are trained on the way we talk, on the way things are written and we're but that's the way we write, is English, and English is a standard. I mean, grammar is a standard. So large language models are, in fact, being trained on not
Jonathan Wise 58:38
only that, large language models benefit from a knowledge graph expressed explicitly on the semantic web, like the training corpus for large language models was human language. We don't have a common language for industrial information. Llms will benefit from the implementation of I agreed,
Walker Reynolds 58:58
in fact, the the results from our queries will drastically improve with standardization. And there was a, can you use a uns in an environment that doesn't utilize real time data? Absolutely, absolutely. In fact, a descriptive name space isn't real time. In fact, a descriptive name. Space is a model. It's an info. It's a model that describes the the it's it's sibling namespaces, and that oftentimes instantiates one time. And so then you make it, you know, you always publish those messages into the UNs on connection, and you do that by retaining the message most of the time.
Jeff Knepper 59:44
What are your thoughts on standardizing the namespace documentation, something like swagger for namespaces? Yeah, that
Jonathan Wise 59:51
was the question that came by earlier. So we're all beating up on OPC because they they have kind of a massive. Scope of things they're tackling. And it's fair to say some parts of OPC are tackled well, and some maybe didn't need to be tackled at all, and some are maybe not tackled well. One of the parts that they tackled well was the idea that I should be able to declare my namespace independent of any implementation, even if that implementation doesn't use OPC UA, that's part five of the spec. It's much more than 18 pages, but it is independent of OPC UA. You can define your namespace in a standard space format that you can exchange with ignition, that you can exchange with high byte, and have that document be authoritative, independent of your broker. It is a standard. It's a published standard. You can use it now, and you can see 160 examples that you may or may not use of namespaces defined using this standard,
Matthew Parris 1:00:55
I would say anything that defines the namespace other than Word document that's more living
Jonathan Wise 1:00:59
improvement as
Matthew Parris 1:01:03
soon as you click save on that Word document, it's stale. It's out of date. So we need something else. I've
Walker Reynolds 1:01:08
generally thought of uns as somewhat analogous to a domain name server, DNS on the web. Thoughts I would change that to alias topics in a unified namespace are generally analogous to a DNS on the way, sure,
Jeff Knepper 1:01:24
let's take three more questions and then we'll wrap. Sound good. Sure
Jeff Knepper 1:01:31
you knew it was going to come.
Walker Reynolds 1:01:33
We promised not to know wars here. But how do you see spark plug
Jeff Knepper 1:01:36
that one? Yeah, of course. What we don't talk about politics, religion,
Walker Reynolds 1:01:41
or spoke spark or, however, I'll say this, how do I how do I see? I'm happy to answer and have you guys read the
Jeff Knepper 1:01:50
question, how do you see spark plug, compared to OPC, UA, pub, sub, part
Jonathan Wise 1:01:55
14, by the way, yeah.
Matthew Parris 1:01:56
Or which, which one is it? The Ethernet one, the UA, dt, one is it? MQ TT? One, the MQ TT one is the question. It's a
Walker Reynolds 1:02:04
good question. It's a good question.
Walker Reynolds 1:02:08
So the answer is, my, here's my philosophy on OPC, a pub, sub, part 14. It would, I think it was ill thought out when it was written. Because the there's a fundamental question, which is, if your recommendation to me is that I should, I should use PubSub with OPC UA, by transporting it over MQTT, which is your recommendation, then I have to come up with a reason to use OPC UA. And so my thought is, is that you if I'm going to use OPC UA, PubSub, it's because I want OPC UA, and if I'm going to use spark plug, it's because I want easier implementation, or I want to connect the things that talk spark plug. At the end of the day, I struggle with why you would ever use part 14. I struggle with it. I really do. I've implemented it myself. I just think that it should be rewritten from scratch and and strip out a lot of the noise well, but go ahead, Wes
Arlen Nipper 1:03:15
and I worked when Tom Burke was with the OPC UA. We worked with them for two years to try to get it into a reasonable form. But it's so political with with IBM and Microsoft and everybody else that we find. Well, when Stephen Hoppe came in, we we finally just quit. I
Matthew Parris 1:03:37
think the answer is, use the one protocol that your consumer can ingest. It's the OP so if you, if you have a piece of software that can understand OPC, UA, PubSub and Qt, JSON, use it. If it can understand spark plug, you need to use that. If you have a piece of software that you can understand both, come tell me what that is, because I would love
Jonathan Wise 1:04:03
Hold on, let's not move on. I would like to be a little more generous and also a little more pragmatic. OPC UA, client server has some challenges. One is that I need to pull so if the architecture that I'm starting from is OPC UA, and it is not an option to replace that architecture with Spark Plug B. Then it sure would be nice to have things published to me without me having to pull for it. From a pragmatic perspective, it is yet another format to decode when it arrives, but the world can handle a finite number of formats. We don't want an infinite number of formats. But pragmatically, I think part 14 is an improvement or a nice augmentation to a client server, and if it's present, I will take advantage of it. You may end up republishing it in another. Format. I see a lot of projects that republish that's fine too. It needed to happen. We can quibble about whether it happened well, but if it's there, I would take advantage of it. Now,
Walker Reynolds 1:05:12
if you want to use OPC, I mean for sure, or you have
Jonathan Wise 1:05:16
to use OPC, especially if you have to use OPC,
Matthew Parris 1:05:19
I think it was only last year, late last year, that they finally standardized MQTT topic names within that standard. And if you talk to them, that's when it has really started to be standardized. To me as an end user, I'm saying I'm waiting for the product to implement it. That's right, not that I'll consider let
Walker Reynolds 1:05:37
me. Let me say this one piece, I think we definitely need to answer that second question for sure,
Walker Reynolds 1:05:43
because I think it's an important question. Here has always been my issue. The OPC Foundation has done very, very important work for our industry, especially when it was OPC DA its limitations, UAS limitations are exactly what's talking about in the keynote that they carried over things from Da into UA that she they should have never carried over. And that's been its Albatross, right? And it's only gotten worse over time as the OPC foundation tried to do more and more and more without focusing on adoption, so they ended up with a larger and larger standard that had more and more elements that very few people were using, and so then it created all this noise,
Jonathan Wise 1:06:25
but the interplay with that legacy ties very much into the question that you want to answer yes. Next they cannot abandon the DA legacy that had to provide a path forward correct, because the Yeah,
Jeff Knepper 1:06:39
so why are so many hardware manufacturers so hesitant to adopt MQ TT, namely, spark plug B and first are in reality that many hardware manufacturers hesitant to adopt MQ TT, I
Arlen Nipper 1:06:57
get emails
Arlen Nipper 1:07:00
every week on a new piece of hardware that does support MQTT spark plug. So I think the major players, it does become a political it's hard for them politically, especially the big players, Allen, Bradley, Siemens, for them to give up on OPC, UA and go to MQTT. But the
Walker Reynolds 1:07:21
interesting thing is, one side of Siemens is all for MQTT, and the other side of Siemens is still something
Matthew Parris 1:07:28
interesting. There's a Beck off device that supports OPC UA to expose this EtherCAT terminals as well as publish those terminal values over MQTT. So they supported MQTT on board, please. Would you support spark plug? Well, we're waiting for the OPC, UA PubSub to get defined. There's still no
Jeff Knepper 1:07:49
did you have a thought you wanted to continue? Oh, no. Okay. I just want to throw this out there as we start to wrap up, because I get the last question, I do want to
Walker Reynolds 1:07:59
answer that piece that
Jonathan Wise 1:08:00
though. Okay, go ahead. I wouldn't mind answering before you get the last question. We deal with this a lot, not just MQTT or spark plug B or even the latest OPC spec. For a hardware vendor to take a decision to implement something in firmware that they will have to support for 40 or 50 years before they can sunset. It requires voice of customer. So if you want it, you have to ask for it. You have to demand it. That's the only way that a risk averse organization with a big legacy and a long commitment and support is going to move is if you ask for it in a unified voice,
Walker Reynolds 1:08:43
and I will, I agree with that one 100% I think I'm going to answer the question from the perspective of you've asked for it, and yet they were hesitant for to adopt it. Because I agree with Jonathan completely there, and I agree the answer is mostly what Arlen said it is, in fact, politics, especially from Rockwell Automation. I mean, just, let's just be honest, Rockwell didn't adopt spark plug for one reason, and one reason only. It's because ignition was kicking their ass, and they absolutely, under no circumstances, wanted to make it easier for people to migrate from Rockwell solutions to Ignition solutions by supporting spark plug. Okay, that's first and foremost. Wonder where also did the same thing. Wonder where was very hesitant. Because wonder where, I mean, the fact of the matter is, the number one conversion in the world, still, to this day, for 12 years, is wonder where to ignition. It is still the number one conversion. And so it is, it there's a commercial element to it, but let's take that piece away. The fact of the matter is, is that if you have something that's working for your customers, and you have an alternative that you're going to support, you have to justify where you're going to support that you. Really do. And so if I'm going to take overhead in my firmware, right? And because it is our it for each additional protocol you support, there's overhead, yeah,
Matthew Parris 1:10:09
and it's not like software as you can just kind of flip it, it's, it's expensive to go upgrade,
Walker Reynolds 1:10:13
and I have to have a real reason to add that. I have to have a reason. It's not a feeling, it's not a gut, it's, we're supporting this for x, y and z reason. And so that's to Jonathan's point. So it is a combination of both. It's the customer needs to be asking. The customer doesn't need to be responding to what's available. You need to be, you know, all you big players in here, I've seen this a million times. Toyota. I know you guys are, y'all are here. You know, Toyota told AWS and Azure what to do, and AWS and Azure said, how high when they said, you jump? And they both said, how high the major players can drive adoption like that pioneer natural resources. Look at what inductive automation and Kepler did, because pioneers said, we need this. That's right, yep, like that.
Jeff Knepper 1:11:05
All right. So
Jeff Knepper 1:11:08
hypothetical world, the US government, the German government, they put a ton of money, and they put a grant to their top 20 hardware and software manufacturing companies, respectfully, and they say you will support spark plug in the next 18 months, and you will get the big old check. You've got 100 individuals committing to spark plug. What does the forecast look like five years from now? 10 years from now? If that would happen?
Walker Reynolds 1:11:40
So that if I walked out there, I wouldn't have to ask the question,
Arlen Nipper 1:11:44
do you do your support? Right? Yep. Oh, I think it'd be huge. Yeah. I mean, again, my vision always drive what you guys are doing. If you could, if you could walk in, plug in all your, you know, plug in all your equipment. You know, the guy from Te. Carl Voss, Carl Voss, yeah. Carl Voss, vision that whole time was, I want to walk into my factory, plug my laptop in with proper permission, open it up, and it learns the whole factory, right? And that's really what you get with MQTT and spark plug B, boom. The Rebirth. Everything comes in.
Walker Reynolds 1:12:25
I would, I'll follow it up. If that were to happen, we would see spark. We have spark plug, A, B and three right now. We would see 4567, and eight very quickly. That's another thing. If you had massive adoption, then we would be able to see the gaps more clearly, the patterns and the gaps more clearly, and we would be able to speed up the hardening of the standard right
Arlen Nipper 1:12:48
because right now we need committers. We need people working on the spec, and we're doing everything that we can with the limited resources that we've got. Standards
Walker Reynolds 1:12:59
are like laws. You notice, our government passes laws but never repeals them. Its standards is the same way. Once you take that step, it's pretty hard to go backwards, especially if somebody adopted it. Yep.
Jeff Knepper 1:13:13
All right, should we? Are we doing an official wrap? This
Walker Reynolds 1:13:16
is sick ass, man. I hope this was really awesome for you guys. This is the i
