Ep 20: Arlen Shares An Update On MQTT And How SparkplugB Provides The Modelling Standard For OT Data And Dataops.

05:18
Speaker 2
Good day and welcome to the Human and Machine podcast. This is episode two for 2021. My name is Yaku, and with me is Lenny, as always. Lenny, how are you? Good, and you, Yaku?

05:28
Speaker 3
Can’t complain.

05:29
Speaker 2
Fantastic. Another week, another podcast. It’s great to spend time with you and all of our listeners again. We, of course, bring you stories, news and conversations and updates on the industrial, manufacturing and infrastructure landscape, specifically here in South Africa. And today, sadly, we don’t have Table Mountain as a backdrop. Lenny?

05:49
Speaker 3
Yeah, last week was we had to choose, were supposed to shoot this podcast last week, but we had to choose between good cell phone signal and cable Mountain as a backdrop. So went for the mountain. We had to reschedule for this week.

06:03
Speaker 2
Absolutely. When in the mother city, you definitely go for the mountain. And it was definitely special, as always. Cape Town was definitely showing off with the weather. She was showing off and just a really good week and quite encouraging to see a lot of positive sentiment and innovation coming out of the cape. And that was really good and also very exciting to see more women, specifically on the training that we had down there. And of course, this is all on the backdrop of us celebrating international Women’s Day. And unfortunately, our industry, like many other industry sectors, is still lagging behind when it comes to ensuring gender diversity in the workplace. And I must say, it feels like we’ve never had a better opportunity to change this than the present.

06:48
Speaker 2
And also very exciting just to change the hearts and minds of young engineers and doesn’t seem evident more so than anywhere else than in the Western Cape. It’s a lot happening.

07:01
Speaker 3
I mean, there’s a lot of talk about current brain drain in South Africa. There’s also this massive talk, know, there’s this massive age gap between old people leaving the industry, youngsters joining, and then in the middle, there’s a little bit of a gap from a skill shortage perspective, but definitely from what I’ve seen last week in Cape Town, just the amount of youngsters that comes into the industry, not necessarily that they have the experience, but that is good because they also don’t have any preconceived ideas of what to do and how to do it for sure. And I think bringing that new innovation into the industry can only be good. So I’m very glad to see the youngsters coming on board in the engineering sector.

07:40
Speaker 2
Absolutely. Especially the young woman joining the training and just kicking it off and also having some incredible ideas. That’s really good to see. All right, so one of the most downloaded episodes from our little Humble podcast that we have was the conversation we had with Arla Nipper, who’s the co inventor of MQTT and the president and CTO at Cirruslink. This was a couple of months ago already. I think it was. In fact, it was last year.

08:09
Speaker 3
Last year. It was probably one of the first episodes we’ve done on the podcast.

08:13
Speaker 2
That’s crazy. Time flies. And today we’re excited to again host Arlin and get an update on MQTT and all the work that they’re doing with Spark Plug B. And also following that episode, just help us answer some of the questions we received about MQTT versus OPC UA and why it’s the future. Spark Plug B, standardization, the concept of data ops, data transformation, just hopefully, as it always will be, just a lot of good and helpful information, especially useful and relevant regardless of where you are in your digital journey. So, yeah, we super excited to have another chat with Alan.

08:49
Speaker 3
Alan, how are.

08:52
Speaker 1
Good, I’m good. Thanks for having me again. I’m looking forward to it.

08:56
Speaker 3
Perfect, thanks. Olin. Olin. I think last time we talked, can.

09:00
Speaker 2
You believe it was last year? It was probably about six months ago that we last spoke.

09:05
Speaker 1
Yes. Yeah, I think it was around six months ago. So, yeah, it’s been a while, and.

09:10
Speaker 3
I think a lot has changed in this landscape that we’ve been talking about. Alan, I think last time it was very much an introductory to MQTT. We spoke a little bit about the history, how long the technology is, and I think we focused a lot around MQTT as a report by exception protocol. Obviously, all the good things that’s intended with that around bandwidth reduction, and I think sometimes people get this idea that, okay, that’s what I use MQTT for. If I’ve got a stranded asset and I need to get the data out, then MQTT makes perfectly sense from a bandwidth perspective. But after our conversations with you, there’s so much more that MQTT can offer than just the reduction of bandwidth. I think it’s probably one of the little myths of MQTT that you only use it for that.

10:04
Speaker 3
Obviously, in the six months there’s this new term floating around called data ops for international enterprise or industrial enterprise. Obviously, you’re in a much more better position than me to explain what this data ops concept is and obviously how MQTT can actually help feed into this strategy as well, not just having data sent through bandwidth efficiency from stranded assets.

10:31
Speaker 1
Well, Lenny, that’s true. I mean, it’s interesting. We kind of did a forensic analysis of our sales of MQTT technology last year. And you’re right, our genesis, and the genesis of MQTT originated in the oil and gas market. It originated to make DSAT communications more efficient. It originated as a command and control capabilities. And that was cool, and that’s where our genesis came from. But as we looked at the markets that were in, actually last year, oil and gas was no longer even 50% of the business that we did. We were into manufacturing logistic, food and beverage pharma. So the landscape of customers understanding it and applying MQTT and the associated spark plug mechanics have really exploded over the last six months. Well, over the last twelve months especially.

11:43
Speaker 1
Yes, one of the contexts of that is we can talk in more detail here, but one of the concepts that we’ve had is that when we design operational systems, regardless of the industry that we’re in, we always have to remember like the three tenets that inductive automation and Siriuslink have been on over the last five years is, number one, whenever possible, decouple. And what we mean there is you should be connecting devices to infrastructure, not to applications. And that could be, like you said, that could be remote assets or that could be a machine on the factory floor, or that could be sensors and other things around the factory. So one of the things like tanks that are feeding materials, liquids and things into the factory, being able to monitor the building control system that’s at the factory.

