Welcome back to the automation podcast the world's number 1, Industrial automation product and technology show. Thanks to you. Our audience of highly skilled automation professionals. Thank you. For being a member of our audience, and thank you for tuning back in this week. Now for those new to the show, My name is Sean Tier of insights and automation and each week, I invite a new vendor to come on the show to tell us about their products and technologies and during the presentation I play the role of the audience, asking questions, I think you have and of course, questions I have as well. With that said, given that a quarter of our audience doesn't watch but listens to the show. Right? So whether they're on Apple or they're on Spotify, or they're on Youtube. A lot of you told me, hey, I listen to you on doing all other things. So because of that, I'll try to call attention to any details in the visuals that I think you listen only folks may wanna know more about. And with that, I wanna welcome back Adam. He's been on the show. This is a third appearance. He's from Ko Automation. He's told us all about get based sauce natural. He's told us about the vice link. And it's great to have him back. It's been about 18 months. So he's back on to tell us what's new and happened. He's got some excited exciting things going on? And so with that, Adam, I kinda built you really big. Can you before we jump in and talk about what's going on with your company. Can you just give us a little introduction for those who are new to the podcast of who you are? Yeah. Absolutely. Yeah. Thank you so much. And I'm I'm definitely excited to be on the the show again and this we'll be talking about, you know, industrial devops and and building out this idea of this industrial devops platform instead of practices. But the component piece our source control device link. So it's almost like that natural progression from the shows we've done. So it's super we're coming me back. I'm in terms of my background, as mentioned, I'm I'm seeing founder at Ko automation, working on Ko for half a decade now. Company has kinda formally found it 4 years ago. You know, before Ko, I was on, kinda group up as a software engineer. Was on engineering strategy At Uber, I worked on at the overall back end systems architecture, my skip level was the Cto as part of the office the Cto. Was working on driver platform features. So also just how you go the the driver app, for that, I'm maintaining exponential growth within the head count of the engineering team there. So I kind of cut my teeth in devops and then moved into the industrial automation. World focusing specifically on, you know, how can we bring those devops ops practices from the It world, and make them work with and the the Ot environments that everyone who listens to your podcast is familiar with. So we'll dig into, a lot of that story of how that works and the problem and and how our platform solves it along with is generally thinking about, you know, industrial devops as as a set of practices. So with that, I'll just jump right in. We'll go through a few different things today. We'll focus on. You know, I'll give a little overview of Ko. I just did. I'll get a little bit more detail just so you all know. Little more about me and where I come from, the problem, you know, that we're kinda facing the solution thinking about Ko Industrial devops platform, as well as as industrial devops offs generally, you know, throughout this, you know, happy to answer, you know, questions as well. So Ko, at a glance. And this is kinda fun because, you know, we probably go flavors of this slide across our different showing. But we're found in 20 20. We start shipping product to users in early 20 21. Since 20 20 Ko has raised 30000000 dollars of funding from top investors who who tend to be you know, invest in the industrial space generally, so the boards of various other, kind of fast growth, high impact, industrial vendors. C consistent growth adoption. Have over 2000 developers using the product now, and a hundred and 35 customers individual, you know, companies using the the the product. We try and compose our team of world class time from the It and Ot space given that the blend of the product is from both this basis, and we have companies like Google, Apple, Microsoft, you know, as well as industrial vendors, Siemens and Rockwell and all those as well in within our our company. So we do really try and maintain a foot in both ponds in terms of It and Ot. So in some sense, our company itself as an It ot, convergence business, and our platform is to demonstrate best class stickiness. We have high user satisfaction, consistent growth in in product engagement. And so that's Cop. But you'll hear me talk a lot about industrial devops and it's something that we're really big on. And for the the people who are just listening, you know, on the screen, we have kind of this timeline of Devops. But Devops is is now at this point around a you know, over 15 year old set of practices. Kinda born in 2007 to 2008 in the It space, you know, there is lots of traction gained through conferences, thought leadership, etcetera. 2012, the state of Devops report is established. In at 20 13, the Phoenix project further builds the case for widespread for Devops adoption Ga, and 20 16 predicts mainstream adoption, I'd say by 20 16, you're already seeing that the top tech companies, even in the world had adopted these practices at uber where we had already been doing them for 2 or 3 years at this point, companies and you're hiring companies like Google and Facebook, etcetera where these are standard practices. Microsoft was is a major contributor to get. I had to use Github a couple years later. Obviously, github gets acquired by Microsoft. Forrest or calls, in 20 17. This the year of Devops, so devops be begins by then 2000 tons becomes very, very hot. And I'd say, you know, you get to a standard set of practices in that time period around. Get and get based practices, and and you know, test driven development, monitoring and learning a lot of the modern type tools by the late 2000 tens have been established. In 20 20, we are found it with the goal of taking that kind of success that been born out over 12:13 years and bringing it to the Ot space. You know, a book came out last year by doctor Su Johnson, and Robin Yemen, which is focused on industrial devops. So... And, you know, we'll be publishing, the first annual state of industrial devops report, which some... It should come out, actually probably comes up between this recording, and and we publish. And then in 20 24, Frost sullivan names, industrial devops to top affecting growth opportunity, industrial automation. So We've kinda seen this in some sense we're in this, like, you know, we're almost in the 2012 or 2011 of devops adoption the It space. Where it's becoming recognized. We have a industry report, industry analysts are recognizing it, and we're seeing it amongst star customers and opportunities that people are familiar with the term and are thinking about it. In terms of their strategy. And so my hope here is I'm sharing this out with everyone here is that they're thinking about their overall Ot strategy within their organizations. And thinking about industrial devops as a, component of that strategy, and as you'll see specifically around, you know, governance and control of the code that runs your plan of the Ot devices there. And things about specifically in a way of driving efficiency for your engineering teams doing more with the less for the engineers you have. In terms of driving up uptime and ultimately driving quality in terms of the production that you set up and and then end product that you develop. All these beautiful phases, that that you all can't see on the podcast, our leadership team from Me as Founder Ceo, Matt, Rv of business development then, Andrea Margaret, Heavy. So it a strong team again, brought cross functionally across this group. You have Rockwell. You have you know, Siemens in this group y'all also send me from Uber, you have, you know, a best in class, you know, It folks as well. So with that, any questions on this then I can dig into the problem, but coming out of that stuff. No. I would just say if people wanna get more of the background, just check out the previous episodes had Ko. We kinda dived into a lot of that good stuff really deep. So go ahead, Adam. Yeah. Yeah. And I think the big thing, you know, just to leave everyone with is as we dig in the problem is, you know, these are a set practices. And as you mentioned, like, we've... This our third time on the show, but we've been talking about industrial devops for 40 years. And so I think the exciting time, especially people are you're tuning in right now. The first time is, like, these are becoming recognized practices, and as we're talking in more and more customers and more and more opportunities, more and more people are meet our our, you know, sphere of of conversation, we're just seeing that term kinda take off. And I saw, you know, a talk in Germany around industrial devops. You know, that didn't have any vendor that was was talking about industrial devops. So just a group of you know, people talking about, you know, how do we bring these practices in our organization. So we're actually seeing people use this terminology and and think about this. Obviously you're picking that up in in analyst reports and that sort of thing. So I it's it's a real term. It's a real set of problems, which I'll talk through that are industry wide, and I think there's a set practices that are coming together, they'll try and share out in this, that can be transformative for controls engineering organizations. So the problem, this is fun 1, but, you know, trello of dollars of global production distribution I workloads are fundamentally broken. And you kinda see here, you know, and I I think everyone who's in the Ot space has run into this of proprietary file types, every vendor does something slightly different, bespoke protocols, opaque interfaces, physical file sharing. People don't test their code, a lot. There is some testing, but it's it's it's either expensive of Sims or there some platforms as support and money unit testing and and ultimately, very limited visibility. Into the operations, you know, of what's actually happening. So something breaks and you don't know why, is it really common situation in in the industrial plan for. And so all of these make it really hard to build the workflow. That our products sells for. And then if speed to market is a survival imperative. Obviously, we see a lot of production coming up. And we see that a lot of building is bottleneck by industrial code. And so, you know, obviously, you know, you... On top of that, you have, you know, some of this, like, cyber Ot questions, as it around ransom wear attacks. There's a lot of access that people have 2, third party third party access to Ot environments. So you run into, you know, for example, air gap as a standard practice. But then people can actually just kinda connect to an industrial network and get access these the devices. So actually, visibility into changes is a major part of security, a lot of time we actually get brought into sales process because people have a ransom attack or they need disaster recovery because of they they need to ask recovery because they actually had situation that happened. So... And that's a very, very common situation or as It conversion starts to happen, Cios and Sis take over, the networking that exist on the plant floor, they see it as a security gap. And so this is part of that overall. Teaching stories, like, how do you actually lock down the devices there. And then, you know, generally speaking, as we talk about devops, this is the outcome of applying the most trusted principles in the domain of physical manufacturing leadership with the It stream. So it's kinda interesting. There's this kinda circular thing that has happened where, you know, you have lean manufacturing and all these practices, then applied to It, It adopted them built devops, and now it's kinda spreading back into Ot. There's kind of an interesting thing here where we think about this as, like, an It came up with all this stuff. But, actually, It, you know, in the early 2000, so they came up with this or borrowing from you know, lean Toyota lean manufacturing, you know, all of that stuff in order to come up with Devops in order to comp the agile. And now we're seeing this on almost like, you know, kinda circling back into the the Ot world. When we talk about the It Devops approach. And there's a lot of stuff that is bucket under Devops, But when we talk about it at Cop in the way that I think about it, it's tied to a standard set of processes that go from the the code being written in your Ide id once that works complete, how does it actually get onto a device. And so what that looks like is git based source control collaboration, if you're putting everything in good version control system, you can do recovery faster and you can actually root cause issues. It's very common for people, for example, to power cycle or reset Plc without root causing an issue when happens in production. And so having that kind of change history. Understand what broker or why a particular run might exist. You know, your ladder or whatever can be help you recover, but also root cause, automated testing, How do you catch issues before they become production issues. Deployment management. How do you actually get code on the plant floor in in an efficient and safe way? You know, I've heard before people having to do physically fly out, you know, don't plants and and that sort of thing as well. How do you actually, gate the processes by which code gets deployed, you know, also on the flip side of that you get people now who, especially have Covid Vpn into plants and just deploy code changes remotely. So how do you actually manage and gate, deployment and production? Then ob monitoring, like, what's actually changing. Do you actually have visibility and what's changing those environments. And that's the It approach what you see in the current industrial world, you know, is a lack of backups and data file storage, which at least 6 cent downtime, manual testing, you know, people are testing and production. They're turning on production to see if it works. There's obviously expensive Sims and and unit tests, and that's sort of thing like system in some places, but often or digital twin in the more stream case. Is a lot of vision on how to solve this problem but the reality is, both the time people push a change and... Honestly, the standard and a lot of environments online changes. You know, in word for People maintain uptime, but then you actually run into risk of of breaking things in production. So how do you actually test your code? Before you're making those changes to make them safer, manual deployment, you know, people are actually going on to sites to play. Obviously, line of sight is requirement in a lot of cases. But you know, going machine by machine to do deployment, and limited ability, which means that you don't actually know what's happening. On top of that, you know, and so this this is all stuff, You know, as you mentioned that we've talked about before in the script, But 1 interesting thing and, is this, you know, we've actually now try to determine. Is this something that we were kinda thinking about as a problem in 4 years ago. Obviously, you wanna start the company. It was a little, like, hey. I talked a few people. It seems like a lot of people had this problem, more and more people I talked to you seem like they had to. I probably spoken to 1500 manufacturers. There almost none of them have not had some flavor of these problems now. But this state of industrial devops report that we put together, which I'm sharing here. Talks about this, and we actually surveyed anonymous survey, 200, you know, industrial engineering leaders to ask them, you know, is this real Like, what are these problems? What are you seeing in these environments? And the results we're were really astounding. So we're seeing 4200000.0 dollars is the average cost of downtime. The interesting thing here, which is when I first showed this number some people they're actually really surprised by it. Instead of seeing really high. 1 of the just some things we found out is as you go higher in a leadership chain, they can consider the outage more expensive. Which is probably a result of them seeing more of the downstream effects. So you can imagine, you know, dependencies. On supply chain. You can imagine insurance costs, legal costs. Reporting to the board, you know, all of these things come into creating that, like, actual cost of of resolution over time, you know, engineering hours that goes into it. So while people think of cost of downtime in terms of, hey, we produce this amount of product per hour, you know, if it's fine minutes delay. We lost that on a product, but there's actually a lot of secondary cost that becoming more obvious as you go up the the site. The 50 percent attributed Plc Code related challenges. I think this is probably shocking to a lot of people. But it's something that we've also in terms of our analysis with some of our customers as well. But what what we typically see is there's actually a huge amount of Plc related changes in these environments, people resolve mechanical and electrical issues at the code layer because it's more flexible and then cause a downstream problem. And so we see frequent challenges, industrial value code changes. The other reason for this data point is there's just a lot more code in production, and this is actually even since 5 years ago when I start talking people about Ko, there's a lot more code in these environments, huge demand for, industrial automation machinery, and you see that you just have, you know, even compared to 20 years ago, just a lot more software driving driving these environments, which means that you're gonna have more errors in that layer. It's also hard to attribute those because they often manifest as mechanical electrical issues. So you hear someone say something like, the Plc stopped working. Right, which doesn't actually really make sense, because, ultimately, you had to make some sort of c change or configuration change or something. Or there's some sort of logic error that that kinda triggered, and this again gets to people, like, power cycling or resetting or something resolve an issue. But ultimately, we see that there's a huge amount of issues that are at the code layer. And then we see frequent mistakes are getting made, and it takes a long time to fully resolve each of these downtown events. So, you know, this gets in that secondary cost of, yes. There's a cost of the outage itself, and there's also a cost of resolving it. So we're seeing frequent errors and changes in these environments. As you have more automation, you just have more changes that are happening, and becomes a larger surface area for outages. And this is obviously pretty awesome because we able to pull it from, you know, 200 you know, industry folks, who were able to, kind of anonymously and give us this feedback. And then, you know, 1 of the big things we see here as a common cause of this. I think this is actually the most common use case and device link. And more governments in control and actually having a process for making changes your environment comes really. Challenging is that 1 of the biggest areas that cause these sorts of outages are ad hoc fixes. So we often see that, you know, oh, I'm just gonna make a small change and that it causes an outage. Right? And so we see that a frequent in cause of these changes is not like a massive new new production going up, but it's making a small change in a production environment then causing an outage. And so, you know, this becomes a major kinda of systemic problem within a plant. As you're seeing, hey, we're having these outages. Some of them, again, mechanical. Some of them are electrical, but some of them, you know, we say the Plc is executing wrong or restoring the previous version of our code resolve the issue, but we don't know if as a code change will, you know, there's a strong indicator if resolving in the previous version of your code solved solve the problem. So there's there's kind of these frequent set of small changes that are happening as part of a maintenance sustain motion that actually cause, kind of massive downstream issues. Any questions on them that I can dig into... No. That makes sense out adam. That made a lot of sense the way you presented that. Yeah. I mean, the crazy thing is, like, essentially, I've realized is as we've dug in really deep in this space, most sustain situations where you have a lot of automation code, people will resolve outages going through a series of different steps. 1 is the first reset their device, 2 the them power cycle if that doesn't work. 3, they'll just try and, you know, ship a backup in there. And then if they have someone who's really aware of the code, they'll actually make a code change. And what that means is you just the issue down the the stack because you haven't actually root caused it. Right? Mh. So fundamentally, you have this kind ongoing maintenance cycle that essentially looks like people not really having any visibility what change, and they just, like it basically brute force production, and you start to create use, like, kind of systemic, you know, cowboy and firefighter, we've called it, sort of issues where things are just breaking all the time, and and there's a lack of visibility into why. I was just talking to a young man who who's in my what my cost yesterday, and he goes out and service calls to all kinds of different companies making everything from, you know, Bagels to anything you can imagine, and that's where you see a lot of this happening because They don't have that trained staff. And so... But that's not to say that your product's is not good for trained staff. It's actually a gods send for trained staff. You know, an expert engineer can understand what you're gonna go through here right now and we've saw in previous appearances is this this helps everybody. Not just in person who may not be as, you know, as experienced as, you know, somebody's been doing this 20 30, 40 years. This solution is is good for all users. And, I'll I'll turn it back to you. Yeah. No. That's that's a great point. And I do wanna call out to that, a lot of what I've seen in in a lot of, especially more enterprise organizations is increased centralization of top talent and organizations. Mh. Or contracting out to system integrator. We're doing support. So, you know, where we actually to your exact points, see, like, a big a big value add here is if you are an expert user of the product, and you're trying support a site. In general, being able to say, like, here's what change. I'm gonna go actually fix the code of underlying logic problem more or maybe I'll do a backup I'll use a backup, and then I'll go fix it. You know, as a follow on so you mitigate and then you resolve. You know? Becomes a powerful workflow for exactly those users who are either, you know, working on a at a plan and they're seeing some these issues come into place or their supporting plans as part of a more centralized corporate team or integrator, you know, this this ends up being useful, and and those are the people that, by the way, I'll say, also often bring us into organizations. Right? They understand the value out of being able to actually root cause an issue. Whereas, like, a less train person who's maintaining, plant for, that are just, like, gonna try and keep production working because they get... They freaked out for good reason when when production stops. Right? So... Cool. But thank you for calling that out, and I'll I'll dig into to this as well. But ideally, yeah, this is a a, ultimately, a workflow that should help, you know, professionals who are who are supporting in these environments. And so, you know, for us, when we talk about our solution, you know, our mission deliver an order bank to improve industrial scale production. And this starts with industrial devops and these set of practices that I talked about earlier. And, you know, 1 1 ways to so is, like, we wanna be able to change the scale and scope of and 1 people be to maintain more industrial automation. They wanna... We wanna support more increasingly automated environments, and increasing scale of industrial production through those increasingly automated environments. And I think, you know, that's just happening. So there's just... Is a lot more industrial automation they just aren't people to do a lot of these operator roles over time, and be are more and more an automation do to automate processes that might hire people for in an alternative universe. Or or previously. And so we think we're really supporting those people that supporting, you know, the next generation of industrial automation, the next generation of scale. Of industrial automation with these workflows. And so when we look at our platform, you know, you know, we're looking for end of end of end to end visibility and control. So this gets a little bit too someone a change in something breaks, but also being able to root cause issues. Looking at, you know, the code that's on the device validating it, multi vendor source of truth. So 1 of the big benefits our product is that it's multi vendor, making sure our cloud management is really easy and secure. There's is a big question that always comes up for us at least for Soc 2 type 2. Compliant. And then, you know, this is almost like table stakes, but is often how we get brought into conversations as rapid disaster recovery. So as well accept it. Generally speaking, they should have a disaster recovery plan. All these things enable you capture that disaster recovery benefit that is well understood as an accepted best practice and necessary sort of tooling in this space, but the industrial your devops vision gets you to, a world where you are actually preventing issues before they become production issues. And so when we look at industrial Devops really looking at producing downtime, and improving the efficiency of teams, you know, automating processes and enabling people to operate in a more streamlined way. Who's Go today? So our platform is focus on 2 things, both which we've shared in the space but matured over time, git base source control, get obviously, is a standard tool in the the It space, software space that's been around millions of people use it. You know, every day, and and to to track code changes in environment then device link, automatic automatic backup, which actually tells you, you know, if something has changed and. 1 of the big this last bullet on this list, the right is visually comparing code in 1 place or quick troubleshooting recovery. So what that looks like is give based source controls preventative, you're doing code review and practices to check your code before you put in production device link tells you if there's something in production that you weren't acting. Right? So someone makes a change. We do it back and we say, hey this change. So you're suddenly... It's preventative actually in the sense of it tells you that somebody has changed. You can catch it before it becomes a production issue. But if you don't, then it becomes a this outage happen rather than power cycling, resetting our code. Just taking the last backup up and blindly installing it or or whatever the standard mitigation practices are. Those are actually still find mitigation practices. You can then go 1 step deep as you mentioned, and, actually deep debug your your code changes. Cool. And this is a a visual of git based source control. So 1 of the big things that we bring onto the space is also this kind of multi vendor, visual environment. So you can actually visually see what change in your industrial environment. This makes it really easy to debug because you can say rather than being like, hey, we have these 2 files, the 1 on the machine and the 1 sitting on our Usb stick. You can say, hey. I can see in my browser that yesterday, there's a coaching change of these 3 runs. And wow that's actually the outage that I have. Right? It enables you to very quickly debug these issues. And device link again, as I mentioned, has monitoring into an ob aspect to it. Where you can view us running, scheduling backups, you know, and and all that stuff and and comparing, you know, what's on the plan floor with what you think is in your source control. Before you go much father, could you... Just for the audio audience, could you tell them what vendors you support now with that visual display of the differences? Yeah. I think yeah. So with that Rockwell automation, so we we go pretty broad now and pretty So we do rockwell automation. I think it might be everything since v 16 of studio 5000, but don't quote me on there. There may be some gap in the middle there. Ko, Siemens, we do t portal, I believe, from the 14 to be to the most recent version which I think is it'd be 19. And step 7. Believe that's 5.5 and 5.6. Schneider, back off, Wag, because it uses code system under the hood, Ab b, and then we actually support B r as well. So we have pretty broad and deep vendor support for the visual code changes. Within within the the space. And our goal is, you know, out of the box we're supporting, you know, probably the bulk of the the Plc vendors that you have on the plant for. Yeah. It's good us. Yeah. Yeah. It's let's take a lot of work. So I had to go deep there. But I think it's it's kinda still tables stakes exit if we wanna actually deliver the the value that we wanna deliver in the space. So... And then with device and gets worth calling out that we go even further than that, because we support a number of those vendors. We also support STSF ftp as well, which means that we can support, like, a variety of of edge devices. You know, as well. So, often what we see is, like, we support the set of Plc when we come to the site, we already have integrations for standard robots like Fan or something like that and common common, you know, devices like Cog or, you know, a kia sensor or something like that. But, you know, as as we get a little bit deeper, We'll often find that people have peripheral devices, and then it's fairly easy to build support for those. Know, as part of our overall integration step. So if we wanna support, like, Strat, a switch or something like that, you know, and be able build those sorts integrations pretty quickly given the the architecture that we have in place. Dashboards and job visual jobs. So, you know, again, this is just showing, you know, what's changing in the environment. And we actually support dashboard. So 1 of the common ways that people can use this product now that we see is actually on day 1, you wanna plug in device link. To understand what's there, and you wanna see what changes are just coming into your environment before you even think about source control. Right? And so this gives you visibility into, hey, there's all these changes happening. This is actually gets the fact that you'll actually don't have that much visibility and these changes begin with. Some of these look pretty pretty pretty gnarly potentially, how do I build, you know, better process to, prevent those those issues? So you kinda get that from day 1 with just just device link integration? And then, again, it's it's always worth calling out best in class security. There's a bunch of different things, but the big thing call is Soc 2 type 2 audits, you know, we're we're regularly audited it. You know, we we have, best in class, essentially, cloud, cloud security. We also support a self hosted version the product not on prem, but, actually in the enterprise cloud. For enterprise customers that need a more specialized deployment as well. So we can... For example, deploy display on someone else's Aws. If if they if they prefer that, And we often to do that, in in larger enterprise customers that that they wanna maintain to operate their own, own deployment in the cloud. Any any questions on on that stuff as we dig in? No. I think that was straightforward and it's good to know. And and and, you know, don't wanna... You know, some plants may so concerned about intellectual property that they do want it on premise, But I think many of the large companies will have their own their own cloud. Their own private cloud. And so it's good that you support all 3 And for the smaller customers, they can just use your cloud. They don't have to do anything. Right? So it's a good Yeah it's a good mix of options there. Yeah. We definitely see... Yeah. Absolutely. And I think that's that's that's kinda standard we see is, like, you know, more And b type customers or, you know, commercial segment of the market we'll call mid market. You tends to be okay with a public cloud offering with the right security practices in place. Especially, you know, forward thinking Cios and Sis. And then as you get to enterprise, just the scale and and scope of the deployment often drive someone to wanna kind of a little bit more operational control. And then also, you know, they have, you know, deals with with a lot of the cloud vendors, and that sort of thing as well that enables them to they they wanna use some of that spend there and, you know, make sure that they're leveraging the the kind of scale of purchasing that they make with within those vendors. So Yeah. And then I'll say, you know, just you mentioned on prem is, you know, increasingly we do see people more and more comfortable control with the cloud. So I think it's it's definitely an interesting, kinda evolution over the last 5 years since we started the company. Although certainly, there's people that really... They they just want on prem deployment. So... Cool. I mean, I think it's worth worth calling out, this is a list of customers here. You know, we work with a lot of different customers, enterprises, mid market, Smb. So we we see a large variety of customers here. And, you know, 1 of the big things is it is industrial horizontal. So we work across a bunch of different industrial verticals that be intuitive to the people on your audience, but it's often something that people ask us, you know, what vertical do you prefer to work with, And we actually see that that we can work a lot of verticals as long as, you know, we have a good technology match, and that's again, gets into some of these vendors that you know, you and, that that we just talked about on the the previous slide, 1 of the big things here is, you know, especially as you get into more scale. But, even if you look at a single, you know, plant floor, you tend to have a lot of different vendors at that plant. You might have different Cnc machines. You might have different sensors. You know, we see Fan robots with rockwell automation. Is a common pairing, you know, that happens. And so you get this kind of multi vendor environment and our goal is to drive consistency across those different vendors. So this is a set of the vendors that that we support on our website. We we have, you know, more detail on this in terms of support vendors. But the 1 other thing I'll call out is often oftentimes we're working with customers as part of our integration, especially as you get to peripheral devices to support, you know, a very bespoke or various specific device. So there's kind of a long tail of vendors in this space that we often kind of work as part of our our our deployment stuff work. You already mentioned Cog, you mentioned other companies like Cog mix that do that kind of stuff. You went kinda through a a quick list of those... All those smaller companies that we cover on the morning show. I did want for the audio audience just to mention some of your customers, including Os, including Chewy, which I know we use. My wife uses. And then, because we have dogs and then Amazon. So Some of these, you you guys... You guys may not recognize. I don't recognize them all, but those are 3 big kinda, you know, names that you may you may have heard of you know, in in outside of work. So I just figured Throw that out for those listening. Oh, I also will call up for Amazon in particular. They actually published a case study of Ko on their, because we're also partners with Aws. Mh. So there there's a published case study kind of our impact there that I I think we talked about it a little bit a later slide on this, but I can also share out afterwards if it's useful. Yeah. Yeah. I was reading that press release and that was very impressive. You know, just for the audience, what are some of the... So so if you... On the next slide, you had the big Plc guys. Right? These are the big automation houses. But, you, I'm interested in and you kinda rattled off it kinda quickly some of, like I see lens here, but you talked about Cog next, who... Could you throw some of those, other, maybe those smaller companies that you're doing maybe the the F ftp or S t with to back their configurations. You know, in addition to Cog? Yeah. Like Cog, kia, yeah. Know, phoenix on here. A lot of robots actually just use you know, S servers. So that's pretty common outside the Plc world. So most of those we end up building integrations for. So And when you're doing network switches, I mean, is that also a secured Ftp or do you typically do something else to get, like, off, you mentioned a Str switch You wanna get that configuration file? Yeah. Actually, that's a good point. Yeah. So we've seen... Yeah, we did build an integration for Strat, which someone... Somewhat recently. And so... And that was actually, I think a fairly straightforward integration. I think into this just, like, a couple hours with our existing infrastructure to build that. So that's another example, we don't have support right now, but, you know, we've looked in documentation, like an Atlas cop code as a controller that's where. Yep. You know? When those those... Some of the more modern ones use S t there. So we certainly see a fair number of of those. So... Now if that there's a little jealous, and they're not on this list, is there something they contact your facility say, hey, I think we got a customer that would like to use you, but we need you to support us, especially if it's if it's SPF ftp, that should be fairly simple. Is there somebody at year, like, do you have, like, a a corporate relations with other companies that they can contact? Yeah. So we have a, person who leads to our business development, Matt. We... He's actually So c founder. So he's... But can, you know, reach out to me directly as well over Linkedin or Matt the MATT space LEE. And just reach out and say hey, I'm interested doing integration. We'll we'll always take your conversation like that, especially, you know, if we can collaborate around AAA lead customer or something like that as well. Because Can and help make the integration mark more high quality. Yeah Absolutely. Alright. Thank you, Adam. Thank you for answering my questions. Yeah. Absolutely. Absolutely. Yeah. So Yeah. There's there's a huge blond of the of those peripheral referral devices. So it's kinda crazy what we what we end up seeing, you know, in the field and you do see stuff that's, like, hyper legacy and all that as well, which is which is always interesting. So... But we we do do a pretty deep technical diligence process on that stuff. So Cool. And then I I think this is, you know, this is the kind of result that we got from that Amazon case study, and people can fully access this on Amazon's website We're not saying anything that's not already public there, but the big data points. I there's a 8 percent reduction of unexpected downtime due to code errors. 25 percent reduction resolution time for severe code issues. So I'm kinda seeing that that kind of major major benefit on preventing production issues by just and Google kinda get code changes and catch them earlier. And then from there, you know, again, this kinda calls out the industrial horizontal, and, you know, the the different sorts of companies we work with from, you know, large entertainment company, electric vehicle company, you know, I'm all these all these different sorts of companies. That can use this product. And again, that shouldn't be probably particularly shocking for this audience given the this covid of vendors that we support, but just worth calling out that we're not actually highly vertical in that way. And some vendors do you tend to. Have solution they say works really well for for this customer another, you know, as long as we have a tech fit. We can basically support your production. So Copious vision for the future of industrial devops. So, you know, again, this is kind of this devops stack. You know, 1 thing that has come up a lot is just as we're taking the next kind of step in this stack. You know, we're going through, you know, get base source control, automate testing deployment management, conservatively monitoring. We wanna build that full stack, you know, from top to bottom and build out that entire workflow. For customers. And we've seen lots of interest in different parts of this. And so the big thing for us. And I think in general, if you're looking at this is how to engage with people who actually wanna drive process changes and organizations, and can kinda of mobilize to enact those changes. The other key piece of this is, again, this kinda, multi vendor coverage across all these different vendors. And then, you know, as we look forward to, you know, Ai enabled workflows, you know, what can you do once you actually have all the source control stored, you know, thinking about cog generation, code analysis, you know, all all these different sorts of workflows, maybe generating tests, you know, all these different... There there's a million things you can build 1 you actually have, you know, a standard set of practices, and you actually have, you know, your quote code stored. So as you start to build out the right set of practices in an organization, you actually set yourself up for some of the next generation of stuff that's coming as well. And 1 thing that we do see in the It space, and so I expect we'll eventually have an impact you know, the ot space is a lot of Ai enabled Devops tools. So basically trying to figure out how to how to build developer workflows and make them work better. And, of course, the wrinkle in the industrial space is you get a lot of sustain folks. And so figuring out, like, if your job is, you maintain a hundred and 50 devices, your foot... Your job might have bought debugging than writing code on day day basis? So how do you make that easier? And that sort of thing as well. Cool. And that's everything I have here. Do you have any questions, any other questions for for me coming on this stuff? I just wanna go back into that 1 slide the the previous slide there on the the devops stack, and this is for... And I love how you put industry x dot o because I know a lot of people are trying to push industry 5 and it's, like, are we are we done with 4 yet. But in any case, I love the Dev stack, you know, git based sauce control So there's other you... There's other ways to do soft exhaust control. Right? And I think a lot of people still using folders on service. But using git, you know, you know, and and we go into this in great detail in our first in our first podcast, you know, it's just an industry standard. Right? So you're using the industry standard, which means you can leverage you can leverage, you know, when you're training younger people, they're learning what the rest of industry is using. Right? And then automated testing. This is something I think that we don't have a lot of. And that's that's something that that's that's important. Right? And getting those reports in that dashboard of knowing when something's changed. It's like, somebody worked on Line 3 yesterday. Nobody is supposed to touch that. You know, that's a that's our money maker, why is why is there a change on line 3? And you can immediately, rep prioritize your day as the engineering manager or or maintenance manager and try to get that before you find out you made a billion dollars worth of bad products. Right? And then deployment management and ob ability and monitoring. So I can see definitely some very interesting things coming from Ko in the future the address this entire stack, but I do love how you guys are working so hard with all those Plc to do the vision... I mean, doing the upload and save. That's 1 thing. But visualizing the changes for all those different vendors, Peel Plc vendors, you know, from my world. That's what I'm thinking. You know, that's that's... That gives you... Because most plants do have more than 1 Plc. It's just the way the world works. Right? You can't have all 1 vendor. It's most homes don't have all honda or Toyota or chevy or, you know, and it's just it's just the way the way things work out. So yeah. Just looking at this slide, it really. I've... You know, kinda, to me, it's a capstone on your on your presentation, and, I would recommend, you know, anybody who hasn't who interested, read that blog... I think it was aws dot Amazon dot com forward slash blog forward slash industries. Check that book that... It's... And then you'll see the blogs up there. Check that I'm sure there's is a link I copious site as well. But it was a very interesting 80 percent reduction in downtime based on code errors. Right? So if you can eliminate all the little mistakes that being made out there when you have hundreds of appeals, then that can go right to the bottom line. But, did you wanna add anything to that Adam? No. No. I and I really appreciate that breakdown here. And I I will say, you know, we like to talk about the big vision of industrial to Devops ops. But a lot of this is, as you mentioned, sporting much of different vendors, sporting much of different workflows. Really ideally building a tool that is actually solving a real problem, you know, at the plant level. Right? When we talk about, like an 80 percent reduction. And now I'll just from code changes and you pair that with, you know, data that we've seen and corroborate just from our experience working with customers up, like, a huge inquiry. I think our number from our industrial towers supports 50 percent, a huge increase in frequency of code changes, configurations, etcetera a lot more automation in this space. You can see this is, like, a systemic problem Mh that organization's face. And when you look at best practices, like, disaster recovery, that's just a fundamental best practice. Right? Mh. So look at the kind of root of this from a, like, you need to solve disaster recovery. There are a lot more code related outages. That are happening in these environments, and they're due to changes. And there's no visibility or your ability to manage those changes. They are like, okay. Well, can you build a tool that really solves for those workflows and actually makes people's lives easier it makes it easier to maintain production. Right? And so that's really our our goal here And so we can always go really high and talk about industrial devops and get, which is amazing and automate automated testing? And how do you manage deployments ability. And we can go into Ai and I think all these gonna be insanely useful tools but it's worth calling out, but the core of it does drive that Roi of up uptime, and it does drive that increase in organization organizational efficiency and it is ultimately strategic because it changes, you know, how your engineering teams actually operate and unlock their ability to bring new production to market. And also, you know, maintain more production, you know, and and more scale and scope of of manufacturing production. So it ends up being this, like, really powerful set of practices, and it starts with a relatively tight investment of backup and source control, But then you can build this entire world out of it. They can really change how you as a controls engineer, But if you're an engineering manager, have your teams operator, if you're a director, how your your whole organization or company could operate. So it it's it's very powerful in that way. And I think for some of the more the more seasoned engineers out there, you know, the efficiency, how you're gonna be so much more efficient with a solution like this. That's the 1 thing you're not seeing in any of these reports, but that is... It's just huge. There's in a self control package is gonna just increase your efficiency, you know, you just cannot be as efficient using folders on a server and rename the file with the date you changed it and not having auto... You know, no automated backups, no automated the difference reports. So yeah. I know a lot of people are like, yeah. I've worked around this my entire career. And I have a kind of a system, but this is the... These these things, these leverage and a quest is not enough of us out there. So, like Adam don't was say earlier. Right? There's not enough operators. There's not enough controls guys. So, you know, just think of the efficiencies when you go to a package like this. And with that, I'll I'll turn it back to you, Adam for the final word. No. That... Yeah. That's great. And and, you know, just dovetail telling off that And even just the efficiency of, like, if you have a backup practice in here we're gonna and where you once a month, they're backing up all your devices. How much time are you spending doing that? You know, And, like, even with that, you get an Roi. So Absolutely Yeah. You're you're totally right. She's just, like, there's not enough controls engineers. There's a lots of production that needs to get built? Mh. And can we make the entire workforce that is building fundamental infrastructure, more efficient and we build more awesome stuff, You know, that's impactful also. You know, especially, you know, production deflation and all that stuff So let's make more stuff and make it cheaper, you know? Yeah. Make it better cheaper and faster. Yeah. Exactly. Let's do it. You know? So... Anyway, thank you so much for having me on the show. It's always really fun. I I really appreciate it. And, hopefully, we have something really lighting, you know, 12 to 18 months when we're on the show again. I appreciate that. You know, hopefully, we get to to share some cool updates in the near future. So Awesome. Yeah. We'd love to have your back. Thank you again, Adam for coming on. Yep. Thank you very much. Well, I hope you enjoyed that episode and I wanna thank Adam for coming back on show to bring us up to speed on what's new with Cob automation. And I also wanna thank Ko for sponsoring this episode, which is why it was completely ad free. Isn't that nice. If you'd like to learn more about Ko automation, please check out the links in the show notes. And if you'd like to gain access to all my content ad free, you can do so by subscribing either on Youtube or at the automation blog dot com, By clicking on that join button is just 10 dollars a month. And with that, I hope you all have a great week. I wanna wish you all good health and happiness. And until next time, my friends. Peace.