What can physics teach us about machine health in manufacturing? Joining us today to unpack this question is Mica Rubinson, a physicist with a PhD from the Weizmann Institute of Science. She currently serves as the algorithms lead for Augury, a company providing AI-driven insights into machines, processes, and operations in manufacturing. We sit down to discuss her transition from physics and neuroscience to working in AI, and how her background has informed her understanding of complex systems and improving machine health algorithms
Mica shares the methods behind Augury’s fault testing processes, why they use the highest quality data available, how in-house experts help them filter their data reliably, and their approach to communicating with customers. Our conversation also explores the balance between edge computing and cloud computing, and why both are necessary for optimal performance and monitoring.
Key Points From This Episode:
Quotes:
“We look for better ways to adjust our algorithms and also develop new ones for all kinds of faults that could happen in the machines catching events that are trickier to catch, and for that we need highest quality data.” — Mica Rubinson [0:08:20]
“At Aubrey, we have internal vibration analysts that are experts in their field. They go through very rigorous training process. There are international standards to how you do vibration analysis, and we have them in-house.” — Mica Rubinson [0:09:07]
“[It’s] really helpful for us to have [these] in-house experts. We have massive amounts of records – signal recordings from 10 years of machine monitoring. Thanks to these experts [in] labeling, we can filter out a lot of noisy parts of this data.” — Mica Rubinson [0:10:32]
“We quantify [our services] for the customer as their ROI [and] how much they saved by using Augury. You had this [issue, and] we avoided this downtime. [We show] how much does it translates eventually [into] money that you saved.” — Mica Rubinson [0:22:28]
Links Mentioned in Today’s Episode:
Augury
Weizmann Institute of Science
Mica Rubinson: Things that are going on in the edge are not written by the same people that are coding in the cloud. We need to be able to explain to those people that are working on that aspect what they're doing, how to monitor themselves, how to know that they're not introducing bugs, how to check that the output is correct. So that's also something to consider.
Rob Stevenson: A world of hurt awaits you when you move from the cloud to the, edge is what I'm thinkly. Welcome to How AI Happens, a podcast where experts explain their work at the cutting edge of artificial intelligence. You'll hear from AI researchers, data scientists and machine learning engineers as they get technical about the most exciting developments in their field and the challenges they're facing along the way. I'm your host, Rob Stevenson, and we're about to learn how AI Happens. Okay, here we are back here again with another installment of How AI Happens. I'm your host Rob Stevenson, and I am geared up for another really awesome conversation with a fantastically technical guest here at the end of the year. We are winding down 2024. I am so pleased because my guest today had so many opportunities to say happy to push this one to the new year if you'd prefer, Rob, but she didn't do that. By the time you hear this, it'll be the new year, but we're recording it in the past in 2024. And anyway, I'm just rattling about nothing here at the top of the show, but it's because I'm, excited about the episode. My guest today has had a ton of amazing roles in research. Primarily she earned her PhD from the Wiseman Institute of Science in Hammerkaw, Israel. She where her dissertation focused on the predictive analysis of neurological disorders. She held a bunch of research positions and currently she serves as the algorithms team lead for Augury. Mica Rubinson, welcome to the show. How are you today?
Mica Rubinson: Thank you so much. I'm m good. How are you?
Rob Stevenson: I am really great. Are you sensing this excitement for me, that I'm just speaking around in circles here at the top of the show?
Mica Rubinson: I can and I'm excited too.
Rob Stevenson: Great. Yeah. So Augury, just quickly is, some context for the folks out there provides AI for predictive and prescriptive machine health and you have an interesting background. It's I guess not that uncommon in the space. I'm learning more and more to have this sort of physics research background and, and then to parlay it into an in house more what I would consider, you know, more of like a Corporate traditional career. I was hoping you could share for you after you accomplished all that amazing research and doing all this great work in science and physics, why you wanted to move into a role like this.
Mica Rubinson: After I earned my bachelor degree, I went to do a PhD in physics at ah, the Weizman Institute, like I said. And I was in the department of complex systems. And I was fascinated by one of the most complex systems there are, which is the human brain. And again I went for what I was interested in. So I kind of dived into neuroscience a little bit. And my research focused on using egle, which is a cap, if you know, with sensors on it that can record brain activity. And I used it in experiments of ADHD and schizophrenia patients that performed cognitive tasks. And I looked at the brain as a network and I analyzed how this network behaves during the different experimental conditions. And it sounds unrelated to what I do today at Augury, but I think there is sound connection because if you think about it, you, you can look at the brain and the signals of the brain kind of similar to the machines that we monitor with vibration and magnetic signals. And we're trying to understand what's inside there, what's inside that box that we can really open and look into. So in that sense I kind of see a connection, although it's kind of random. The way I ended up at Aug eventually and after I finished my studies I joined Augury as a research scientist. I was working to expand the company's products to new machines and new industries. And even though I wasn't a mechanical engineer and I didn't know hell of a lot on industrial machines and how exactly they work, I think this background helped me to be able to learn. After doing independent research, I could pick up on the important things and could understand how magnetic fields in motors behave and how we can use ultrasonic sensors signals to find electrical faults in motors. So it all kind of fell into place in that sense. And I think my background also helped me to communicate with different departments at Augury because we have a physical device that user sensors and I could, as part of my role I had to communicate with departments like the hardware departments and firmware and IoT. And this background I think helped me to be able to understand them and be more efficient in working with them. And later I got the opportunity to become a team lead. That was around the growth period right after the COVID 19. We had hyper growth in the company. So I got this opportunity and I started leading one of Augury's algorithm groups, again responsible for expanding the company's coverage. And that's my current role today. There was another question about, AI experts. Why they tend to go there. But I'll wait for you to ask that.
Rob Stevenson: Yeah, yeah, sure, yeah. You know, I've met a lot of physicists doing this podcast, and I didn't expect that, but maybe that's just my own naivete speaking. Why do you think that is? Is it just because math is math and the compensation is better in AI, or why are so many physicists drawn to the space?
Mica Rubinson: I think it's part of that. I think a lot of physicists end up in this field partly because, yeah, there aren't. If you compare the amount of traditional jobs in physics, like in hardcore physics, compared to the number of jobs you have for data science and AI, I think they are less so for, hardcore physics. And I also think that many physicists kind of like me go down that road. Not necessarily because they have a clear career path in mind. They, you know, they like physics because it's interesting, and then they like AI because it's also interesting. So they kind of like raw into that.
Rob Stevenson: I think the curiosity of a scientist continues into the space.
Mica Rubinson: Yeah, yeah, yeah. I think, that's part of the reason. Yeah.
Rob Stevenson: I want to hear more about your current role too, Mica So you are the algorithms team lead, and so I was hoping you could just share more about your current remit and what you're working on and. Yeah. What's kind of keeping you up at night from an algorithmic point of view?
Mica Rubinson: So many things. We look for better ways to adjust our algorithms and also, develop new ones for, all kinds of faults that could happen in the machines, catching events that are trickier to catch. And for that we need highest quality data. So that's part of what's keeping me up at night. Yeah.
Rob Stevenson: In your industry, it seems to me that it wouldn't just be enough to have really clean, high quality data, but there's this domain expertise probably that is necessary. So is that something that you are able to provide yourself when you are trying to, you know, I don't know, annotate data or label data or are you bringing in experts? How does that process managed?
Mica Rubinson: So at Augury, we have internal vibration analysts that are experts in their field. They go through very rigorous training process. There are international standards to how you do vibration analysis. And we have them in house and they get all the detections, all the alerts that our algorithms generate and they either approve or disapprove these detections. And we do that before they reach the customer. So this helps us also to improve the quality of what's eventually getting to the customer, improve the precision of our algorithms. But also we use that in order to make our data sets of higher quality. We can use that to basically label the data kind of like. And it's different from another field where you could use, you know, common knowledge, like you have a picture and you need to say it's a dog or a cat. So you could probably use crowdsourcing for that. But here it's more like when you use a doctor's opinion on a, CT scan. So you need that expertise to be able to say if this vibration signal has a fault signature in it. So that's really helpful for us to have that in house. Experts and you know, we have massive amounts of records of signal recordings from 10 years of machine monitoring. So thanks to these experts labeling, we can filter out a lot of noisy parts of this data. And actually, interestingly, we also recently added also a layer, that uses generative AI know that's like the hype these days. So we're looking for ways to use that. And one of them is to also improve our labels. So you could, for example, if you had a detection and let's say the analyst approved it and eventually reached the customer, and the customer either took it and saw it, there was a problem in the machine and then repaired it. So you can later on look, for example on the conversation between the customer and the analysts and understand from that if the detection was good or not, if a repair was made or not. So you can use that and you can build on that to even further improve your labeling process. So that's another thing we recently started doing.
Rob Stevenson: Interesting. So then you would query in natural language about just has acts happened? Right. Like what is the process of, it's almost like speaking to, not like a plant manager, but speaking to someone who had performed the operation themselves.
Mica Rubinson: Yeah, exactly. There's a lot of really interesting information in those conversations. Right. So you have the person in the field and he's seeing what's really happening. He's eventually when he communicates to us, then we can use this information to improve ourselves.
Rob Stevenson: Right.
Mica Rubinson: Because he is the ground truth of what really happens. So instead of guessing, we can really know in that case.
Rob Stevenson: And so the idea is to take the data that that person in the field has collected and then be able to query it as a chat bot, essentially.
Mica Rubinson: So not exactly as a chatbot that's another thing that also happens at the company. We have AI chatbots on the interface with the customer where they can ask what's going on with the machine and so on. But what I'm talking about is like a process that we do internally that we like scrape off all the conversations and then understand from things that happen. If we see important words or you anything like that, we can use that to make our labels, better and then use that for retraining processes, for example.
Rob Stevenson: I see. Okay, that is interesting because like those conversations, those back and forth than being used to inform the technology that process that back and forth, that is like the work, the capital W work. Right. Of improving your product. And that is the kind of information that you would need to train a new employee, for example. And so I'm seeing more of that as well. Like internally, how do we identify how work is actually done? And if it's in these conversations and these text based conversations, can we feed it to some text so that other people can use it? Is that the idea?
Mica Rubinson: not exactly. Because I think in our field one of the things I learned being at Augury was the importance of the domain knowledge, the domain expertise, like having someone from the outside understanding what's going on is important to some extent because eventually you would need him to perform an action or something like that. But when it comes to the models or the way that we want to train them, we really need to be specific and to understand what kind of data we want to use. And it's something that it wouldn't work to just use the data as is and plug it in and hope for the right things to happen. We really want to take the main knowledge of those vibration analysts and eventually incorporate it into the models.
Rob Stevenson: Okay, yeah, that makes sense. So when you are considering this domain expertise that is necessary. Right? It feels like this would be pretty manual. This need to sort of be labeling this data and then determining what is feeding the model and not feeding it. Is that the case?
Mica Rubinson: So it's problematic to do it completely manually because you do need large data sets. Eventually we have so many machines and so many records that you won't be able to go through them manually all the time. You can't do it for a small data set like a golden data set that you can really go through manually and have as a ground truth to test yourself on. But it's something that you, you need to find a way to like have a rule of thumb of what you want to use when you try to, to create A data set and what features you want to feed into the model. So we use a lot of domain expertise there to kind of help the models understand the things that we know are important. This requires our algorithm developers to have familiarity with signal processing. For example, they need to take the signals, they need to clean them in a way that would leave out the most important information, filter the signals, et cetera. You would, if you ever saw a vibration spectrum or any kind of frequency spectrum, there are a lot of peaks and noise, signal to noise ratio is not always great. So you need to find a way to extract the important part and know where to zoom in. And that way, when we do that, when we extract the important features that we know are related to faults in machinery, right, like specific frequencies, the speed of the machine, frequencies that are related to bearing faults and all of that, then we help the detectors, the models to zoom in on what's important. And regarding your question on the manual labeling, so we can use like rule of thumbs, right? We can take, we need to consider for example, what the good examples to show the model, right? The false examples, the true examples. So there you can take for example, all the examples that the analysts approved, like we said before, but you need to consider that different analysts think differently, right? They tag things differently. One is more traditional and the other would approve more. Like it's not traditional, sor, conservative. One is more conservative and the other could approve more. So you could, for example, instead of taking everything that was approved, you could take only the detections that eventually led to a change in the machine health index, for example. So you could be sure that this event was meaningful. So these are the kind of things that we can do more automatically. We need to come up with those set of rules to make our data sets better. And eventually we feed into the model, those features that I told you about that we know are most likely to have some kind of relationship with what we're trying to detect in the machine.
Rob Stevenson: Okay, yeah, this is what we're converging on is this idea that we're moving past this idea of an LLM, some kind of grand Unified theory grant, like know the AI can be query about anything or tell the model can do anything. And the more specific the use case, the more specific the training has to be. And so you need this huge scale of data, but it's also so specialized. And so that's the challenge. It's like, okay, the scale is maybe too big for individuals to put a dent in. Are there Any ways for you to kind of automatically feed the model and train the model, or does it necessarily, because of the specificity, need to remain more manual?
Mica Rubinson: It's not really manual in the sense that you do try to help the model by giving it a set of features that are likely to relate to what you're looking for. But you're also kind of, you can do like a spray andray, right. You can take the spectrum and you know, you think that those bins are probably interesting. This. I can take the RMs or whatever of those bins and just let the model understand what's important.
Rob Stevenson: Right.
Mica Rubinson: And probably if the model spots that's an energy in a certain band kind of increased, it would understand that this is something important and it can do it by itself, if I show it enough examples and it sees kind of a pattern. So in that sense it's not all manual. There are things that are very general and common and you can try to use them. And you can also give it very general features that are not necessarily linked to our domain and might help the model as well. So it's like a balance, I think, between the specificity or, and between the letting the model figure out what's important. And eventually we do feature selection and we understand what was the most critical for the model to perform best. You try all those things, try different methods. It's a lot of trial and error in this field. It's not like there's one clear path to go through. I think a lot of data scientists experience that they try different models, different ways, and eventually you go with what works best. Right?
Rob Stevenson: Yeah. Yeah, that makes sense. Okay, so it is, I guess that the other answer is just you're constantly monitoring accuracy, you know, and so the accuracy goes in the wrong direction, then it's something to zoom in on. There's always that safeguard. Now I'm certain also when you are saying that you're training the model what to pay attention to. Right. And it's learning what is important, there is perhaps a difference between what you like to see on your end at Augury and what the customers care about when they are considering the own health of their machines. And this is related to something I see happening a lot, which is just this need for AI professionals to expand their own skill set into this way where it's like, okay, you understand how the model works and you understand how to train it and you understand the output, but you have to communicate that first to the rest of the business and then also probably to the customers too. So when you are considering what to present to the customers, what they care about, how are you managing that?
Mica Rubinson: So that's really true. You need to take a product perspective when you consider what to show the customers. If internally in the AI department you would consider recall and precision and those kinds of metrics, then it's not what you would necessarily show the customer. You need to explain and use matrix that make a difference for their outcomes and their goals. Right. And I think you can say that their goals are to prevent catastrophic events and to avoid downtime eventually and to save money. So I think that we do have this connectionion of our AI Metrix, eventually are around the win rate and miss rate and all of that. But then eventually we quantify this for the customer as their roi, return of investment, how much they saved. By using Augury like this, we avoided this downtime. How much does it translate eventually in money that you saved?
Rob Stevenson: Right. That is I guess the bottom line. Like literally that's the bottom line.
Mica Rubinson: Yeah.
Rob Stevenson: And so is all of this processing happening on the edge in the actual machines of the customers or are you doing it at the Augury mothership? Where does the compute happen?
Mica Rubinson: So both we do have edge calculations. We're gradually moving a lot of our algorithmic abilities to the edge feature calculation for example. And that allows us, when we do it on the edge instead of the cloud, it allows us to send less data, improve the battery life because we're sending less data and reduce the data transmission costs. And we can consider machine learning as well on the edge, which is also around the corner. And then you can allow for shorter time to alert. You don't need to have all that cycle, all that time spent sending to the cloud, getting the analyst to review the alert, all of that takes time. If you're on the edge, you can immediately alert when you see a catastrophic event. Generally in our field, most of the issues, most of the faults are developing over time. So usually it's not the main reasons, it's not the most pressing issue to have. Like fast deteriorating faults are less so or are less common compared in the, this general field of faults. In machinery we do see more of a, developing faults over time, but this is something that you know when it happens it's catastrophic. So you have to get it, you have to alert on it fast. So edge computing can help with that. But it's not like we can easily or we don't necessarily want to move everything to the edge. You do want to have computations in the cloud first because It's a balance you don't necessarily save all the things I mentioned before, because it's all a balance between the energy you spend on the sampling on the edge device and then the energy you spend on the calculations. You need to balance that with what you saved by not sending the data. You have memory considerations. Right. You can't do everything you want on the edge. You're limited by the accuracy that you can achieve. And you also have limitations like you can't look at the machine as a whole. You're limited to the edge device you're on. So in the cloud, when we can see all the, endpoints at the same time, we can use magnetic sensors from the motor to say something on the driven equipment. And that's something that's much harder to do on the edge if you don't have communication between the endpoints. And, and it's a whole other more difficult story. So that's one of the limitations. And I think that's the reason that you would always want to keep, the two parts like edge and cloud, each of them having their own advantage and disadvantage.
Rob Stevenson: Yeah, Edge computing is all fun and games until you have two devices on the edge that have to talk to each other.
Mica Rubinson: Right, Exactly.
Rob Stevenson: Yeah, that makes sense. But I guess the whole point too of the Internet of Things is that the things are doing the compute. So that is an interesting balance you have to strike. And this like such an unsexy answer when it comes to like cloud versus Edge. But the answer is always, it depends. And it seems like most people seem to kind of iterate what you said, which is that there will always be a use case for cloud, even as edge computing becomes more desirable in certain cases, partially just due to the increase in processing power at the edge. Would you agree with that assessment?
Mica Rubinson: Yeah, ah, I think it's a fair assumption because I would also say that even if you're completely like edge based and that's, you know, that's the core your product, it could work. But you would get to a place where you do want something sent over to the cloud, because otherwise you won't be able to monitor yourself at all. Like if you're on the edge and you don't see what's going on, right. And you start getting bugs and you start seeing alerts, bugs happen all the time. Eventually a bug will be introduced somehow and you always need to be able to monitor yourself and to be able to check the data every once in a while. So even as when we're moving to the edge we have a lot of reasons not to fully be on the edge. We do want to have the raw data. like, you know, if you're calculating features, that's great, but you want the analyst and you want the algorithms as well, the detectors to have access to the most accurate, the highest resolution data that they can have at least once in a while you don't want them to have the limited, because eventually it's limited. What you get from the edge would be limited to compared to what you can have on the cloud. And if you don't let them have access to that, you, you won't benefit from it. And also you won't be able to at least go back a few hours ago and check, okay, I had that data before. Maybe it can tell me something about the problem I'm seeing now. Because otherwise you're probably blind to what's going on.
Rob Stevenson: Yeah, definitely. When you speak about monitoring though, how much of that necessitates large amounts of cloud compute monitoring?
Mica Rubinson: A lot, a lot of our work is very dependent on us monitoring ourselves. If it's monitoring our feature calculation, our detectors output, the accuracy of the models, we always, you know, the memory consumption of, you know, the algorithmic pipeline. Like if something happens suddenly, you see a spike, then, okay, someone introduced a bug. We need to figure out what's going on, we need to roll back a version or whatever. So we are constantly monitoring ourselves. And that's really a, thing that we need to consider when we're moving things to the edge, because what we're used to monitoring is suddenly not as easy as it was before. We need to understand how we monitor things from the edge. We need to prepare a pipeline for that. Just also think that it kind of like it spreads out the responsibility because things that are going on on the edge are not written by the same people that are coding in the cloud. Right. It's usually firmware engineers that are doing the coding inside the edge and it's the, algorithm engineers, developers that are doing the work on the cloud. And that's when you have to do this close collaboration I mentioned earlier, and that's actually part of what my team does. We have this strong collaboration because we're responsible on what's going on on the edge, algorithmic, wise. But we're not always the ones that are doing the coding itself. It'in different language, it's not in Python, they're doing it in C or whatever. So we need to have that strong communication and we need to be able to explain to Those people that are working on that aspect, what they're doing, how to monitor themselves, how to know that they're not introducing bugs, how to check that the output is correct. So that's also something to consider.
Rob Stevenson: A world of hurt awaits you when you move from the cloud to the edge is what I'mly. But as you said before, at any time you have more than one, device, more than one machine, and those machines need to behave harmoniously. Now you have a need for cloud computing, Is that correct?
Mica Rubinson: For cloud computing?
Rob Stevenson: You're saying that creates the need for.
Mica Rubinson: The need for cloud computing? Yeah, yeah. And I think, well, you know, we're not there yet in a place that everything you want to do in the cloud can happen on the edge. Maybe we'll get there eventually. You know, things are becoming smaller, you know, devices are becoming smaller and with more memory. So maybe, you know, in the future, but now we're still not in a place where whatever you want to do in the cloud, you can do on the edge. So I think eventually, if you want to have a product that gets to the highest quality detection or, you know, the highest quality, the best performance that you want to get, then eventually I believe you would be limited with the edge. So it really depends on what the product you want to have. Right. It's okay to have a product that uses that, and if that's what you want, then it's okay. But you will be limited.
Rob Stevenson: Yeah, yeah, makes sense. Well, when we think about the limits first, clouds versus edge and how to have them behave harmoniously and monitor it. As you said, a whole new world of problems awaits. And, maybe that's part two of this episode, but for now we have to wind down because we are creeping up on optimal podcast length here. Mica So this has been fun getting to JYM with you today. So thank you for being here and sharing your expertise with me. I'LOVE love chatting with you.
Mica Rubinson: Thank you so much. I was happy to be here.
Rob Stevenson: How AI Happens is brought to you by Sama. Sama's Agile data labeling and model evaluation solutions help enterprise companies maximize the return on investment for generative AI, LLM and computer vision models across retail, finance, automotive and many other industries. For more information, head to sa.com.