12:48
Speaker 1
So all of a sudden there’s all of these other opportunities to take and get a hold of that strand of data. So number one is connect devices to infrastructure, no matter where you’re at. Number two was provide a single source of truth. And originally four years ago when we came up with these tenants, that was just at the process variable level, in other words, the measurement. So if you had a Modbus register or Alan Bradley register, that you could take that register value pair and all of a sudden give it context, you could give it a name, you could give it engineering units, you could give it engineering ranges, you could give it any other properties that you, me. But now, as we learned, as went forward, exc.

13:44
Speaker 1
But now as we learned and we’ve been moving forward with our customers, we kind of changed that tenant to provide a single source of truth for models, assets and measurements. And we’ll get into more on that in our data as we talk more about data ops. And then the third tenet was, remember, our job first and foremost is to provide a better operational system first. So let’s get our operational infrastructure better, faster, more secure, more available, more scalable. And then once we’ve done that, we’re ready to plug into data ops, we’re ready to plug into cloud solutions, we’re ready to plug into that backend enterprise system. But we have to focus from an ot up to it mentality, not it down to OT.

14:39
Speaker 3
Now, Alan, that’s something that we hear a, I mean, I know we’ve been speaking a lot about it, but you get a drive from it around digital transformation and they kind of drive you to say, okay, all we need is to get the data into our cloud infrastructure. Doesn’t matter what it is, all we need is just to move that data from the plant into the cloud. And that’s normally it’s kind of perception on how to get this ot type of data into it. And you say it so nicely when you say you’re just moving the problem from one place to another.

15:14
Speaker 2
Yeah, definitely. And ot is definitely becoming intertwined with it, specifically around the enterprise. I know we spoke a couple of weeks ago about enterprise driving a lot of this direction and momentum, and OT is definitely becoming intertwined with it much more than we’ve ever seen on this discussion around what the offering is, what the technology is, and understanding the overall solution. And to your point, that data gathering component to drive the decision making, that’s the overwhelming factor. And that’s potentially why data ops and where it started or where the big driver is coming from.

15:55
Speaker 1
Oh, absolutely. Yako, let’s step back and just kind of take a look at what you just said. We can grab some actual technology examples. So we have things like Azure IoT hub, we have things like AWS kinesis, and those are those interfaces that cloud services give us to take large amount of data and put it into a data lake. So what were seeing is that companies that had perfectly good operational systems, they knew what they were doing. They probably had the tools to model the machines and the equipment they were monitoring. They had dashboards, they had their trends, they had alarming and reporting and all that. But then the mentality was, oh, well, let’s take these pressures and temperatures and valve statuses and motor statuses, and we’ll take those registered values and we’re just going to pump them up into a data lake.

16:56
Speaker 1
Okay, now we have thousands, hundreds of thousands, millions of measurements setting in a data lake. So six months later somebody comes along and know, hey, yako, we’re paying a lot of money a month to store all this data. What are we doing with, you know, we actually have to hire somebody to go into the data lakes and start taking all of those measurements out of the data lake and start giving it context. So now what we’re doing is we’re writing code on operating systems and lambdas or in functions to take the data out and give it context. And ironically, we’re trying to probably reinvent the same structure that we had on the plant floor to begin with.

17:46
Speaker 1
So kind of our new notion and what we’re talking about with this notion of data Ops is that with MQTT and Spark plug, we now have the ability to publish a model. So let’s take, for example, in ignition, we build a UDT, a user defined type. And in that UDT, let’s say we just modeled a motor, and that motor has rpms and amps and handoff auto and things like that. Well, now that we’ve taken the time to build that model on the factory floor, we instantiate that model and actually point it at an Alan Bradley Plc or a Modbus Plc or a Siemens Plc, or maybe point it at our backnet ip building control system.

18:38
Speaker 1
And now we’re gaining the scalability of being able to take a model and then replicating it, abstracting it away from the actual low level register value pairs that we’re pulling in. And now we’re building screens, so we’re dragging UDTs onto the screen, they’re populating, and we’ve got consistency. So now with MQTT, Spark plug, we’ve got the ability to take those models, that motor UDT, and actually publish it to cloud infrastructure. Okay? So now, out in our back end systems or our cloud infrastructure, we’ve got the notion of a motor model. Well, now we take the instantiations of those, the instances of those motors, and those are published as spark plug definitions. So now we’ve got the definition, and now the measurements that go along with that are included.

19:38
Speaker 1
But now, instead of this big lake of measurements that we have to put back together, now in our infrastructure, we’ve got the notion of, oh, from this location we learned this model, and at that location, there’s five of those models creating assets. And then those assets have measurements, and the measurements have context. So imagine the fact that if you could just go into your cloud infrastructure, boom, pull up a motor, and now you know what you’re talking about. The other thing that’s kind of one of my pet peeves is that modeling using tools like UDTs lets us make data humanly consumable. And what I mean by that is that our industry? And it doesn’t matter if it’s oil and gas or food and beverage or pharma or manufacturing. We are awash in enumerations.

20:43
Speaker 1
So we’ll have an engineer write a perfectly good control program and we need to know information from the equipment that’s out there so we have an integer value that can be 01234. Now, if I’m on the plant, if I’m the engineer down there, I know that zero means this and a one means this and a two means that. But once we get decoupled from the tribal knowledge on the factory floor, once we get decoupled from that, now, what we have coming up to all of this digital transformation is in a number, 01234. So with our modeling, we can take that tribal knowledge and break it out. And in our model, in our UDT, give that context. So one of the examples that I give is that in the oil industry we have an orifice plate material enumeration.

21:42
Speaker 1
Is it stainless steel, is it carbon, is it Monell? Well, with a UDT we can break that out so that a zero is carbon. We create a string so that now other human beings can understand what in the heck we’re doing.

