Transcript.

Welcome to the Industrial IoT Spotlight, your number one spot for insight from industrial IoT thought leaders who are transforming businesses today with your host, Erik Walenza.

Erik: Drew is the founder and CEO of Alluvium. He's also a very active guy that's involved in a number of other companies. We'll focus first on going a bit into Drew's background, some of the other projects he's involved in and then have a deeper look at Alluvium from the business perspective.

For the second part of the podcast, we will be diving more into the technology, both Alluvium technology but also technology more generally, so looking at how they differentiate from other companies in the market. And then we'll end in the third part with some deep dives into specific case studies. Drew, thanks so much for taking the time to talk with us today.

Drew: Erik, it's great to be here. Thanks for having me.

Erik: I love how focused your value proposition is. I think you state it very clearly if you can get 10 minutes of somebody's time on the screen, you have to make that time count. And then your job is to make sure that's 10 minute is well spent. Let's transition to the second part of the podcast and look at how you make sure that those 10 minutes are well spent, that you're presenting the right information in the right context. And we can go a little bit technical here. Maybe we can start a little bit higher level. What are the products? I think you have two products, am I right in the market right now?

Drew: Right. So we have underlying technology, and then our first flagship product that we built on it. So I'll talk a little about the technology first and then our product. So when I started the company, I was really focused on figuring out where within, say the chain of operation for industrial company is the best place to insert a piece of software that's fundamentally designed to take in these heterogeneous streams of data, distill them down into this idea of a stability score, this index of operation and produce these high value alerts.

And so if you think about these different sets of constituents or different layers in an organization, the core layer is that operational technology side, or what is often referred to as the edge of the operation. That's inside the facility right next to where those data and those bits are being produced.

With those same bits end up flying out to a secondary layer, which we think of as the control room. So they're not the folks are actually walking around the plant floor, but again, is those managers, so those people who are not having to do the minute-to-minute, hour-to-hour analysis, but maybe doing the day-to-day, week-to-week analysis. And so it's the same data, but they have a slightly different context for how they're using it.

The exterior layer of that is at the corporate level or the headquarters level. And so these are the folks who are not at all on the operations side, but are looking at lots and lots of data potentially across many different production facilities and having, again, different contexts and different set of questions. And so with that general map in our heads, what I want to do, as I said, well, the place that we think we can have the most immediate impact is if we go right to the source of that data and go right into the facility and start building our operation.

So the first piece of technology that we built was how do if we want to do distributed real time, unsupervised learning from these assets, how would we actually tie all that together so that we could build this top level view? And so we began to build what is now core library core technology which we call Floodplain. And Floodplain, without going too deep into what the technology is, is really just a way of doing generalized unsupervised learning from the streams and actually distributing that software across multiple nodes of compute within any given scenario.

And so the idea is if you wanted to stick a piece of software out on a wind turbine sitting in the Midwest, you could use floodplain to put that on any one of those wind turbines and it would learn a stability score for that one wind turbine and then that could be transmitted up and we can have an entire stability of all the wind turbines at once. Or likewise, for a single asset inside a manufacturing facility, we can do it for all the assets and build this top down view.

And in the early days of the company, we had some really interesting opportunities to try this. Probably the one that we talked about the most was actually one that we ultimately did not decide to pursue for commercial product was we were working with the New Orleans Police Department and using our floodplain technology to build a stability score of police vehicles; the MDT is called the Mobile Dispatch Terminals, they’re little laptops that police officers have in their cars. We could install software on there and actually stream data off of the onboard diagnostic sensor in a car, which as I'm sure you know, modern vehicles are really just like big computers with wheels on them. So it produce a tremendous amount of data any given car.

But we could stream that data in and build an internal stability score for a vehicle and then actually aggregate that up and build it for an entire unit or for an entire department if we wanted to. And we learned a lot from that. Ultimately, we decided that we didn't want to pursue the kind of vehicle as a business proposition. But as we turned our attention with this technology to the industrial space, we found two things to be true. One was that folks in the manufacturing world were really interested, and I'd say certainly aspired to be able to do real time learning from the streams of data that were coming off of their platforms.

