 Live from San Jose, it's theCUBE, presenting Big Data Silicon Valley, brought to you by SiliconANGLE Media and its ecosystem partners. Welcome back to theCUBE. I'm Lisa Martin with George Gilbert. We are live at our event, Big Data SV in downtown San Jose, down the street, from the Strata Data Conference. We're joined by a new guest to theCUBE, Sastri Mallotti, the CTO of Foghorn. Sastri, welcome to theCUBE. Thank you, thank you, Lisa. So Foghorn, cool name. What do you guys do? Who are you? Tell us all that good stuff. Sure, we are a startup based in Silicon Valley right here in Mountain View. We started about three years ago, three plus years ago. We provide edge computing, intelligence software for edge computing or fog computing. That's how our company name got started, is Foghorn, particularly for IoT industrial sector. All of the industrial guys, whether it's transportation, manufacturing, island gas, smart city, smart buildings, any of those different sectors, they use our software to predict failure conditions in real time, or do condition monitoring, or predictive maintenance, any of those use cases, and successfully save a lot of money. Obviously in the process, we get paid for what we do. So Sastri, GE populizes this concept of IIOT and the analytics and the high, sort of the new business outcomes you could build on it, like power by the hour instead of selling a jet engine. That's right. But there's, and actually Wikibon and David Fleur did some pioneering research on how we're going to have to do a lot of the analytics on the edge for latency and bandwidth. What's the foghorn secret sauce that others would have difficulty with on the edge analytics? Okay, that's a great question. Before I directly answer the question, if you don't mind, I'll actually even describe why that's even important to do that. So a lot of these industrial customers, if you look at it, we work with a lot of them, the amount of data that's produced from all of these different machines is terabytes to petabytes of data. It's real, and it's not just the traditional digital sensors, but the video, audio, acoustic sensors out there, the amount of data is humongous. It's not even practical to send all of that to a cloud environment and do data processing for many reasons. One is obviously the connectivity, bandwidth issues and all of that, but the two most important things are cybersecurity. None of these customers actually want to connect these highly expensive machines to the internet. That's one. The second is the lack of real time decision making. What they want to know when there is a problem, they want to know before it's too late. We want to notify them here is a problem that's occurring, so they have a chance to go fix it and optimize their asset that is in question. Now, existing solutions do not work in this constrained environment. That's why Foghorn had to invent that solution. And tell us actually just to be specific how constrained an environment you can operate in. We could run in about less than 100 to 150 megabytes of memory, single core to dual core of CPU, whether it's an ARM processor, an x86 Intel-based processor, almost literally no storage because we're a real time processing engine. Optionally, you could have some storage if you wanted to store some of the results locally there, but that's the kind of environment we're talking about. Now, when I say 100 megabytes of memory, 150 megabytes, it's like a quarter of a Raspberry Pi, and even in that environment, we have customers that run a dozens of machine learning models, if you're not talking about. Like an ensemble. Like an anomaly detection or a regression or a random forest or a clustering or a k-means, some of those. Now, if you get into more deep learning models, like image processing and neural nets and all of that, obviously need a little bit more memory, but what we have shown, we could still run one of our largest smart city buildings customer elevator company, runs in a Raspberry Pi on millions of elevators, right? A dozens of machine learning algorithms on top of that, right? So that's the kind of size we were talking about. Let me just follow up with one question on the other thing you said. Besides the, we have to do the low latency locally. You said a lot of customers don't want to connect these brown field, I guess. Operations technology machines to the internet and physically, I mean, there was physical separation for security. That's right. So it's like security. Bill Joy used to say security by obscurity here. Absolutely. It's security by like. Physical separation. Yeah, absolutely. Physical separation. Tell me about, I was actually coming from, if you don't mind saying, last week I was in Saudi Arabia, one of the island gas plants where we deployed our software. You have to go to five levels of security even to get to that. Multi-billion dollar plant and refining the gas and all of that. Completely offline. No connectivity to the internet. And we installed in their existing small box, our software, connected to their live video cameras that are actually measuring the stuff, doing the processing and detecting the specific conditions they were looking for. That's my question, which was if they want to be monitoring. So there's like one low level, really low hardware low level is the sensor feeds. But you could actually have a richer feed, which is video and audio. That's right. But is, how much of that then, are you doing the sort of inferencing locally or even retraining? And I assume that since it's not the OT device and it's something that's looking at it, you might be more able to send it back up the cloud if you needed to do retraining. That's exactly right. So the way the model works is particularly for image processing because you need, it's a more complex process to train and create a model. You could create a model offline, like in a GPU box, an FPGA box and whatnot. Import and bring the model back into this small little device that is running in the plant. And now the live video data is coming in, the model is inferencing the specific thing. Now there are two ways to update and revise the model. Incremental revision of the model, if you could do that if you want, or if you can send the results to a central location, not internet, they do have a local in this example, for example, a PiDB, an OSSF PiDB, or some other local servers out there, where you have an opportunity to gather the results from each of these different locations and then consolidate and retrain the model, pull the model back again. Okay, the one part that I didn't follow completely is, Yeah. If the model is running ultimately on the device. That's correct. And perhaps not even on a CPU, but a programmable logic controller. It could. Programmable-ized controller also typically have some notion of a CPU there as well. These days, most of the PLCs, programmable-ized controllers, have either an ARM-based processor or an X86-based processor. We can run on either one of those too. So, okay, assume you've got the model deployed down there for the local inferencing. Now, some retraining is going to go on in the cloud where you're pulling in a richer perspective from many different devices. That's correct. How does that model get back out to the device if it doesn't have the connectivity between the device and the cloud? Right, so if there is strictly no connectivity, so what happens is once the model is regenerated or retrained, they put a model in the USP stack, the low-tech, right? USP stack, bring it to the PLC device and upload the model. Oh, so this is sort of how we destroyed the Iranian centrifuges. That's exactly right. Exactly right. But, you know, some other environments, even though it's not connectivity to the cloud environment, per se, but the devices have the ability to connect to the cloud optionally. They say, look, I'm the device that's coming up. Do you have an updated model for me? Then it can pull the model. So, in some other environment, it's super strict where there's absolutely no way to connect this device. You put it in the USP stack and bring the model back here. Other environments, device can query the cloud, but not cloud cannot connect to the device. This is a very popular model these days because, in other words, imagine this. An elevator is sitting in a building. Somebody from the cloud cannot reach the elevator, but an elevator can reach the cloud when it wants to. Sort of like a jet engine. You don't want the cloud to reach the jet engine. That's exactly right. Jet engine can reach the cloud if it wants to when it wants to, but a cloud cannot reach the jet engine. That's how we can pull the model. Okay. So, Sastra, as a CTO, you meet with customers often you mentioned. You were in Saudi Arabia last week. I'd love to understand how you're leveraging, engaging with customers to really help drive the development of Falcorn in terms of being differentiated in the market. What are those kind of bi-directional, symbiotic customer relationships? Like, how are they helping Falcorn? Right, that's actually a great question. We learn a lot from customers because we started a long time ago. We did an initial version of the product as we begin to talk to the customers, particularly that's part of my job, where I go talk to many of these customers to give us feedback. Well, my problem is really that I can't even do, I can't even give you connectivity to the cloud to update the model. I can't even give you sample data. How do you do that modeling, right? And sometimes they say, you know what? We are not technical people. Help us express the problem, the outcome, give me tools that help me express that outcome. So we created a bunch of what we call OT tools, operational technology tools. How we distinguish ourselves in this process from the traditional cloud-based vendors or traditional data science and data analytics companies is that they think in terms of computer scientists, computer programmers, and expressions. We think in terms of industrial operators. What can they express? What do they know? They don't really necessarily care about. When you tell them, I've got an anomaly detection data science machine learning algorithm. They're going to look at you like, what are you talking about? I don't understand what you're talking about, right? You need to tell them, look, this machine is failing. What are the conditions in which the machine is failing? How do you express that? And then we translate that requirement, or that, into the underlying models, underlying well expressions, values, or CEP expression language. So we learned a ton from user interface, capabilities, latency issues, connectivity issues, different protocols, and number of things that we learned from the customers. So I'm curious with like some, more of the big data vendors are recognizing, you know, data in motion and data coming from devices. That's right. Some, like the Hortonworks data flow, NIFI has a mini file component written in C++, really low resource footprint. But I assume that that's really just a transport. It's almost like a collector, and that they don't, it doesn't have the analytics built in. It's exactly right. NIFI has the transport, it has the real time transport capability for sure. What it does not have is this notion of the CEP concept. How do you combine all of the streams and everything is a time series data for us, right, from the devices, whether it's coming from a device or whether it's coming from another static source out there. How do you express a pattern recognition, pattern definition across these streams? That's where our CEP comes in a picture. A lot of these seemingly similar software capabilities that people talk about don't quite exactly have either the streaming capability or the CEP capability or the real time or the low footprint. What we have is a combination of all of that. And you talked about everything's time series to you. Is there a need to have sort of a, an equivalent time series database up in some central location so that when you subset, when you determine what relevant subset of data to move up to the cloud or on-prem central location, does it need to be the same database? No, it doesn't need to be the same database. It's optional. In fact, we do ship a local time series database at the edge itself. If you have a little bit of a local storage, you can down sample, take the results and store it locally and many customers actually do that. Some others, because they have their existing environment, they have some cloud storage, whether it's AWS, Microsoft, party, it doesn't matter what they use, we have connectors from our software to send these results into their existing environments. So you had also said something interesting about your sort of tool set as being optimized for operations technology. So this is really important because back when we had the net heads and the bell heads, it was a cultural clash and they had different technologies. They sure did, yeah. Tell us more about how selling to operations, not just selling, but supporting operations technology is different from IT sort of technology and where does that boundary sort of live? Right, so typical IT environment, you start with the boss, who is the decision maker, right? You work with them and then they approve the project and you go and execute that. In an industrial, in an OT environment, it doesn't quite work like that. Even if the boss says that, well, go ahead and go do this project, if the operator on the floor doesn't understand what you're talking about, because that person is in charge of operating that machine. It doesn't quite work like that. So you need to work bottom up as well to convincing them that you are indeed actually solving their pain point. So the way we start with, rather than trying to tell them what capabilities we have as a product or what we're trying to do, the first thing we ask is, what is their pain point? What's your problem? What is the problem you're trying to solve? Some customers say, well, I've got yield, a lot of scrap. Help me reduce my scrap. Help me operate my equipment better. Help me predict these failure conditions before it's too late. That's how the problem starts. Then we start inquiring them, okay, what kind of data do you have? What kind of sensors do you have? Typically, do you have information about under what circumstances you have seen failures versus not seen failures out there? So in the process of interrogation, we begin to understand how they might actually use our software. And then we tell them, well, he is using our software to predict that. Sorry, one, 30 more seconds on that. So the other thing is that, typically in an IT environment, because I came from that to have been in this business for 30 plus years, IT, OT, and all of that, where we don't right away talk about CEP or Expressions or analytics or machine, and we don't talk about it at that. We talk about, look, you have these bunch of sensors, we have OT tools here, drag and drop your sensors, express the outcome that you're trying to look for, what is the outcome you're trying to look for, and then we drive behind the scenes what it means. Is it analytics, is it machine learning, is it something else, and what is it? So that's kind of how we approach the problem. Of course, if sometimes you do surprisingly occasionally run into very technical people, for those people, we can right away talk about, hey, if it is analytics, it is machine learning, it is an expression of all of that. That's kind of how we approach it. One thing that's becoming clearer is, I think there's widespread recognition that this data intensive and low latency work to be done near the edge. That's right. But what goes on in the cloud is actually closer to simulation and high performance compute if you want to optimize a model. It's not just train it, but to maybe have something that's prescriptive that says, here's the actionable kind of information. As more of your data is sort of video and audio, how do you turn that into something where you can sort of simulate a model that tells you sort of the optimal answer? Right. So it's actually a good question for more experience, right? There are models that require a lot of data. For example, video, audio, that. There are some other models that do not require a lot of data for training. I'll give you an example of both customer use cases that we have. There's one customer in a manufacturing domain where they've been seeing a lot of finished goods failures. There's a lot of scrap. And the problem there was, hey, predict the failures, reduce my scrap, save the money, right? Because they've been seeing a lot of failures every single day, we did not need a lot of data to train and create a model to do that. So in fact, we just needed a one-hours worth of data. We created a model, put the thing that we have reduced completely eliminated their scrap, right? There are other kinds of models, other kinds of model of the video where we can't do that at the edge. So we require, for example, some video files, or simulated audio files. Take it to an offline model, create the model, and see whether it's accurately predicting what they're based on the real-time video coming in or not. So it's a mix of really what we're seeing between those two. Okay. Yeah. Lucestry, thank you so much for stopping by the cube and sharing what it is that you guys at Foghorn are doing, what you're hearing from customers, how you're working together with them to solve some of these pretty significant challenges. Absolutely, it's been a pleasure. I hope this was helpful and, yeah. Definitely, very educational. We want to thank you for watching the cube. I'm Lisa Martin with George Gilbert. We are live at our event, Big Data SB in downtown San Jose. Come stop by forager tasting room, hang out with us, learn as much as we are about all the layers of big data, digital transformation, and the opportunities. Stick around, we will be back after a short break.