Evolving landscape of manufacturing technology with Joseph Dolivo

In a recent discussion, Jeremy Theocharis and Joseph Dolivo shared their expert views on the evolving landscape of manufacturing technology. Watch the video below as they discuss a broad range of topics including the integration of Kubernetes and manufacturing, the challenges of running Ignition on Kubernetes, the benefits of open source software, and the future of factory control.

Highlights:

• Kubernetes and Manufacturing Integration: Integrating Kubernetes with manufacturing processes can significantly enhance efficiency and quality.
• Running Ignition on Kubernetes: Utilizing Ignition on Kubernetes platforms simplifies deployment and management of manufacturing applications. This combination offers scalability and helps manage complex systems more effectively.
• Benefits of Open Source Software: Open source software in manufacturing provides flexibility and can lead to significant cost savings. It allows for customization and adaptability to specific manufacturing needs.
• Future of Manufacturing - Unified Namespace and Control Systems: The manufacturing industry is moving towards a unified namespace, improving control systems for better efficiency. Azure's open-sourced RTOS platform signals a shift towards the virtualization of control systems, indicating a growing trend in the industry.
• Virtualization of Control Systems: In the future, control systems in manufacturing are likely to be virtualized, operating on the same hardware as SCADA and HMI systems. This trend points towards more integrated and streamlined manufacturing operations.

Transcript

Jeremy: Hi, this is Jeremy, co-founder and CEO of the United Manufacturing Hub and we're here today with Joseph Delivo from 4IR Solutions. Hi, Joseph!

Joseph: Hi Jeremy, great to talk to you today.

Jeremy: Yeah, it's nice seeing you again. I think the last time we saw each other is only a couple of weeks or maybe already one or two months back when we were doing our small US tour. And I remember we wrote each other and then we met in a small restaurant in San Jose. What was it a restaurant or a cafe? How would you call it?

Joseph: Yeah, I'd call it like a cafe. Definitely a nice sit down restaurant. It was good getting to talk to you. And we had a nice conversation as well about technology, but also about some other fun things. So, and yeah, what is time these days? It all kind of blends together. I think it was just a couple of months ago.

Jeremy: Yeah, I remember when we met there that I was really hooked because you said something, running ignition on Kubernetes. So I think that's also where I think the idea came from. We wrote it a little bit back and forth. Should we do like small blog article or should we do like interview like we're doing now? And I think the end result is clear. We're obviously doing an interview because I think it's... what you guys are doing is first of all quite similar to what we're doing but still very, very much distinct. So I think just hearing from you what you're doing and how you're approaching things, especially with ignition and the automation, would be really beneficial for the community. So just to get things started and get the conversation going, what is it that you do outside of work?

Joseph: Yeah. So I've always been a technologist at heart. So I've really enjoyed playing with technology outside of working hours as well. My latest, my latest thing has been playing around with a lot of the generative AI, large language models. So I've got some of those running. There's a little Intel NUC off to the side of me. I've got an old gaming PC that's been repurposed. Its GPU has been repurposed for running some of these. So that's been kind of my tech hobby that I've been playing with for some time. But my non-tech hobby has been raising children. So we're going to talk, I think a little bit about Kubernetes.

Kubernetes is hard, you know what's harder than Kubernetes? Raising children in today's society. But it's a blast, it's a lot of fun. And so I'm trying to do a lot more analog things with them as well. So, you know, keep them away from the screens as much as possible. I do enough of that, we do enough of that during our day jobs. So really enjoying, I live in the Bay Area, so we've got access to nature and hiking and mountains and camping and all that kind of stuff. So enjoy doing a lot of outdoorsy stuff with them and then just watching them learn.

Their fingers are a little bit more dexterous to be able to like play with Legos and do some of some of that building. So we're still on the Mega Blocks, which are just they're just not the same.

Jeremy: All right. And I think you already said something, the topic for the conversation today, Kuberenetes needs manufacturing. Of course, for us, it sounds on one side familiar because we're doing it as well. But on the other side, it might sound really crazy. So what is it that brought you into this field? Trying it out, what's your story?