Unfortunately, the other thing that we learned is that the barriers to entry to that industry, so just from a technical perspective, actually deploying software inside of a manufacturing facility is quite challenging, and very challenging, in fact, if you're an early stage startup without a deep track record, and without a systems integrator walking in the door. So we found it quite challenging to actually get even in early pilot started where we were building even a custom tool on top of our floodplain technology for the customers that we wanted to work with.

But one of the things that we learned from our customers through this process is that they were actually still really interested in using the technology, but using it not in a real time way, but in what we came to call a Just-in-time way. So rather than having a stream of data off platform, if they could just periodically put yesterday's data or last month's data into a tool that uses technology to generate stability scores, then they could leverage that to either do their investigation or do the resource allocation.

And so we ended up hearing this enough from the folks that we were working with at the time, that basically early part of 2017, I said, you know what, I don't want to build these kind of proof of concepts forever. I think this is a product that we can just go ahead and build. And so that idea ultimately became Alluvium primer, which is our flagship product built on top of our floodplain technology and design not for the real time use case, but for that just in time use case where customers can put data in, either individual datasets where they're doing forensic analysis, or daily datasets from the same facility all captured for long period analysis and get that stability analysis and leverage it to be able to do this discovery and reasoning about data.

Erik: So what is the architecture? I guess that you're not taking stuff off the PLCs? Are you getting it from the MES or the ERP or is it more of a manual upload?

Drew: The answer is sort of yes. Right now, Primer is a cloud-hosted SaaS product. So data goes into it, drag and drop from, however, a customer is able to export that data. Typically, a customer's either working off of a traditional historian platform; there's many different vendors for those. Or perhaps they have more of a more contemporary data lake infrastructure where they're collecting data in a large cloud infrastructure, and then exporting that data into Primer. We will have a more integrated version of Primer coming out later in the year.

But as it exists today, customers can drop in any dataset that they have from their production systems, that data will get analyzed by Primer, and then it sort of operates as a top level analytical tool where customers can then explore that data within the tool.

Erik: So one of the big issues that is facing in manufacturing, and also a lot of other sectors is the fact that there's proliferation of protocols and systems from different vendors may tag data with different metadata. Is there some customized work for you to go in when you deploy one of these and to say, we're using this set of equipment and this data means this, it comes from the system and so forth and to train the system of it? Or is it really able just to take in any data source without any education behind it and make some sense out of these different disparate data sources and how they're interacting with each other?

Drew: So again, in the early part of our development, one of the things that I really was keen to focus on was not requiring our customers to have a big upfront cost in terms of the training of a particular model. Traditional way you think about doing machine learning is in this supervised context. So, okay, I'm a manufacturer, and may be I'm a particularly sophisticated one. And so I've already made a big investment in technology and I've stored a bunch of historical data, and I can actually point to different examples of how particular assets fail and then I can hand that over to a vendor, and a vendor can build a model based on that. And then I can put that model into practice and then hope that now I'm able to prevent these types of failures in the future because I have some ability of identifying them.

And there's absolutely nothing wrong with that approach. In fact, it's a typical way that you would even think about solving this. But we were really focused on having a different way of thinking about it because we felt there were two problems with that. One sort of obvious statistical problem is that in practice, industrial operators are actually quite good at preventing catastrophic failures of their assets. They've been doing this a really long time. They understand even if it's just a general heuristic, or set of decision trees and best practices, if an asset starts to look like this, then we probably need to service it. And they also have regular inspection and so they're predicting a lot of these things.

When things do go sideways, it's typically uncommon or rare events. And so just from a basic statistical mindset, you would not want to build a model off of examples of failures that are themselves rare. We would call this kind of selecting on the dependent variable, which thing we wouldn't want to do. We wouldn't want to build a model of rare events and then put that in practice, and only be able to detect things that don't happen very often, but actually be completely blind to a new scenario that we've never seen before, which is how these things typically go and then that model not be a success.