21:58
Speaker 2
Yeah, so Spotplug B, and just to be clear and confirmed that it doesn’t in any way modify MQTT or the MQTT specification, establishing a single source of truth. And I’m with you. I think if we can almost break it down in terms of how it is the standard for modeling OT data, it does give us the, call it the centric Ot centric topic namespace. It provides us with the data model asset structure you’ve just spoke through. Again, OT centric extensible process variable payload. And then of course, very importantly, where the connection is, the MQTT state management. And that is, in short, how is the standard for modeling ot data?

22:49
Speaker 2
And of course you and some of the other folks at the eclipse Sahu, that’s what the drive has all been and what the focus has been for several months or years, if not, well, correct.

23:05
Speaker 1
The spark plug working group has been organized now for about 18 months. We are encouraging more and more companies to join. Currently it consists of Chevron, intel, inductive automation, Canary Labs, serious link solutions. We have several other large organizations that I hope that we can publicly announce coming up here soon. But you’re right, I want to actually go back and comment one of the things. It was very interesting for me to hear on the diversity of getting young engineers into the workforce.

23:46
Speaker 1
So one of the things from my standpoint that’s so exciting about just MQTT is that if I went to a university and talked to a group of electrical engineering students or data scientist students, or in those disciplines, you talk to that audience and you say, how many of young engineers, if you want to go into automation, have ever heard of opcua? Raise your hands. Just crickets. Nothing. Modbus, backnet, IP heart protocol, DMP 3.0, nothing. But if you ask that same group of young engineers, how many of you have a raspberry PI in your dorm room? Probably over half the class raised their hands. How many of you that have a raspberry PI have probably downloaded the Alexa app? You’re talking to Alexa, you’re formatting MQTT commands from Amazon, and you’re publishing them to your raspberry PI to turn an led on and off.

24:52
Speaker 1
Again, a lot of interest. And what’s so exciting to me is that as we bring new, exciting technology in, we can engage these young engineers because they know what in the heck we’re talking about. So instead of having this little silo of knowledge, of that, again, going back to that tribal knowledge, this is the way these industrial things work. We’ve got something that’s easily consumable across the spectrum, and to me, that’s what’s exciting about what we’re doing in this space.

25:24
Speaker 2
Yeah. What are the two sentences that we often come across? We have never done it this way, or what was the other one?

25:32
Speaker 3
I’ve been doing this for years.

25:33
Speaker 2
I’ve been doing it for years, or we have never done it this way.

25:39
Speaker 1
That’s why I always go back. Yakko. One of the things is that what we have to get across here is, first and foremost, MQTT will bring it up. And if somebody hasn’t heard about it, to your point, oh, that’s bleeding edge technology. We’re not going to adopt that. Well, remember, this year, MQTT turns 23 years old. Number two is that it was invented. The genesis of it was for Philip, 66, on a pipeline control project. So it really was invented. Not for Alexa and for Raspberry pis and for Facebook messenger. It was invented real time, mission critical applications.

26:29
Speaker 2
Now, it’s a very good point, Arlen. And just to sort of echo what you’re saying, I think there’s just a whole lot of context that is just immediately relevant to these young people without the requirement of explaining why or how or when. All of that context is just automatically there, which is so refreshing.

26:54
Speaker 1
It’s the fact that you can put your hands on the technology. Yako. Again, every raspberry PI ships with node red, and node red is an MQTT creature first and foremost. So that means that instead of having to invest thousands of dollars and get equipment and get some very obscure documentation, that means that all of the engineers that we’re talking to and all of the young engineers can go out and for $35 they can have this technology up and be playing with it. And that to me is what’s going to make this scale globally. Going the. And I think if I look back on what Andy and I had, we had, we kind of know all the hard work for any sort of a communications infrastructure is the security and it’s the reliability of it.

27:58
Speaker 1
And at the time we had the opportunity to choose UDP because it was lower overhead than TCP IP. But had we done that, we would not be able to leverage all of the security and native capabilities of what the entire world are doing with TCPI fee. Then the other thing that we leveraged is that we never did dictate a topic name and we never dictated a payload. So with MQTT, you can publish anything that you want on any topic. And I think that’s why it’s become the dominant IoT transport, no matter which direction you look, from consumer all the way to heavy industrial. Now, at some point, that is the wild west, I will agree. And at some point we kind of had to drive a stake in the ground and say, look for the industrial sector.

29:01
Speaker 1
If we want a mission critical real time infrastructure that is cloud ready, let’s at least come out with a specification that gives us some ground rule so that we can start to understand these MQTT messages. So spark plug set up a well known topic namespace. In that namespace, we started to describe what you would want to do in an industrial system. I want to publish data, I want to publish a command, I want to publish a model, I want to instantiate that model. So those are the mechanics and the verbs that go around this very simple notion of what we’re trying to do with the MQTT spark plug specification.

29:46
Speaker 1
And that dovetails quite nicely now in this new market sector, that, to your point, we’ve been doing it, but data ops just kind of popped up as this, oh, well, this is a completely new market sector.

30:07
Speaker 3
So Arlen, when someone now comes to you and says, all right, arlen, we hear what you’re saying, we understand how important this foundation is, but we’re still a little bit skeptical around MQTT. As Yaku said, we’ve been doing things away. We want to do a POC, we want to now check how this thing works. What would you say if someone started off with a PoC and they started.

30:36
Speaker 2
Probably 80% of the case.

30:37
Speaker 3
80% of the case. It’s always us. We want to prove the concept. It doesn’t matter if it’s working on how many other sites. I want to prove it on my infrastructure. Right. So we always get this kind of scenario. I know we’ve spoken a little bit about when you start to code on.

30:53
Speaker 2
Operating systems and loaded question is it or ot that wants the PhD?