Joseph: Yeah, it is crazy. And what I've been telling folks, especially our customers, is if you have to ask if you need Kubernetes, you probably don't need Kubernetes. So it's solving a certain class of problems at scale that you don't necessarily need to start off with. And to be frank, we didn't start out that way either. What got me into this was, again, some of my technology experimenting was playing around with Docker and containers. And I was running them on a laptop, and there's a member from the Ignition community formerly of the ignition community, named Kevin Collins, who released his own Dockerized version of ignition, and he made it available on GitHub. And so I was playing around with that, and I was learning about that. And it really got to, it got me thinking about how IT technologies and tools could be repurposed into the OT space, the manufacturing space, which I think as you know, has historically been really left behind. It's been 20, 30, 40 years, you know, A lot of the legacy hardware platforms, a lot of the software platforms have been kind of from that vintage. And it's really made it difficult for folks in that industry to be incredibly productive. And it's also been a barrier to entry for, let's say folks coming out of school who maybe get a degree in automation or software and they're used to these, being able to use Git for example. And then they come into the working world and folks are going, what's Git? So I really thought I could help close the gap.

And so long story short, really, you know, spun out this startup around bringing these IT technologies to the OTSpace. And, you know, going from Kubernetes from containers, initially to Kubernetes, when we all of a sudden had to do this at scale, and we had to do it across multiple clouds. And despite how complex Kubernetes is, it's actually the simplest way for trying to have a common layer between different operating environments like AWS, like Azure, and as you're

Jeremy: Yeah, fully agree on that one. Like for us, the decision to go to Kubernetes was okay. First of all, it was like playing around what's everyone talking about it. But then it was also about, we started with Docker and you get, it's really great and you can do a lot of things with it. But at some point, if you're trying to now to set it up on 30 devices, on a lot of different setups.

It abstracts a lot, but still there's all this configuration, all the volumes, and spinning up multiple Docker containers. Okay, there's Docker Compose, but you could only come so far. And we're using Kubernetes for the same reason that you do it, like just as an abstraction layer. So of course, reality is more complex. Like what's running on EKS might not be running on Azure.

Just because Kubernetes is not equal to Kubernetes, but still it's a great way to just put like a structure layer on top. And then also, and this is our main reason, it's about the configuration options. You have the option to have a whole stack with databases with everything around and just do like a click and start it up. And combined with the fact one that it's kind of agnostic. It's really great. But maybe going some steps back, what did you do before founding 4IR solutions?

Joseph: Yeah, so, you know, when I, when I came out of university, I had a degree in electrical engineering and a passion for software engineering, and I found myself working for a great system integrator in the manufacturing space called GrandTech. And that's really where I kind of zigzagged my career, doing everything from programming PLCs, you know, sitting on a bucket at three in the morning, doing line startups, and then the suitor, they could push me out of the PLC land into kind of the SCADA MES ERP integration world. That's where I spent the bulk of my career.

Then I was kind of known as the SAP guy, because I did a bunch of SAP integrations. And that got me into understanding the landscape of ETL tools, of REST-based interfaces, and so more into the traditional IT space. And then along comes Docker, and along comes the work that Inductive Automation was doing with Ignition. I had been working with Ignition as a SCADA platform primarily. But of course, it really is kind of an OT development environment. You can build all sorts of applications in there around IoT, around UNS. And so basically communicated with my, my past CEO and current founder and investor to say, I'd love to really do something new and novel and kind of go beyond the traditional system integrator route to actually offer this as part of a community to be able to serve other system integrators and other vendors as well. And it all started kind of around ignition. And so now we're basically providing what we call our mainline product, ie. Factory Stack and its sister product, Pharma Stack, where we want to be the stack of applications that you use to run your factory. And it's centered around ignition and similar tools that are these really nice, configurable, customizable development environments that allow you to aggregate data and also do control across all your manufacturing systems. And the reason we're able to do it at scale, as you know, is because we're using technologies and tools from the IT world. Kubernetes being main one but also things like infrastructure as code, also things like Git for version control. There's sort of this cloud and cloud adjacent ecosystem of tools that enable us to do these things at scale. And, you know, five, 10 years ago we wouldn't have even thought about doing this. You'd have to hire one person for every plant you wanted to support, for example. And I'm sure you've experienced the same.

Jeremy: Yeah, definitely. So I think you already explained a little bit what my next question, like what's your company doing now? Maybe you go a little bit into the topic. I still remember you said something like ignition as a service or you said like applications that you can host. Maybe you can go a little bit more into the details there, how this typically looks like.