The other thing that we wanted to not have to worry about is only working with customers who had gone through the exercise of collecting data and storing it. Again, most of the customers in the industrial space are quite technically sophisticated, but may only be at the beginning of their digital transformation journey. And so maybe they haven't already put a bunch of resources into collecting this data.

So when we built floodplain, we said we want to build a system that can do this analysis from heterogeneous streams in an unsupervised way. We allow the system to learn from the data on its own. And we have put a tremendous amount of effort into building an underlying algorithmic approach that is both general but learns quickly. But as we say to our customers, our system starts learning from them on day one. It comes in as with a really powerful set of tools to understand data. But without that human operator interaction, it never gets any smarter.

So we want to move our system and move the paradigm of how our system works from a fully unsupervised approach on the first data set that goes in. But with every subsequent data set, and with every subsequent interaction, the user is actually learning from that and moving to a semi-supervised approach. We want every interaction, as I said before, to be that high value for the customer, but also be super high value for the system.

And so to go slightly more technical, we don't necessarily talk to our customers about this because the context might not be there. But if you're an industrial engineer using Primer, you are effectively a data engineer too. And what I mean by that is with every interaction in the system, you're actually helping the underlying algorithms do their feature selection and do hyper parameterization of the models.

Because every time you evaluate an alert and provide feedback, the system looks at that and says, okay, slightly, this unbounded search space of potential future interactions and neural nets gets a little smaller because I know a little bit more about what's important and what may be not important to this particular use case. And we learn more about that.

Again, so, it's not that there's some magic under the hood that says, oh, we can learn from any particular use case, and you can just give us data and this machine will automatically generate these magic findings. No, what it does is it takes that data, given the approach that we have, it distills that into that stability score and generates alerts. And when those alerts are high value, the operator takes the appropriate action and the system learns from that. But when those alerts are not high value, either false positives or there may be some context missing for the algorithm that the operator has, it won't make that mistake again. And so we get this kind of positive feedback through that iteration.

Erik: It's very clear that your primary customers here are the operators. But what about the OEMs? My brother just wrapped up his PhD, he's working for Intel now and he's one of those guys that's in a lab managing a $10 million machine. And it's like running a little bit of magic: the machine's not working now, why is it not working? Nobody knows. And obviously, Intel, they're collecting data on this. They have a huge stake in maintaining uptime and utilization for these machines.

But then the machine manufacturer also has a stake in understanding how our machines actually operating, why are they breaking down and so forth? So they would also be very interested in this data and understanding in what cases their equipment is suboptimal and how they can improve in product development or in manufacturing. Are you working at all or do you see interest? I know, this is obviously, moving data between the operator and the OEM, this is a long term business challenge, not really a technical challenge. But have you come across this, either requests for OEMs or situations where the data might actually be more valuable for the manufacturer as opposed to the operator?

Drew: Absolutely. And the OEMs in this space they have both a tremendous amount of leverage as well as what we think is a lot of incentive to work with companies like us and folks who are building specific applications for their data. The OEMs, they're the ones building the multimillion dollar pieces of equipment, and they're out there trying to sell these more sophisticated assets that have more instrumentation on them, are generating more data.

And from the customer perspective, so now you're buying that multimillion dollar asset, you say to yourself, well, okay, it's this much more sophisticated, it generates all this data, but what am I going to do with that? And you as the OEM, how are you going to help me understand that data because I'm a manufacturer, I'm a refiner, this is not my core competency, what do I do? And so what we have seen is there are different kinds of OEMs, who I think are taking a different approach here. But all of them are sticking out real estate within the industry to say, we want to be doing analytics, building software platforms, and cloud platforms for our customers to be able to leverage this data.

