Vatsal: What you do with the data right after you collect it is much more important than just collecting the data itself, which is how do you make sure that temperature coming from Rockwell versus temperature coming from Siemens looks exactly the same? How do you normalize it? How do you prepare it? How do you contextualize it?

Voiceover: You're listening to Augmented Ops, where manufacturing meets innovation. We highlight the transformative ideas and technologies shaping the front lines of operation. Helping you stay ahead of the curve in the rapidly evolving world of industrial tech. Here's your host Natan Linder, CEO and co founder of Tulip.

The frontline operations platform. 

Natan: This week on Augmented Ops, we're joined by Vatsal Shah. He's the co founder and CEO of Litmus Automation. You've probably heard terms like MQTT and Unified Namespace tossed around a lot lately. Thank God we're hearing less Industry 4. 0 and we're getting more technical.

But Vatsal is really here to give us low level understanding of how modern edge and cloud stacks technologies work and how they impact businesses. If you're curious what led an automation engineer to abandon existing tools from the big vendors in the space, quit his job, start building his own connectivity platform, you're really in the right place.

Let's go.

So Vatsal. Welcome to the show. It's great to have you on Augmented Ops. 

Vatsal: Thank you for having me. It's good to be 

Natan: here. Yeah, this episode I think is going to be pretty exciting. On one hand, it's really great that people stopped talking about Industry 4. 0. It's been a few years that people have been talking about it.

But what people are talking about is data operations for operations. You know, or data ops for operations. I always like have to think about that a little bit when I say that. And I think the reason is because it's becoming real. And I think the people who made it real are kind of people like you, right?

They're automation engineers that had to do this and ended up founding software companies, solutions, because there was a real need. So why don't we start there? Like what, what was your journey from, you know, working for Rockwell and doing automation engineering to. Starting and leading litmus. 

Vatsal: No, for sure.

As you pointed, it's spot on that we as an engineer saw a problem statement, we were trying to resolve something in our previous jobs, working with previous customers, partners, we couldn't do it. So in my own example, I was that automation engineer, I used to design PLC leader logic and I used to design SCADA screens and HMI screens.

Natan: What did you use to design skater screens? Did the Rockwell suite? 

Vatsal: Of course, of course, Rockwell suite. But the whole idea was, um, imagine this is like four engineers sitting in a 10 by 10 room trying to hash out the details before our projects are pushed to customers. So you're working on this oil and gas project at the time where we had to integrate our systems to Emerson, Honeywell, Fisher, Rosemount and Siemens systems at the same time.

It's like for one single database. To work, there was a traceability required across multiple different systems. And it's a bunch of engineers sitting together writing code in Visual Basic. That was literally, that was the only way to do that at that time. And we wrote the logic at the end of three, three and a half months, we had first functioning product available to integrate multiple different parties to get data into MySQL database.

Of course, OPC UA servers, OPC DA servers, historians, they all existed at that time. But if you are looking for a purpose where make the operational technology data available to different IT systems or different systems that can consume it. The challenge that was there like 10 years ago, the exact same challenge exists right now.

Much more widespread because IT consumers are getting much more mature. So again, I didn't know if I was going to found the company, but all we wanted to do was just go ahead and solve this problem. And on my credit card, I purchased Rockwell Automation System at the starting of Litmus. I was like literally 3, 200 on eBay.

Bid for it, got the control logic system and try to figure out, let's create a software that talks to Rockwell and Siemens at the same time. And again, it was not about starting and working on a, on a whole software journey. It was all about solving a problem. 

Natan: But you know, this idea of having widely available, some even open source, but some non, you know, drivers to all the PLCs and, uh, you know, tools, if you think about induction or Kepware or they existed.

So what was not sufficient with that level of, you know, access to the controllers at the physical layer at the time? 

Vatsal: For that project itself, there were a few considerations that they were going to run in a standalone environment in the field. So, if you want to use those OPC systems, you will have to install like 50 of them, maintain all of them, configure all of them, and keep updating all of them at the same time.

Versus writing a code that works on a one to one integration that works forever. It was the choice that customer had and those solutions they were built for a specific purpose which is bring all this PLCs data to the SCADA systems, to the HMI systems or to SAP and other things. But they were never made for a unified approach across all of them.