Joseph: Yeah, totally. So, you know, ignition is, like I said, it's kind of a platform and there's other platforms that are in this space where they're allowing you to build OT services and by themselves, they're valuable but where the real value comes in is as part of an ecosystem of other tools. So for example, for any non-trivial ignition application, you're gonna want a database. So now I've got to orchestrate, we'll come back to that word later, gonna orchestrate ignition with the database, with the version control system. Thats a unit of packaged up software that traditionally OT folks haven't really had the skill set or the time or the energy to be able to maintain themselves. So that's really what we're doing is that we're providing the management of these systems at scale and we started out running it in a cloud tenant that we maintained.

And of course, there's always being OT folks, you know, you can never not be able to control your plant if you lose cloud connectivity. So there was always this requirement to have something at the edge, something on site that would be doing your, that would be your local SCADA node or your local HMI and your kind of store and forward data buffer that always needed to be the case, but we just wanted to start out. Our MVP was just, we're going to host something in the cloud to give you reporting, visualization, alarm notifications, all of that in one place. And we would take care of everything around the environment. And you would just build your application, your ignition application for your plants and then we would help you run it. Then of course we had organizations that said well that's great but we have our own agreement with a cloud provider. Can you run it inside of our tenant or our subscription? So then we had to figure out a way to evolve our products to go beyond an environment that we fully controlled into a customer's environment. So we started supporting deployment into you know multiple subscriptions, multiple tenants and then some of those tenants and subscriptions were in a different cloud provider. So we actually originally started out on AWS. We had customers that we need you to run in Azure. And so now we needed a multi cloud solution. You can see where Kubernetes comes from. And then most recently, and we talked about this back in September as part of our conference, we have a lot of customers who said, well, yeah, but what about that edge piece? So can we use the same tools and technologies that you're doing in the cloud? Can we do it in sort of a hybrid cloud environment or an onsite or an edge environment? And so that's been our most recent area of R&D and our newest product launches basically doing that on premise as well. So that's a whole new set of challenges, but it's really interesting and I think it really moves us into a space kind of like where you guys are doing, where you're seeing the value of running Kubernetes at the edge and on site.

Jeremy: Oh, interesting. And what would be things that you make? Or like, what would you say, where is your sweet spot in the future? Also thinking about the United Manufacturing Hub. What do you say is like the things that you really want to focus on?

Joseph: Yeah, and well, I wanted to say what I love about what you guys are doing is a couple things that I want to ask you about, but especially the focus on open source and the focus on, you know, making technology and tools available to folks who otherwise may not know how to do it or may not have familiarity with it. So I've been being able to run that anywhere. So we're trying to be a solution to running your manufacturing software anywhere, regardless of where it is in the cloud on premise.

Jeremy: Yeah, so I looked at your website and you also have, you have like factory stack and then there's also pharma stack, if I got the wording right. And you wrote that you're using it all in a qualified or validated environment, FDA approval or how we called it 21 CFR part 11. How does it work? Because I think there are a lot of companies in the unified namespace field and pharmaceuticals that- they want to use it and they also see like a lot of benefits, but so it's like a little bit hesitant. Wow, about validation because as you know, the software costs are much more smaller than the validation costs of everything. So how do you approach it?

Joseph: Yeah, it's very true. And it's been a very, I'll say a tough nut to crack, if you will, in terms of the industry, it's been very siloed in a lot of ways. And so a lot of the vendor companies that you see, for example, they focus their entire business on pharmaceuticals and life sciences because it is so highly regulated and a big part of the costs of doing those projects is the software licensing, like you mentioned, but it's also the documentation. So companies in that space have full-time quality teams. They have quality folks that they will have on contract as well to help them with audits and all this kind of stuff. And so the opportunity that we saw was again, you look at how slow-moving that industry has historically been because it's been tied down by some regulations, by some limitations in tooling. And so the first product we envisioned was actually PharmaStack. In developing that, when we really realized everything that was involved in doing that, we brought on a quality partner called Brevitas to help us with preparing. We realized that the stuff that we're doing, the version control, the change control processes, how we're sort of decoupling the application configuration from the environments, all that stuff is not just useful to life sciences companies, it's useful to everybody. So we said, well, we can release earlier to market with this factory stack product, even though our original focus and intents and the reason we exist was really kind of around the life sciences industry and pharmaceuticals with Pharma Stack. So that's kind of how we sort of expand it out. But to your point, there are a lot of challenges with doing that well. And for folks that maybe don't know the industries well, the one thing that life sciences really tries to enforce, which I actually think is a good thing, is that you're doing what you're saying that you're doing and you're able to provide evidence for it.