I'd say on maybe the most high profile example of this is GE Digital with their Predix platform. GE, I think has taken a really vertically integrated approach to say if you buy a turbine from GE, they can take you from deployment of that asset to data generation to an entire ecosystem of applications and tools that they can provide to the customer as an add-on to the purchase of that equipment. I think part of it is both how the technology has progressed and how software has become much more of a central part of these OEMs business.

But also, as an evolution of their business model, these high CapEx businesses, if you're selling a multimillion dollar piece of equipment, you're probably only selling one or two of those to a customer every few years. And that's been a great business for those companies for a while. But having the kind of recurring revenue model that you get from a software services agreement is also a lot more attractive. It costs a lot less to do. And if you already have significant structural advantage in terms of how your customers interact with you, well, that seems like a really smart thing to do. And GE is a good example of this.

But Siemens has their own, I think it's called Mindsphere. That's their cloud analytics platform. Honeywell, likewise has their Sentience platform. Hitachi, all these companies have these big cloud platforms. And so for us as a startup, certainly, for the foreseeable future, there will always be a tremendous amount of asymmetry between us in any one of these large multinational OEMs. The advantage that we have is that we're not locked into a particular asset line or OEM specification.

So, for customer that says, listen, we have a mixed fleet maybe we have a GE turbine and Honeywell process control, and we're also working with some Siemen’s SIs, we can come in and say, listen, all that data is perfectly compatible with our system and in fact, it's really our system is designed to be able to take in all these different inputs and give you a top level view of how all these things are operating together.

And so we've begun to have conversations with some of these OEMs. I think there's lots of opportunity for us to work with them and provide whether it's Alluvium primer or a different application to exist inside their ecosystem. But it's still early days. And quite frankly, I think a lot of these large OEMs are still trying to figure out what approach works best for them. Is it the kind of fully vertically integrated approach that GE has taken or perhaps more of a community based one where an OEM will say, listen, we can build a cloud infrastructure and we can get all the data to a central place. But we're not software designers and developers. We don't have that as a core competency. So let's go out and try to partner with companies like Alluvium or other ones. And so, obviously, we've been more attracted to companies that are taking that latter approach.

Erik: I think even GE after sinking X billion dollars into Predix are now looking more carefully at this community driven approach and maybe deciding that they do need to be a bit more open. But as a potential solution partner, are you working with these guys? Would you see GE as potential deployment partner? Or do you consider them at least in the status quo today to be more of a competitor?

Drew: Well, to answer the first question, we don't work directly with GE, although we meet personally and we as an organization have a great relationship with GE Digital actually was, last fall, I had the opportunity to keynote at industrial machine learning workshop that GE hosted out in San Francisco, and I know the team there, and they do some fantastic work and we haven't found the right project to work on together yet.

And not just GE, as I mentioned, the other OEMs out there, we’re building relationships with them. These organizations are large and you have to be able to navigate them. But me personally, I don't see them as competitors at all. I mean, in some sense, it's almost foolish to think of them as competitors, just given the asymmetry there. If these organizations, you don't really need to compete with a company like ours because we don't do the same thing at all.

We operate in the same marketplace and we have sort of spiritual alignment in terms of how we want to serve our customers. But Alluvium is never going to build a turbine, will never ever be able to do that in the same way that I don't expect large OEMs to be able to think about building deeply technical deep learning models and real time software infrastructure in the way that I can and the team that we have in Alluvium was thought about doing.

So in some sense, it's much more of a natural complementary relationship. Not every company out there approaches it that way. But my perspective is for those OEMs, that are in the marketplace thinking about working with companies that complement their approach, that makes total sense to me. And I actually think that's true across the board even outside of the OEMs because you have other systems integrators and infrastructure providers who themselves are not particularly well suited to build applications, and may be looking for companies like ours to come in and provide specific solutions to specific problems that their customers already have.

Erik: Thanks for tuning in to another edition of the industrial IoT spotlight. Don't forget to follow us on Twitter at IotoneHQ, and to check out our database of case studies on IoTONE.com. If you have unique insight or a project deployment story to share, we'd love to feature you on a future edition. Write us at erik.walenza@IoTone.com.