So let's say I want to read data from Rockwell versus Siemens. It should behave exactly the same. Why do I have to do multiple one to point to point integrations by multiple drivers, by multiple transformation logic on the top of it? So it was not really to replace those legacy systems, it was more about what can we do more with this data that we are collecting?

Where can we make it available in a one single data format? Normalize, contextualize, which is ready to use. That was the whole idea. 

Natan: I think what's interesting for Litmus, and I think it's worthwhile, a little detour for two minutes for listeners who don't know well, but you guys actually have a pretty interesting architecture that spans the edge and the cloud.

Can you talk a little bit about what's important about it? Why have you designed the system like that and what does it allow customers to do? And if you don't mind sharing like some stories, like how, how do people actually use it in the real world? That'd be awesome. 

Vatsal: Yeah, for sure. So pretty much every feature that we designed over the last seven years, it came from real customer feedback.

So when we were looking for product market fit in early times of litmus, it was always about, if we talked to like 50 customers and 49 of them, they told, yeah, you can't do it. Like the problem statement exists, but you guys are not going to be the one to solve it. Why was that? It was more about, nobody knew what they wanted to do with the data.

Beyond the specifications of the assets itself, specifications defined by system mitigator or approaches or processes that they existed. So if you think about it, we created this product suite to solve a specific challenge on automotive customers or food and beverage customers where they wanted completely offline systems.

No calling cloud. Nothing goes out of our four walls. Start with the AirGap first product. That allows us to collect all the data and make it available to our visualization system in a much more agile way so that I don't have to pick up the phone with our system integrator every time I want to visualize one more failure points in my asset.

So agility was the one that was driving it and they wanted a complete isolation from that IT world where there were a lot more regulations and there were a lot more processes. Driven from cloud, driven from software as a service world and more. 

Natan: So you're early customers, and remind me, when did you guys start the company?

Vatsal: 2015 we started the company. And our large customers started from 2017, 2018. Where we found our product market fit and kept on building on exact same customer base. 

Natan: So you're saying the early customers around 2015, maybe even later than that, 2018, they were telling you, Hey, focus on edge. We are still in the on prem world.

That's so interesting. 

Vatsal: Again, the cloud existed, but every time we used the word cloud with them, it was like we are, we were cursing them, trying to bring data to cloud. It's far more normalized now. And I would say 90 percent of our customers as of this moment, they are bringing data out of LitmusSat system, making it available to warehouses and everything else.

Natan: You mean cloud data 

warehouses? Cloud data warehouses, cloud software as a system, 

warehouses in our world is actual, you know, there's a warehouse. It's a real 

Vatsal: thing. That's very true. Yeah. The cloud data warehouses. Now it's primary use case for Ritmos Edge as a system. But when we got started, it was all about, I want compute at the edge.

I want all data analyzed at the edge. And then when we started getting customers, they had like 10 sites, 50 sites, a hundred sites. Then, IT teams were asking, how can I manage all of it from a central point of view? Mm hmm. Introduce Litmus Edge Manager as a product that allows customers to manage all of those edge deployments, probably from cloud or probably from their own centralized data centers.

So both of these products, they drive data collection. Analytics, contextualization at the edge, all the integrations to cloud, and centrally help customers scale it up. 

Natan: And when people are doing the edge collection, setting it up, and then they push the data to the cloud, are you guys are also the cloud data warehouse in that story sometime?

No. So you're just, when you get to the cloud, you're more like the pipes. 

Vatsal: Yes, we are pretty much the pipe. We pump it into Azure infrastructure, AWS, GCP infrastructure, where customers are going to have. That long term data strategy figured out a whole lot of data to SAP, MES systems and others. We push it as well.

Natan: That's, I guess what our shared customers are doing when they push litmus data to Tulip, which is always, I find pretty cool to see our ecosystem in action. What is a cool story of someone going through that transformation from like saying, well, yeah, I'm comfortable at the edge, but I actually want cloud.

Do you have, do you have something you can share? 

Vatsal: Yeah, it's more of a journey that pretty much everybody's going to go to cloud. They can stagger it only for the time being. What happens is, um, there is an innovation project, there is a center of excellence. They want to drive something right now. What they'll do is, okay, forget about a lot of dependencies on the cloud and data warehouses.