Integrity. That's another key word that we hear a lot about. So how can you verify to me, what evidence can you present to show that the data that you collected at the sensor that has all these regulatory requirements like having to stay within certain tolerances has to be sampled at very specific frequencies? How can you verify to me that data has not been tampered with? And I may have to go back in seven years. So in seven years when an auditor from the FDA comes knocking on your door and says, show me that you were collecting these temperature and humidity readings from four year ago. I need to be able to demonstrate that I not only have that data, but that it hasn't been tampered with. And that's an incredible challenging problem, I would say, for folks who maybe haven't done work in that space before. But it's also very important, and I understand where the need comes from. So hopefully that provides a little bit of a little bit of background and perspective on what we have to what we have to achieve.

Jeremy: Maybe one side note for people who don't know the pharmaceutical space, even though Joseph is sitting in the US, the FDA regulations actually apply to almost basically every country has their own regulations, but basically everyone is, especially the pharmaceutical, is following the US regulations there. So even though we're talking about a very US specific thing, it's basically the same in every other country. Just as a side note there.

Joseph: Very true.

Jeremy: And out of this, I think one of the most exciting parts, how did you get like ignition to run on Kubernetes? It seems to be like different worlds. Like on the one side you have Kubernetes, it's Silicon Valley, Silicon Valley Bay Area world. And then on the other, you have like ignition, which like the manufacturing world. How did you get it to work?

Joseph: Yeah, well, the Kevin Collins community member that I had mentioned to you, so inductive had the foresight to actually hire him on full time. So they said, rather than us come up with our own strategy for containerized ignition, we're going to leverage the strongest person in the community to do that. And so since then, he's somebody that I've been working with very closely where we're providing a lot of feedback to inductive automation as to how to make their products a better fit for running inside of this environment. And then the Kubernetes ecosystem itself has been evolving to better support these kinds of use cases.

Because if you think about Kubernetes, and you know this Jeremy, it's really strong in sort of the stateless workload environment. So if I don't have to carry about state, it's really, really good at letting me put a load balancer in front of a bunch of services, and I can very easily scale out to a whole bunch of things. Software recognition is not like that. There's states, there's the current value of tags, for example, you're holding all this kind of stuff in memory. So, but Kubernetes as an ecosystem has evolved to have much better support for workloads, namely stateful sets and things like that. So, so we've basically taken this sort of packaged up containerized version of ignition, and then we've injected a lot of Kubernetes specific things into there to enable it to run really, really well. So for example, when you first provision an ignition container, we do a bunch of stuff to initialize the deployment of that, where we're taking their configuration, we're injecting things of this workload to get it ready to go. We're using volumes of course, those volumes can be mounted to sidecar containers where we can do things like take backups to do version control with Git. So we are able to kind of have separation of concerns like you would want as a best practice. And then we use orchestration to run Kubernetes commands to do things like taking backups.

To do migrations, to do upgrades. So we have all of this tooling that we've really built around the Kubernetes ecosystem and what that's enabled us to do. And then Ignition has kind of evolved to be better supportive of this environment. We love to do it with other software as well. Some of it is getting there, but it's not quite as mature. There have been some recent releases from, I know you guys use HiveMQ as well. So HiveMQ is actually, I'll say ahead of the game in terms of having an operator. More Kubernetes native way of supporting that flow as an official container as well. So we are seeing other kind of the more commercial enterprises getting there in terms of their support, but there's still a long way to go, I would say.