30:58
Speaker 3
Well, it’s probably more from the IT side, but anyway, let’s not go into that discussion. But we spoke a little bit about it around when you start to code on operating systems, that’s kind of one red light to understand that. No, there’s some things, you spoke about it. We put applications down to help us with this. So when that’s probably one red light. So custom coding sometimes is a very big not no, but it’s a red flag that your POC might be in full of failure. What other type of things can we look out for to make sure that we do not fail when proposing this new foundation for that? What’s critical to the success for that implementation?

31:43
Speaker 1
Well Lenny, I think the first thing, and again, just nothing specific, but just to generalize, is that we all know there’s system integrators, there are organizations that are attacking the sea level and saying, hey, you need to get into cloud infrastructure, you need to do digital transformation. It’s wonderful. It’s the panacea of everything that you’ll be able to use to optimize your business. And then, oh, let’s start on a project and have 18 months of discussions on, we’re going to put this a component here, this is the way we’re going to put this infrastructure together. To this point. Over the last four years that we’ve been doing this, I can probably guarantee you that’s going to fail and it may even fail spectacularly. So the first thing that I would say is try to find what problem are you trying to solve.

32:45
Speaker 1
First let’s identify a problem that we’re trying to solve. Then this other notion of being able to deploy edge compute, regardless whether it’s Google, IBM, Microsoft, AWS being able to deploy cloud or deploy edge of network secure containers, and now there’s this knee jerk reaction to say, well, I’ve got a secure container. And that means I can write a bit of python code or Javascript, and I can take a process variable off the plant and I can get it into the cloud. And I think that’s what you were talking about, Lenny, is this notion of getting sucked into that first step that says, oh, I’ll just write a little bit of code on this operating system, but that will not scale. And so what we’re talking about is it’s all about tools on platform.

33:39
Speaker 1
So when we do demos, I want to be able to get on a webex with a customer, identify a piece of equipment, and show that we can use tools on ignition. We can use leverage technology like MQTT, spark plug. We can leverage services like Azure, IoT hub or AWS sitewise. And in that 60 minutes I should be able to get data off the factory floor, into a model in the cloud, and show that customer that’s done at that point. That’s how quick a first level PoC should be. It should be days, it should not be man months.

34:30
Speaker 3
I agree 100%. It’s not just digital transformation projects that need some sort of goal and objective to achieve. We see it a lot in reporting projects, we see it a lot in mes projects. If there’s no business value coupled with those projects you almost immediately set up to fail, because what have you proven at the end of the day? What are you actually achieving and actually making better for your business by doing this? So, 100% agree they must be coupled to some sort of business value. Why are you doing this? I mean, to push, just to push the data into the cloud, as you said, other than costing your rams and cents for storage capability, what are you actually achieving with that data? Just because it’s now in the cloud?

35:16
Speaker 2
Yeah, for sure. And that’s also significantly reduced with Sparkluck being the standard for OT modeling. And I’m specifically referring to the eight to twelve or eight to 16 kind of month period that you referred to, alan. I think that ability, data transformation, ability from source, cuts down the time to value significantly.

35:36
Speaker 1
Well, I’ll bring it up, because he says it all the time. One of the founding members of the Spark plug working group was Chevron, and the representative from Chevron is time. And I know Todd and I talk a lot. He said, arlene, anytime anybody’s doing a presentation or trying to sell Chevron a solution that plugs into their architecture, he said, at any point during that demonstration, if somebody says, oh, and then all you have to do is go in here and write some code, stop because Chevron had already realized they had already gone down that road. Right. And what they found was that it became untenable, even when it was very, oh, well, this is just this little module. And then, oh, well, here’s this other little module over here.

36:34
Speaker 1
And if you look at it from an operational control, engineers, PlC programmers, people like that, it’s got to be all about tools on platforms, being able to configure things to get your infrastructure ready and then be able to plug into the. You know, I think, Yako, you and Lenny and I were talking about this, is that there may be many instances when there’s actually a very small amount of information that goes to the cloud. Because once they get this type of an infrastructure in place, they’ve got the visibility, they’ve got the knowledge, they’ve got the engineering capabilities to keep this all within the business.

37:21
Speaker 3
And to that point, especially on these projects that tend to run 18 months, 14 months, 24 months, one site, one line, it’s still easy, it’s still maintainable, and when you wipe your eyes, there’s about 20.

37:36
Speaker 2
Scalability.

37:37
Speaker 3
Yeah. And then there’s like 20 engineers sitting in your offices that you are renting out to just try and make this thing scale, and they’re all sitting back encoding their fingers to the ground. We saw that a lot as well.

37:50
Speaker 2
I like that. Tools on platforms, not coding operating systems. I like that. I might steal it from you, at least repurpose that. I love it.

38:02
Speaker 1
And again, none of us are slamming it. We’re not slamming programming language. We know that there’s the right place for that. But we also know that in this whole context of what we’re talking about, and really, let’s say we’re talking about SCADA systems, we are still in a brownfield world. I don’t care how many high end modern plCs come out with opcua servers in them. It’s going to be minuscule compared to all of the brownfield equipment that’s going to be around for the next decade. So let’s embrace the fact that we have protocols like Modbus and Alan Bradley and Bacnet and all those, and they’re going to be with us. And so let’s embrace that and let’s give ourselves tools to be able to deal with it.

38:55
Speaker 2
Yeah. And open. Lenny, I know you are usually very vocal about the open aspect, is own your data. Don’t let something or somebody or a system or a black box or anything else own your data. Open standards is really the only way.

39:14
Speaker 3
To go 100% yes, a lot of tools and stuff does have sdks and toolkits again, but then you’re starting to code using open standards to get your data out. You paid for it. You paid for the piece of machine. It’s your data. So definitely utilizing these open standards to just get your data out shouldn’t even be debatable. Subject in my case.