Just do it. Let's just do it right now. Then the moment they show the CIOs and SVP of manufacturing that I achieved this, I reduced our quality issues by 2%, I reduced our energy consumption by 4%. By utilizing this, all of a sudden they say, why are you not doing it everywhere? Why are you not going on every line and every site right now?

And at that point, there is no other alternative for them. It's just like, okay, we are going to maintain it from cloud. We are going to utilize cloud infrastructure to scale it up, open the security in a way that we can control it. And have a proper scale of design. So that's just moment in time where they stick completely edge.

Natan: And I think it's great to see all the automation vendors opening up and adopting new protocols and, but still, you know, it's, it's moving fast and slow in the same time, I guess. How do you keep up with all the protocols, all the new things, like to, to make sure that, you know, somebody goes in a line suddenly, like you talk only to seven out of 10 of the assets and what do you do?

Incomplete. 

Vatsal: Uh, let's say 2018 19, we had coverage of 80 percent if we go on any plant floor across the world, right? It was 80 percent that we should be able to connect out of the box. Every year, we try to go like a few percentage more from that point onwards. Over the last six months, we have never found a customer that we could not connect to right away or at the end of 15 days.

It's more like the libraries are built out, they are robust, they are resilient, they are repeatable. It's not like there's a new protocol version dropping every week that we have to catch up to. So the initial library was the big challenge. And how do we adapt to the next product or standard or industry that we enter?

How do we tackle that might be a challenge, but coverage is pretty good. 

Natan: We'd like to have a practical sort of portion for listeners and we might include some links to this so people can see all your protocols in the library. Yeah, it's all public. What are the most popular protocols that you see customers are using right now?

Vatsal: So when we think about it, depending on automotive tier one, for example, there will be a lot of PLC and robotic system and a lot of CNC systems that we have to deal with. If we are going on a food and beverage, uh, we'll have a lot of DCS systems and PLC combinations that we have to deal with. But overall, either it will be one of those systems or OPC infrastructure that they have created already.

It's normally a mixture of both of them that we will find. And it really depends on the vertical that we work with. That's 20 percent of our product though. So, what you do with the data right after you collect it is much more important than just collecting the data itself, which is how do you make sure that temperature coming from Rockwell versus temperature coming from Siemens looks exactly the same?

How do you normalize it? How do you prepare it? How do you contextualize it? The context which is available locally, which shift it is? Which recipe it is, which asset it is running on, which line was it running on? So a whole lot of variables, they are lost in time. So once the moment has passed, you don't have that variable available that easily.

So how do you make sure that all the data that we are collecting, they're contextualized properly? Mm-Hmm, . Then how can you allow customers to analyze that data or derive the KPIs right then and there out of the box? Low code, low code way. And then how do you make sure without losing all of this context, make it available to smarter systems like Tulip or data warehouses on the other side or anywhere else.

So the whole journey has to be robust, resilient, repeatable. All of those pieces are required as soon as you collect the data. It's table stakes. 

Natan: Exactly. So let's dive even deeper. I think one of the things that's been on everyone's mind recently is this sort of term around either been kicking around around the unified namespace architecture.

A lot of vendors are starting using that term and definitely customers are asking for it and they're contextualizing it vis a vis ISO 95 model and. With point to point connection and, you know, lots of, I'd say regionally the object oriented type definitions versus event driven pub sub type of thing. So what is your tech technically?

And if you can also talk about like, what does it actually mean to the customers, like from value? I mean, okay, we got the general gist, but like, what does it actually do for me from your perspective? Yeah, 

Vatsal: I think a lot of our customers, they have been asking exactly the same question. So, Litmus as of right now, we are deployed on thousands of sites across the world.

And when we ask our customer, what does this UNS mean to you? And they will say, oh, that doesn't work for me. Or some of them, they will say, this is the exact solution to the problem statement that we have. So depending on the industry that we are working with, they answer it differently. 

Natan: Can you give me an example what type of customer says that doesn't work for me?

Vatsal: Security sensitive customers, they don't want to create an architecture that is distributing data beyond the domain of that data itself. So, uh, when we go into some of the midstream projects, when we go into some of the biopharma customers, biodiesel customers, they said, it's not like it doesn't help them, but it's like the technology is not there yet to solve the challenges that we have.

We want to make video data available on it. We want to have more context information available on it. We want to have more maintenance layer created on the, on the top of it. So, it doesn't work for us as of this moment. But then there are customers which are on a discrete or on a hybrid world. They will say, I have like six OEM systems on my plant floor.