Jeremy: Yeah, I would definitely say it's a long way to go because in my experience, yeah, putting it in a Docker container, at least this is like my opinion of what I've seen in manufacturing. A lot of companies, manufacturing software companies, they're like, the salespeople are like, okay, we need it now in Docker container and then they somehow put it in a Docker container. But it's like, toyed around, like it's not thought through. So you have like, even though it's Docker, then you still have to manually move something into the volumes or something. And like the Kubernetes way of thinking is like, Hey, just press a button and everything starts up from scratch. Let's be very explicit about where we store files and storages. I've seen like a Docker container where you just had to mount like the entire host root system, and then would like use like libraries in there. So it's not one thing that we tell our customers. Unfortunately, when selecting solutions, Docker does not equal Docker, like HIFMQ is, it's obviously much better. What specifically is the small things like all the configuration is stored in a file. So that in Kubernetes, you can just put in a standard file.

In the Docker container, it doesn't store like random configuration things. It doesn't, of course, maybe you can change by API or et cetera, but how the Kubernetes way is, it's like you have a fixed config file, you put it in and nothing else, maybe some temporary files, nothing else around it.

Joseph: Yeah, I'll tell you, it makes it hard to go back to other software tools that don't support that once you've kind of tasted the beauty of that, right? I've got my configuration, I've got my environment, and then I can spin them up and spin them down as needed. Really hard to go back to more legacy software products after that.

Jeremy: Yeah, this was also like my journey. Like we went through it and once we had it and once we were used to like, okay, let's really just double click on something and it's installed. So no more 30 pages, 46 pages document on how to install an IoT platform, whatever. It's just like, it's always there. If it crashes, it's fully automated to recover everything. Yeah, maybe one thing. I had an interesting discussion a couple of days or weeks back. What would you say is the acceptance of Docker manufacturing? Because sometimes I still hear people are like, who Docker? I've never heard about it. What's your experience with that?

Joseph: No, it's a it's a great question and I'll say we've got a couple of different Classes of customers that we tend to work with some of them are folks who don't know what docker is And they don't necessarily care because we're providing the managed service how we provide it. They don't necessarily care as much.

The other side of folks is folks who have more of an IT background or working with a lot of corporate C-level folks who had got a background is like a, they're like CIOs or CSOs or CISOs. And so when we start talking about Kubernetes, we start talking about containers, they get it because that's what they're familiar with from their enterprise systems. And so for them, it's actually kind of a motivator. They're like, oh, you're using containers. You're using Kubernetes. I get it. I'll they're actually much quicker to sign off because they already have an appreciation for what that can do.

We've been maybe fortunate in that again, because we're managing on behalf of our customers, they don't necessarily care. They just care about the value that is going to create for them and the benefits that they see. And the fact that as an example, when we have to do upgrades, because those are of course, a necessity for security reasons and everything else, the fact that we're able to have very short maintenance windows because we're using this tooling, they see and benefit from the effects of that. They don't necessarily care how it's done as long as it's done. So it's more of a tool for us. We could do the same thing by spinning up VMs and we could download the ignition installer and we could click through the GUI and do all of that, but we wouldn't be able to do what we're doing at scale if we took that approach.

Jeremy: Yeah. It's exactly like how we landed up, up at it. Like at the beginning, we started by just installing that also like doing like updates. And that was just the point like, hey, you can have a, have a person. If you need to update like 30 devices, yeah, you can do this clicking through it. But if you like start hiring a person for that, this person will do like random mistakes. In the best case, the software will fail immediately. In the worst case, the person clicked a button, disabled the cache or whatever, and then the system only fails like a year later. Like 30 installations, 23 of them are working immediately, but in the long run, only 50 of them are working because someone just forgot to do something. Are there any questions from your side?

Joseph: I definitely do. And I'd love to really hear you guys made a very conscious decision. I remember you went through a licensing change as well by having an open source open core product. So I love to hear about your decision making in doing that. And also what kind of benefits that's brought you by taking an open license approach. Because I think for a lot of folks, especially manufacturing, they hear open source and they kind of they pump the brakes a little bit. It makes them a little bit nervous. We'd love to hear about your experience with that.