39:41
Speaker 1
Yeah, Lenny, I’ll give you a good example of that is one of the things that we’re seeing in the States, and I think probably everyone’s seeing it globally, is that Laurawan is actually starting to mature, at least here in the US. And LoRawan is a technology. It’s basically low speed wireless communication from sensors into your infrastructure. And there’s some very interesting devices starting to come out. Ultrasonic tank levels, four to 20 milliamp. Yokagawa has a new vibration sensor called Sushi that you could start slapping on all of your rotational equipment and start getting accelerometer and vibration information, like immediately.

40:29
Speaker 1
But the interesting thing is that what I was seeing is that there were these companies that were putting cloud solutions up where you would take all this binary data from your LoRaWAN sensor and you would send it to them, and then you would have to pay to get it back once they interpret it.

40:49
Speaker 2
We recently experienced that with the vendor presentation as well. And up until that point, it was a beautifully integrated story until they got to the point where they capture all of that in their own proprietary cloud. And you have to pay to get the data from.

41:07
Speaker 1
Yep. And so what we did was we took the same approach. Yako, is that we said, well, wait a know, we’ve got the capability. There are manufacturers that have LorawAN gateways. We can build a UDT. And in this UDT, we’re going to represent a Yokagawa vibration sensor or radio bridge ultrasonic level, and we’re going to populate that UDT with that information, and then we’re going to publish it into the customer’s infrastructure using Spark plug and all of a know, no longer even have touch the cloud, don’t have touch the Internet, but we can start leveraging all of these lower WaN sensors.

41:53
Speaker 1
And there are many other applications, but that was one of them that, as you were talking through this, is that again from open standards, whether it’s MQTT or SQL databases or well known protocols, we’ve got all of these tools at our disposal to make very good solutions for our end customers.

42:16
Speaker 2
Yeah. And it’s that interoperability. I want to call it or the decoupling that really enables you to connect multiple consumers. Multiple just serve many different systems and data consumers. Alan, I wanted to get a quick example here of. So I was just, while you’ve been talking through this, I’m just sort of putting it all together in my own mind. So I’m going to sort of, let’s ignore any specific brands of skaters or anything else like that. And when it comes to specifically, I think, some of the more recent kind of developments that we’re quite excited about is the spark plug sitewise, or the bridge that we have, which is obviously no programming or code required, as it should be. We know, for example, I’m going to mention it on the edge side. If it’s, for example, ignition, there’s no programming code required.

43:19
Speaker 2
And then obviously on the sitewire side, there’s no programming or code required. What does that typical flow look from left to right, or what does that typical architecture look like? If it’s an easy question, yes, it is.

43:37
Speaker 1
Again, it was the work that we had done. Amazon’s probably, we’ve probably been working with them the longest. And we had done a lot of projects where were quite adequately. We were using kinesis streams, were using kinesis firehose, were using DynamoDB. But again, in some situations, the customer could stitch all of this together quite nicely. But in many situations, again, it ended up with huge amounts of data setting in s three buckets, and then those s three buckets had to be, you had to write code to get it all pulled out and get it reorganized. And were in the process of trying to figure out, well, how could we make this better? Maybe every time we get an MQTT birth message, we could make an entry into DynamoDB, and then the process variables would go into s three buckets.

44:31
Speaker 1
And were kind of headed down that road. And I think it’s about 18 months ago, we had a meeting with Amazon, and they said, hey, arlen, we’ve got this new service. It’s called sitewise. And if anybody listening here googles AWS sitewise, you can see that very uniquely, it is a modeling service machine model. So insight wise, you create a model, and then when you want to use that model, let’s say we created the model of a wind turbine. Now we can take, and we can have multiple wind turbines that are instantiations of that model, insight wise and insight wise, those are called assets. And then those assets have measurements, and we can have RpM, wind speed, wind direction. So what I just said, we have a model, we have an asset, and we have measurements. Now let’s look over here on the edge side.

45:30
Speaker 1
Let’s look at ignition edge. Well, we can build a model with a UDT. We can instantiate that UDT, thereby creating an asset. And again, that asset has measurements. So the other cool thing about Amazon is they already had an MQTT broker. They’ve got AWS Iot core. So what we did, we needed that bridge between messages flowing into IoT core and the sitewise service. So Cirruslink created AMi an application, and we use, it’s called cloud formation. So literally, it’s free to run for two weeks. So literally, you click on a button that runs a cloud formation that installs sitewise bridge in your Amazon infrastructure. So let’s go from start to finish.

46:27
Speaker 1
You’ve got an edge device out in the field, and it’s talking to a wind turbine, creating a wind turbine model and populating it with the RPM and the wind direction and the wind speed. Now I’ve got my model and my asset. I literally point it at my AWS IoT core, my MQTtG broker setting in Amazon, and those wind turbine models will automatically show up in sitewise. No coding, and the assets will be instantiated. And now all of that wind turbine information goes directly into the time series database in sitewise.

47:11
Speaker 2
So data models for the assets as well as time series DB for the OT data.

47:15
Speaker 1
Yes.

47:17
Speaker 2
Beautiful.

47:18
Speaker 1
So were talking about, how do I go do a POC and do it quickly and see value? Well, here we’re talking about literally just tongue in cheek. You could do this with a raspberry PI. Run sitewise bridge for the first two weeks for free. Run all the ignition modules in trial mode, and you’ve just done a PoC of getting models, assets, and measurements into a cloud infrastructure, and it cost you $0.

47:51
Speaker 3
What I love about it is that the models is already created on the OT layer.

47:56
Speaker 2
Yes.

47:57
Speaker 3
You don’t have to replicate and now link up and remember to add this and that. It’s already done. You don’t have to spend any time or effort to recreate that model inside of sitewise.

48:09
Speaker 2
That’s the massive value add.