All of them, they are going to talk MQTT today or tomorrow, or I have Litmus Edge already available here. So how do I create this namespace? And they are all over it. They are trying to jump on that solution itself. So it's again, a mixture of both of them. But UNS sentiment as a whole is growing amazingly in the right direction.

And we introduced the product Litmus UNS broker just six weeks ago, and we already have a few hundred customers working toward it. Tell 

Natan: us more about this new product. What does the Litmus UNS broker do specifically? 

Vatsal: So before I jump into product itself, because I don't want to make it like a product specific, but let's let me answer it in a way like what would be the real value out of this URL.

I think it's a common ground. Ooty has a mess. IT needs data right now. There has to be a common ground between both of them. That common ground has to come from a protocol which is more efficient like MQTT or the language that everybody talks about is GraphQL and Graph databases itself. So it's more like a bridge that OT and IT, both of them, they can agree on and OT decides what type of data is going to get pushed, how it is going to get organized.

IT decides how it's going to get consumed, how it is going to be secure, and how it is going to have proper context that all of the smart applications require. And it's a very good common ground as of this moment. It has its own limitations, but because of the protocol it uses, like MQTT protocol has certain limitations that it needs to go beyond to be real enterprise wide unified namespace.

But still, it is a good common ground. So based on what we know from our customers itself, so over the last six years, we were always distributing data from point to point. So Litmus was pushing data into SAP, Litmus was pushing data into Tulip, Litmus was pushing data into Azure, but now there's a bridge in between.

Litmus Edge pushes data into this bridge and all the applications who wants to consume it, they can consume it. So this bridge became a point of interaction between OT and IT system in a domain isolated way. And I think it's, it's a step in a very good direction if it's done correctly. 

Natan: So do you think IT people now starting to embrace MQTT?

Vatsal: I have my own personal opinions that 

Natan: Yeah, I want your personal opinion. That's exactly what we want to know. 

Vatsal: Okay, let's start from the positive side. Yes, MQTT came along a long way, right? But there's a long way to go from on the top of it. If you think on asynchronous systems that exist in a cloud native environment like Kafka or Pulsar or Red Panda, they are built with a resilience at their core.

They are built with a wide array of applications that they can enable right at the core. Publish, subscribe, queuing mechanism, message throttling. Every application that you require for enterprise service burst is there. Now we are trying to replicate a lot of those things and try to bring into MQTT world.

And try to retrofit the things that we need to make MQTT enterprise scale. So, there are going to be challenges on that. The second thing that I would say, industrial world believes in robustness and resiliency a lot. That means you create something that has to work forever. So when we introduce new communication mechanisms on the top of MQTT, like Spark Plug B, like OPC UA over MQTT, or other things which are popping up.

They do not give comfort that it's a future proof infrastructure yet. 

Natan: What's really your take on Sparkplug B? What do you think are the drawbacks and what are the great things about SparkLog and where's it going? 

Vatsal: So Sparkplug B was a good step in the right direction. MQTT was more like data agnostic at the transport layer.

So whatever you can pump into that consuming applications, they can get it. But Sparkplug B created a structure. The scope is still a bit narrow. That means, sure, if you have a edge device, if you have a SCADA system and if you want to make data available somewhere else, it'll definitely organize that data in a Spark plug B format.

But the moment you go for more analyzed data, derived data, contextualized data metadata, then you have to think a little bit beyond Spark Plug B, because it is not in the scope of the specifications as of this moment. Mm-Hmm. Unified namespace as a whole. It goes far beyond what Sparkplug B can provide because it focuses on a broader integration that is possible between OT and IT.

Natan: So how do we bridge the gaps? Because in a way, don't you think like that internet based protocols, you know, they became pretty proprietary, pretty good, of course, very HTTP centric, but we're seeing. Other protocols on the internet that, you know, they're more application specific, like to do video transport or to do, you know, all sorts of things, but really it's all browser centric and web socket centric.

And where do you think this is going? Like this convergence? 

Vatsal: If you focus on like real customer use case, all they care about is. Make this operational technology data available to me so I can have a better workflow. I can have a better process. I can have a better understanding of my operations itself.