Jeremy: Yeah, so maybe two things. There's like first why we use open source and then the shift from AGPL to Apache. Why open source? It was just like, what's my backstory? I was always an IT nerd but then started mechanical engineering. And when I was doing my first industrial IoT projects I just saw how many millions you can spend on manufacturing software. I don't want to do any names here. I don't want to get sued. But how many millions you can spend there and how less you can actually get. And because people are in this bubble, it's hard to think outside of the... to think outside. And because I was like an IT nerd, I just knew it. I remember there was this note read. Can't I just do exactly the same? And this is like, by the way, like what most of our customers like... they have a very similar journey like they see manufacturing, then they're like somehow contacted with or confronted with IT and they're like, but it's just two different worlds. And then IT, if you think about infrastructure, open source is the norm. It's not a manufacturer, open source is super rare. But if you take a look at it, because even like manufacturing IT is a sub part of the global IT, everything that has to do with computers... like open source has already won. There's no discussion about it. Of course, 20 years ago, there was still like Microsoft fighting, fighting against Linux, this type of things. Uh, then they bought like GitHub for like 2 billion or something. Um, they're, they're putting Linux inside of the Windows operating systems. Like I can give more and more examples. Docker is, Docker is, it's not a question to use Docker anymore. Like Kubernetes is okay. It's more like a, uh, can be a philosophical decision whether to use it or not, but like Linux, Docker, Kubernetes, basically every large infrastructure thing is currently open source. So that's what we were using those tools anyway. So that was like the first thing, hey, we want to make something big here because we saw we're going from customer to customer. It's already a couple of years back, but from customer to customer and we could... we would be so much quicker by just using open source software. And we were starting to use always the same type of software. So that's when we decide, hey, let's do something really big here and put this collection of tools also open source, all this pre-configuration between it, so that you can just use it immediately. And at first, it was a JPL. For people who are not familiar with this, Apache. No, no, sorry. AGPL, Afero, AferoGNU, I cannot do the name, but basically what it means, it's less permissive, it's a restrictive license, which means you can do whatever you want with it, but every time you do a change, you need to provide the source code with it. And our thinking behind it was, because we're even using the AGPL, which means even just hosting the software would mean that you need to provide the source code to all of your customers. And our reasoning was, hey, maybe in the future you want to do like hosting as a business, like hosting, stack something, I think, but what you do maybe in the future, we just wanted to start with a very restrictive license and basically just ensure that for the customers, they don't care. Like they have all the source codes. Okay, it's fine. But for like copycats, people who want to just copy it, that they... could not host it or do another business on top of it. But at one point, we were like, hey, that's really not our business model. And hey, we actually want to encourage other people to do exactly just that. Because our business model is, when the enterprise environment, so our business model are licenses, and mostly there are... so many small to medium sized enterprises out there that can really benefit from this, but let's be honest, they don't have the budget for digital transformation. So our thinking behind it is let's use them. Let's put it open source. Let's give them everything for free. And we expect like there will be 100 customers in SMEs, not customers, like 100 users in SMEs, but... one percent of it will give something back. It will be just feedback or the discord channel and if you start adding it up we would start to create community and we can start to build actually very good product because we're getting all of this feedback for free so that we can actually build a very good enterprise product because I think this is problematic right there right now A lot of salespeople selling you everything, but then you realize you're like the first customer. And what we can do is it's already battle proven at a lot of different users. And that was the reason why we decided, hey, let's go from the AGPL to the Apache license. Basically say, whoever you are, take it and start selling it. If you're a small system integrator, go ahead. If you are a for IR solutions. You could theoretically just take the United Manufacturing Hub and integrate it in your product offering and offer it to your customers. Like, that would be totally fine for us. What we're doing right now is because the next question is going to be, hey, how do you make money? And our thinking behind it is there is the Give me a second. I think I just lost track. The editor who is going to cut this video, we can just cut this part out. So we're going to add some commercial add-ons on top of it. So the course open source, which is also by the way really important for the customer because they don't want to have this lock-in effect. So they can ensure it doesn't matter what happened with us, the data of our structure, what... the place where they build their entire company in the next 10, 20, 30 years on. It's open source in case anything happens to us. We was suddenly rate charge too much money, whatever. They can always like move it away. But then additionally, we offer like, um, commercial add ons like, um, or the community at us, like the management console. Um, I don't know if you have, have you tried that out yet? Or have you seen it?

Joseph: Yeah, yeah, I have. No, it's great. I love what you guys are doing. And I think it adds a lot of value because it's something not unlike what I've seen with other tools where sort of the, let's say the tech space or the command line interface or the API is kind of free. And when you want a nice visual GUI on top of it, that's something that you can productize because it's really the user experience and the ease of use that you're building. So I think that's a really great model of what you guys are doing.