48:11
Speaker 3
And I think that’s when we’re talking about the single source of the truth of your model. And that’s what we’re talking about. Having it only to configure it once on the OT layer.

48:23
Speaker 1
Yeah. Again, that sequence that I just talked about, that cut through so many man months of engineering and design, and how are we going to connect to this kinesis stream, how are we going to write this lambda? And again, those are all really good tools in the cloud and we should all learn about them and figure out how to leverage them. But when we can cut through all of that complexity and get with an OT guy that may not completely understand all the complexities of the cloud, but Arlin, Yako, Lenny, I’ve been told that I need to get this data up into the cloud. How cool would it be for him to go back to management? And you know, yesterday you asked me about, know, wind turbines. Well, look here, it’s already in the.

49:24
Speaker 3
I guess it’s the same story, right? Not talking just Amazon, but it’s the same story when we look at the other providers, like Azure for instance.

49:33
Speaker 1
Yes, we’re doing much the same thing. We’re working with Microsoft, so a lot leveraging what we can do with our injector modules. We literally, as of this week just released some more capabilities with the Azure injector module, which lets us do routing into a service they call TSI time series insights. And now to the same extent that we can do that in Amazon, we’re going to be able to do it in Azure as well.

50:04
Speaker 3
Correct.

50:08
Speaker 2
I’m not sure if you feel, I know you have likely you can’t share the customer details or the site details, but I know you spoke to us, you gave us a little bit of detail about an incredible project that you had, which was a vessel of fleets, sorry, a fleet of 30 plus, I think it was 30 plus vessels. Can you share a little bit of that around that if you feel comfortable with that?

50:38
Speaker 3
Yeah.

50:39
Speaker 1
We had an opportunity with a customer that were looking to modernize their shipping container or shipping vessel infrastructure. And Yako, ironically, guess what? Down in the guts of a ship, monitoring the motor, monitoring all of the logistics is that they have Modbus and they have Alan Bradley. But then on the ship they also had their local display and their local information and then they had business apps on the vessel. But coming off the vessel they had satellite communications. So they wanted literally to go and build an infrastructure where they went from level zero, the control system in the bowels of the ship, up into their information system, up into their analytics, and then efficiently take that information and publish it over their VSAT system into their cloud back end systems. And so ultimately it was a very interesting project.

51:52
Speaker 1
We won it and now we’re going three levels through the ship. The nice thing is from each level we’re making an MQTT connection up and again from a security standpoint, I think we already talked about this, is that there is no better security. MQTT does not. It’s a remote originated connection. So there doesn’t need to be any ports open from level two to level three. No ports open from level three to level four, and no ports open coming off the ship into the VSAT infrastructure. So that was a very good example of, even though weren’t in the quote, vessel monitoring business, the application was perfect for what?

52:39
Speaker 2
That’s the beauty, right?

52:41
Speaker 3
That’s definitely not a pipeline.

52:43
Speaker 2
It’s definitely not a winning gas, although that’s quite unusual. Yeah, I think it’s probably likely one of the misconceptions as well. I think the NQTT born oil and gas just for oil and gas, and also the exclusivity for remote asset applications. I know Lenny, you’ve done a couple of TFC in the office in our demo environment doing some incredible things with MQTT. Again, not just for communication, bandwidth efficiency and remote applications, but for some fairly heavy load applications. You’ve done a couple of incredible tests.

53:25
Speaker 3
Yeah, I think with people always, we spoke about it, right? We spoke about data modeling, but contextual information that can now couple with that. Olin, I know you guys gave us an example where you actually feed, camera feed through the phenomenal protocol. So that’s phenomenal. I think people forget that. All right, I’ve got MQTT here. It’s now pushing my more traditional pressures and valve or vibrations and all the more realistically or process variables. But now what about some more type of static information, or how many containers on the ship? What is the barcode of the container on the ship? When was it packed? All of that contextual data, and you’ve got the infrastructure already created on this vessel, and you can actually now start pushing that contextual information through the same infrastructure that you’ve created. Nothing different.

54:24
Speaker 3
You don’t have to put anything else down. The infrastructure is created and you can use that for other contextual information, not just vibrations and pressures and flows.

54:34
Speaker 1
Absolutely, yes. By adding the ability now in Spark plug to publish a file, it can be a CSV file, as you said. It can be a JPEG image, it could be a sound clip of customers that are very interested in listening, having a short sound clip from their equipment. And the other thing I kind of forgot to mention as were talking about data Ops, is that it’s also a very evident capability within sitewise, is that for the last 30 years we’ve been having vendors provide us with these things called asset framework. And that kind of goes back to our data ops discussion, right? Well, Lenny, you’ve got this modbus register, and it’s connected to this four to 20 milliamp transmitter that happens to be a pressure, and you’re calling that p one from this location and it’s flowing up into your time series database.

55:38
Speaker 1
But you know what, Lenny, you need an asset framework where now another piece of software with another human being typing information that contextualizes where that pressure came. Now, you know, not only are you’re hand entering data every time you get a register value pair, now you’re hand entering information into the asset framework says, where’s that coming from? Well, with udts, you can put properties on udts. Well, what happens in sitewise is we create attributes for those properties. So I can add things like location supervisor, the equipment serial number, the allotment number. So now we’ve kind of layered the asset framework and the measurement or the monitoring capabilities. Again, to your point, it’s layered all one communications infrastructure technology where we can do both.

56:43
Speaker 3
And the great thing about that is the broker centric says if there’s another third party application that need that data.

56:50
Speaker 2
It can get it easy to object.

56:52
Speaker 3
Easy to get to connect to the broker because it’s this open standard protocol.