What technology you use in the middle of it, it doesn't add a whole lot of value just yet until you hit the point of repeatability that you want to keep on doing it across multiple sites. The technology has to grow beyond what it is built for right now and we are yet to see. How it will evolve. Just MQTT as a whole or Spark Plug B as a whole, it has to evolve over time.

So at a higher level, yeah, internet based protocols, they are good. But the bridge that is created right now that did not exist before or it existed with OPC UA and others, but it was just too complicated to deal with. 

Natan: So sometimes in Augmented Ops, we like to end the episode with, uh, just instead of me asking all the questions, you lead us with like a couple of questions to end this episode.

So what do you want to know? Sure. 

Vatsal: So why do people keep on putting you in MES category? Tulip is far beyond MES.

Natan: I know. I don't know that I have a great answer to that. I think people change their minds slowly and perceptions slowly as to how they call different products or technologies. I asked some analysts at some point when they started covering the company.

Why are you doing this? Like, don't, don't call this an MES. It's, it's different. And they're like, Natan, you don't understand. It's not about what you think. It's about what your customers are telling you that they're building with your platform. So some customer build some sort of a warehouse solution.

They don't necessarily cost WMS or some customer would build, uh, you know, workflow for RMAs and, um, They have a lot of paper processing, so they don't really call it RPAs for operations. And, and then, yeah, some people build work instructions and workflow and data collection and all that kind of stuff.

And, and they don't call it MES. And then Gartner comes along and they call it composable MES. So the reality of like classic legacy MES is unacceptable. And what value provide the customers, and I don't think. People should be okay with just having a manufacturing execution system. The organization really need new production systems.

And to get it right, you need a lot more than an MES. Yeah. You might need a data platform like Litmus and a frontline operation platform like Tulip. And you might need like BI tool XYZ and cloud data warehouse ABC. And that's sort of where really the next generation of production system lives. It lives in the ecosystem.

Vatsal: Yeah. You're a hundred percent right. And, and I think in earlier times, we had to justify it. What was industrial edge computing, uh, like, why do you guys exist? And as an interpreter, I was always trying to avoid creating a new category, right? So how to fit in the category that, that existed. So it's easy to reach out to the person who is actually buying it.

How difficult was it for you to define as, as a frontline worker platform? So that's a new category. 

Natan: Yeah, there is this conundrum, a lot of companies, certainly in the B2B enterprise space, everybody wants to, I want to create a new category, but the reality, the reality is customers create the category, not you.

We just gave this thing a name because we had to be very clear about why is this product good. And who is it targeted at? And it wasn't anything that was there before and some of the stuff that people started calling the work we were doing was like too limiting. Not to mention MES obvious legacy, but I'm talking about all sorts of weird names.

And honestly, they're confusing, like, uh, connected, uh, worker. Okay, but what does it actually mean connected? Is there an unconnected worker in 2023? Like I don't, I don't know. I don't think we're done. And I think what's more important is like to continue working on large scale ecosystem with, you know, an open stack.

And we had this conversation many times and like, Hey, there's a new stack for operations. And I think the companies like ours and several others have a place to play and together it just creates more, more value to the customer. And that's where it's all about. 

Vatsal: A hundred percent. And I think in manufacturing or industrial world, incumbents are so strong, creating a new category.

Kudos to you. My thought process was always like, don't create a category until you absolutely have to, and executing on it is just difficult. You guys did it, did a fantastic job at it. 

Natan: Thank you. I don't, I don't think we're doing it alone and we'll have to do this again because unfortunately we are out of time.

I want to thank you so much for joining. It's been awesome. I hope to see you again and we'll keep following, you know, the industrial age, the industrial cloud. And we'll put some links on some of the architectures and the library of connectors that Litmus has. And of course, if people want to check out the Litmus and Tulip.

Integration. We're going to include the link to the Tulip library. And on behalf of both of us, we'd be happy to talk to anybody who is curious about the architecture, UNS, whatever. Give us comments on this episode and others, or if you're curious how to implement it, let us know. Thanks a lot. 

Vatsal: Thanks a lot, Natan.

Thank you for having me. 

Voiceover: Thank you for listening to this episode of the Augmented Ops Podcast from Tulip Interfaces. We hope you found this week's episode informative and inspiring. You can find the show on LinkedIn and YouTube. Or at tulip. co slash podcast. If you enjoyed this episode, please leave us a rating or review on iTunes or wherever you listen to your podcasts until next time.