Jeremy: Yeah, so we even giving this, it's not open source, but it's community, so everyone can use it for free. But there are some certain limitations, like there is the part where in the future, there will be only maximum amount of users that can use it. So what we want to do with this, so that as small to medium sized enterprise, you can use it because probably only have like one IT OT guy anyhow. But then. The next thing is if you're an enterprise and you act like you're large from a suit of company or energy or whatever, and you actually want to use it, you will always buy something and you're always going to buy for compliance. It might be the option that you can have multiple users because multiple users working together with audit trails. It can be that you get like a list of other used versions in your software because you... You need, you're legally required to have that. It can be because of required support level agreements. So this is like our thinking behind it. And also why we think, Hey, it's, it's not dangerous for us. We can put everything open source there. There will be all the people that make money with it. They will help us. Um, if they're like, actually like some really bad people that take it and try to make a competing business model, it will be quite hard for them because we still have like control of the open source project and I don't want to go too much into detail here and bore everyone. I think I'm already talking too long about it. But that was basically the idea behind it and why we're also very confident that this can exist in the future. It's already existing business model open source. We're just using it and we can guarantee you the data infrastructure will be open source forever. It's also not something that we can take back.

Joseph: Yeah, no, I love the mission and you're right, you're building on a proven business model and I'm really a big believer in what you folks are doing. And you know, ignition aside, it's nice to see that we've sort of converged on similar open source technologies. So between Grafana and HiveMQ and TimeScale, there's a lot of really great best in breed technologies, which also have an open source or open some level of an open model that encourages the community building part that you guys are doing. I think that's great. If we've got time, I did have one more question for you if we have time. I'd love to ask you to kind of look in your crystal ball, if you will. And if you look ahead to where manufacturing is going, I'd love to get your predictions on where you think the industry is going to be going, let's say within the next five years and where you see UMH being as a part of that.

Jeremy: Yeah, so of course, like a crystal ball go, it's always hard. But what are like some current trends that I currently see? First, I really see this unified namespace thing. It has a name. We were doing it before it had a name, but now it has a name. And the main reason is we're now 10, 15 years into the industry 4.0 thing, and nothing has changed. slow, the industry is very slow, but they are getting to the point, hey, we need to do something different. Like we cannot go to the next system integrator, pay 500 million and expect an expected result. So people are picking up the unified namespace because they're absurdly frustrated with what's going on there, like me and probably you as well. So I think this will continue to grow. There will be... still like this, let's call it the world of OPC UA, there will still be this, but I see that even the large companies, they're slowly, because they're not getting anything done in the traditional way, there's just like, more and more people, they start to look for something else. So I think really that this will make, this is really making a move. And will it take two, three or four years? Okay. It's hard to measure, but this fraction will get stronger because it's happened in every other industry as well. Manufacturing is like one of the last industries to be revolutionized by IT best practices and it will happen there as well. So over the time, there will come a point where the people at OT or like traditional vendors are like realizing, oh, Then we were like, oh, and that probably will be too late. We can always see some vendors already going, trying to keep up with all the modern stuff. But I think too many traditional vendors made it too comfortable in their sector. Looking at historians, for example, just continue to milk the cow. So I think that in the next couple of years, there will be some kind of boom where people will realize. Why do I need to pay millions when I get everything literally for free and 10 times better features? So there's something that I think with the movement of unified namespace will happen in the next five years. And how we see each other? The United Manufacturing Hub as the part where the data flows. Because it's ridiculously hard to manage. the data flow. And it's even harder to make a very good user story, kind of like an Apple-like user story around it. Normally, you have all the IT people, like Spark, Flink, whatever. It's not possible, because the people on the shop floor, they are like electricians. They come from automation. They still need to be able to do it. So we see ourself as this open source piece that's the core of every factory just because. just because it also doesn't make sense to do otherwise. Core of every factory. And then we're going to, like I said, I already explained the business model, but then there will be a lot of, it's our vision, a lot of companies around it, such as yourself, that focus on different layers, maybe more on the automation, maybe more on the application layer, maybe on the AI. But in the end, in the middle, this is our version. There will always be UMH, either as a paid or open source version that just provides you the data. And with this UMH, there's also all the tools that are behind it, like Node-RED, HiveMQ, Kafka, et cetera. It's a great tool.