56:58
Speaker 1
Yeah, and again, that’s what we’re seeing. Again, I can’t mention the customer’s name, but a very large project where several data consumers coming off. So the project started on just a small PoC. Hey, Arlen, can we get some of this building control information, chillers, air handler units, can we get that into sitewise? Yep, done. Got it. Oh, here’s a chiller showing up. Here’s the air handler unit showing up. Oh, well, we have another application that’s cool. It’s going into sidewise, but we’ve got this other application where they just want to build some dashboards. So we had this other application and it subscribed to IoT core as well. And then they had a third application.

57:49
Speaker 1
So all of a sudden, just by getting a simple POC up, just going from a building control system into a few models, then going, well, let’s expand that, let’s plug another application. That’s the power of the decoupling of MQTT is that you publish information, you don’t care who consumes it. As a consumer, you consume information, you don’t need to know who produced it. Cool.

58:23
Speaker 2
Do you want to recap?

58:27
Speaker 3
I think the only thing that I want to recap from that is obviously, arlen, there’s a lot of, as we speak about these things, there’s a lot of building blocks that we need obviously for this industrial platform or for this data ops solution to actually function.

58:46
Speaker 2
What it is, it’s an industrial platform.

58:48
Speaker 3
And I think people must just remember that we shouldn’t position when we try and sell this or make sure that we get the buy in. We’re not selling MQTT here. We’re not selling only that portion of it. We’re selling the whole overall solution to go from edge to enterprise and creating that platform. And that obviously includes how do we bridge that itot gap, how do we make sure it’s future proof, how do we make sure that there’s no coding involved, but it’s an overall solution and idea that we’re selling here rather than that just, oh, we need MqTT for this to actually.

59:29
Speaker 1
Right, right. To a large extent I think I’m still guilty of that in that it’s not about MQTT, it’s not about Spark plug. It’s about building an ecosystem of OEM vendors, of solution providers, of application providers. It’s building those things around open standards so that our customer has choices. It’s very important to me. And again they said, arlin, well we could just go directly in and hard code this stuff into Amazon. We could hard code this stuff into Google, we could hard code it into IBM. But I’ve got this notion as I came off of 25 years in the hardware business. So I was the CTO for a company that manufactured embedded computers and embedded computer systems. And not one time did I have a customer that were designing equipment for.

01:00:31
Speaker 1
He never came to me and said, you know, arlen, I want you to design me this piece of equipment. And I only wanted to work with at t or I only wanted to work with Verizon. No. And by the way, Arlene, I want this to work with T Mobile and Verizon, at T and Orange and BT. And I want this to work with anybody’s cellular infrastructure. And what I’m seeing is the same in what we’re seeing emerge in digital transformation is that, no, I don’t want to just go to Amazon or just Microsoft or just IBM or just Google or just SAP. I want the more, again, the more people that can adopt MQTT, spark plug. That means that today I could point it at this service, tomorrow I could point it at this service. I am not hard coding again, right?

01:01:27
Speaker 1
I’m not hard coding my customer to a particular solution that six months down the road he goes, oh, man, I just realized I can’t move. I am hard coded to this or I’m hard coded to this, and we want to give our customers. It’s the serendipitous nature of data. Oh, I just realized something. This company just announced this. I want to take advantage of that, and our customers need to have that capability to be serendipitous with their data.

01:02:01
Speaker 3
I think you’re selling yourself a little bit short. And the reason I say that, I think you’re doing a great job. The amount of vendors that’s out there that supports it now, I mean, we spoke about the guys that’s obviously on the Tahoe foundation, but there’s big players in the market that starting to adopt. We’re talking about Moxo, we’re talking about Aviva. All of these companies are coming on board, and MQTT is getting entrenched more and more into these vendors.

01:02:26
Speaker 2
And Olin, you’re right. I think the very important part of that entrenchment or that adoption is the. And I’d like to get a sense of how you feel. Personally, I get the view that we’ve likely never had this big an opportunity to finally, to put it simply, get that OT and it bridging and digital transformation, easily done. We’ve never had as good as an opportunity as we have now to get that standard in place. And that must be terribly exciting for you.

01:03:04
Speaker 1
To me, again, I go back, and it’s been very interesting, I can say that for me to watch the evolution of MQTT over the last 20 years, Andy and I, we talk every so often, and we look back and realize that 1999, everybody still had DB, nine rs 232 ports on their laptops. If we would go into OT and say the word TCP IP, typically we just got blank stares. Like, what’s that? There was notion of cloud computing. Gosh, nobody was worried about security on TCP IP because nobody knew what it was. So obscurity is security, right? But to watch it evolve into it being adopted already by all the major cloud providers, I agree with you. I think this is an opportunity for the entire operational ecosystem to take advantage of it. Embrace it.

01:04:16
Speaker 1
To your point, Yako, again, I can’t mention it, but there are many huge organizations that are adopting a spark plug b. Going forward, many of them are going to be joining the Spark plug working group, but there are others that mean it’ll just be, oh, yeah, we plugged this into MQTT infrastructure. So you’re right. We should take advantage of this. It’s kind of the keep it simple, stupid. It does what it needs to do. It does it very well. It does it efficiently, it’s easily understandable. Again, I’ll go back to my notion of it embraces the way that this next generation of engineers think. It embraces that because it does leverage Internet TCP IP technologies. So I think going forward, it’s going to be great to see everybody come together.

01:05:13
Speaker 1
And like you said, when you have the avivas of the world and those people adopting it, then it’s going to become viral very quickly.

01:05:24
Speaker 3
Speaking about the youngsters, Alan, I don’t think it’s just about the great technology.

01:05:28
Speaker 2
It’s also about.

01:05:30
Speaker 3
What do you mean? I need to configure this thing both in this solution and that. Why can’t I do it just in one place?

01:05:36
Speaker 2
And it works on both sides. On both sides.