Joseph: Yeah, no, I love it. It sounds great. You're building an ecosystem and I think it's really exciting and we'll see, we'll see where the industry goes in the next couple of years. That's great.

Jeremy: So maybe to wrap things up, what is it that you can offer to the typical UMH user? It's like always a final question in my interviews. So imagine now you're hearing this and you really love these ideas. Wow, using ignition, Kubernetes, hey, I'm small to medium sized enterprise, hey, I'm farmer, so this sounds really interesting. What's the way so that they can get started or should they get in contact to you? How, what is it that you offer to a typical U of H user?

Joseph: Yeah, totally. So feel free to check out our website. We do post some architecture diagrams. I'll say they're not as nice as a lot of the great deep dive technical blog posts that you go through, Jeremy, but we have some technical diagrams if folks want to get a sense of what we actually do and how we do it. But you can contact us through the website or myself personally to kind of just have a discussion. So we're really in this space together, I think of educating and trying to make the pie bigger as opposed to fighting over little slices of it. So I love to have conversations like that.

We're primarily focused on ignition as a platform because it makes our lives easier. So if folks are looking for more SCADA workloads where they're not only doing a lot of that data collection and reporting, but they're also doing control, distributed control, that's I think a complementary area to what UMH is doing. And so you can have both, right? You can have UMH where you're doing your UNS building and maintaining of that system. And then you can plug in ignition as either a data source or a data sync from that. We think it's a good complimentary offering and we're using similar technologies. So again, we're all, we're all built on Kubernetes. So I would love to have a discussion and see if there's a, there's common, common interest there and to see, uh, yeah, just to, to have those voice of customer engagements, to know what are folks looking to do, what are they interested in? That's how we've evolved our product to where it is today. So love having those conversations.

Jeremy: I know I said I want to wrap things up, but I just had one, I hope final question. You said control. How do you envision the topic of controlling the factory in the future? Because to give you some perspective, there are PLCs, there are real-time networks, there's real-time Linux kernel. Some companies, I talked for example with Yosef from SDA.

Joseph: Yeah, we tried a sort of a marketing blurb for a little bit. We tried control from the cloud. And we said that because we knew it was going to be controversial. And the big asterisk on the end of that is, again, I can't not stop a motor or not close a valve or not run my pump if I lose internet connectivity. So that's always been a bit of a tongue in cheek comment. There may be a time in the future where we've got 7g modems at every piece of equipment and there's perfect connectivity. There's no There's no interference from the high horsepower motors and stuff like that where maybe you'll have everything directly connected up to the internet If that time comes at all, I think it's gonna be a very long time away and so I think there's always going to be a need for local hardware, but I do see a point as we're looking at, I think Azure just actually open sourced their RTOS platform. You're seeing the real-time Linux kernels, like you mentioned, we're seeing a lot of companies, code assists, Siemens that have kind of virtual PLCs, where you are able to run those as well. And it's always been the case, you look at, you know, the ITOT conversions that's been happening and you look at ethernet. So all of a sudden you had a lot of the legacy control-based protocols like ControlNet are now, you know, you have Ethernet IP and you have OPC UA and you have MQTT of course that are all kind of built on Ethernet technologies and Ethernet has is a not deterministic protocol. However, if you work within certain constraints you can have pretty close to guarantees on what your latency is going to be. So it enables you to do things like, like I remember when SIP safety and SIP motion were coming out a little bit ago. So you can do more with traditional IT networks. So I do foresee a future, maybe not too far off, where we're going to actually be able to virtualize a lot of the control. We'll be able to run it on hardware that is this might be the same hardware where you're running your SCADA systems, your HMI systems, and your other manufacturing systems. So I do see that coming in terms of having nothing on site at all where the machines are connecting directly up to the cloud. That seems a little bit far-fetched to me.

Jeremy: All right. Yeah. Thank you for your take on this. And thank you for taking the time to talk with me. And yeah, to our viewers and listeners, as Joseph said, you can contact him, you can find more information on by just Googling for IR solutions, or if you're watching this as a LinkedIn post, you can just click on link and then you'll be automatically redirected.

Joseph: Thanks so much, Jeremy. Thanks everybody.