01:05:39
Speaker 3
How many times can I do it? So, yeah, I think just from what they’re used to with apps and the way technology is driven and the way the notion around configuring once with the birth capability and it’s consumed with all these other places, it’s also filling into that gap around just the ease and use of the technology.

01:05:59
Speaker 1
Well, it’s interesting. I can tell this story because I had the opportunity to go out to Tesla and go through the factory out in the San Francisco area, and Tesla has just huge number of young, really sharp engineers. And were sitting in this meeting, and one of these very young engineers, he looked at me, he goes, Arlin, I wrote MQTT, spark plug in. Alan Bradley, later, logic. And I’m looking at him, and I go, you did what? Oh, yeah. Watch this. But the notion was. And then the engineers asked me, they said, arlin, why do we have to pull these plcs to get information? Why can’t they just tell us when it changes?

01:06:53
Speaker 1
I literally had to go through again, I hope I’m not digressing here, but I had to go through the fact that when we started, at least when I started 1980, there were no such thing as networking protocols. So we had rs 232, rs 45, we had Bell 202 modems. And because of the nature of the networks we had to poll because it was a multidrop system, right? Everybody was listening. I send out a message, and it’s got an address on it. Your address one. Your address two. And so when address two got his message, he got to respond. So we got that mentality baked into our heads, and we got it so entrenched that for 40 years, that’s the way we do it.

01:07:42
Speaker 1
And to come out and actually say, well, we’re just going to connect into infrastructure and we’re going to publish everything that we know and then we’re going to publish everything report by exception because we know our state. Going back to your point, Yako, it is disruptive, but I think we’re getting that generation of engineers that understand it.

01:08:04
Speaker 2
Yeah, definitely. And again, if there ever is an opportunity, it feels like a very small window of opportunity that we have and hopefully we’ll see that unification in our lifetime and it feels like we’re very close to that. So getting the right foundation in place for this to be successful, maybe as a recap. So the one that I’m definitely going to repurpose in mind and keep Oli and I love that is tools on platforms and not coding operating systems. We spoke about open architecture, we spoke about the ease of everything installing, managing and configuring. As to your point, Lenny, we spoke about that very important, that quite crucial data ops or data transformation edge to enterprise transformation. We spoke about interoperability, scalability, probably the one that is most important for success in most of these cases. And obviously hand in hand with that.

01:09:12
Speaker 2
Scalability is obviously the price element or the costing element that either makes it viable or not. Is that just about sums it up, Alan.

01:09:22
Speaker 1
Yep, that does, I think the one other thing, again, not that, lest we forget it, is the security aspect, we keep going back again and again on again. That’s the other unique nature, is that for 40 years we’ve had to take from a central computer our SCADA system or our platform. We had to make outbound connections to connect to equipment. And with MQTT, it flips it on its head and it’s a remote originated connection, I. E. The equipment connects into our infrastructure, thereby not having to have any ports open. And it leverages the latest TCP IP security, whatever that is today and whatever that’s going to be tomorrow.

01:10:15
Speaker 2
Perfect. Cool.

01:10:18
Speaker 3
Another hour.

01:10:19
Speaker 2
I know, it’s crazy. Thank you very much. You have this incredible ability to just very eloquently just canvas everything that is happening in this space and just making it so simple and easy to understand. Thanks again for your time. I think we’ve just been over an hour ready. We really appreciate your insights. It’s always just an absolute treat chatting to you and as always, just hearing the passion and the knowledge for what is currently happening in our industry and so pivotal to its future. So thanks again for your time.

01:10:54
Speaker 1
Well, Yako, Lenny, as always, I appreciate the opportunity. Element eight is doing some fantastic stuff. I really love your outreach. I love the fact that what you said about what you guys did in Cape Town and what you’re seeing in South Africa. So keep it up. It’s fantastic what you guys are doing.

01:11:15
Speaker 2
Perfect.

01:11:15
Speaker 3
Thanks, Harlem. Cool.

01:11:18
Speaker 2
Appreciate it. We will do that and we’ll stay in touch. I’m sure we’ll have a couple of more comments and questions following this episode and we’ll be sure to forward those on to you. And yeah, let’s keep the conversation going. As always, it’s all about conversation.

01:11:33
Speaker 3
Hopefully not another six months, though.

01:11:35
Speaker 2
Hopefully not another six months. We’re not the holders of all information and it’s so important for the more people in our ecosystem that spread the news and the awareness and the education, I think the better off everyone’s going to be.

01:11:51
Speaker 1
Cool, great. I really appreciate it, guys.

01:11:54
Speaker 2
Awesome. Well then, thank you so much. We’ll chat soon. And as Lenny said, definitely not six months, right, Lenny, what do we. I think we promised a couple of podcasts. We spoke about the water industry. We were definitely going to speak to some consultants. We’ve got that lined up. I know we also have food and beverage in the brewing space. We have some podcasts lined up. If there’s any suggestions. I know our listeners have sent through some thoughts and ideas which we’ve used. If there’s any suggestions or ideas, please let us know. What is the email address again? I thought you were going to steal one email.

01:12:29
Speaker 3
So it’s podcast at element.

01:12:31
Speaker 2
Podcast at Elementate Co.

01:12:33
Speaker 3
Please guys, send us your topics and your ideas. Even people. If you want us to interview someone that you feel is relevant in the manufacturing environment, please get those topics and ideas off to us.

01:12:45
Speaker 2
Fantastic. We certainly not professionals. It’s a very humble podcast. We’re trying to do our small little part in just having conversations with different folks from the industry. And thank you for the support. We really appreciate it. And thank you for listening. It really is encouraging. And we’ll see you for the next episode in about two weeks time, I think.

01:13:06
Speaker 1
Great.

01:13:07
Speaker 2
Excellent. Thank you for listening and let us know if there’s anything. Be safe. Look after each other.

01:13:12
Speaker 3
Thank you. Cheers. Everybody’s.