For the latest episode of our podcast, Data In Depth, we sat down with Ed Kuzemchak from Software Design Solutions. Ed digs into the ways companies can use the Internet of Things (IoT) to increase efficiency. He shares advice on how to identify areas of opportunity to implement IoT and strategies to make the most of an IoT investment.
Check out this episode below and head over to Data in Depth to listen to our other episodes!
Don't miss an episode! Follow Data In Depth on Facebook, Instagram & Twitter and listen and subscribe with any of the following:
Have a topic you'd love to hear more about? Interested in being our next guest? Let us know in the comments below!
Transcript
Announcer: Hi and welcome to Data in Depth, podcasts where we delve into advanced analytics, business intelligence and machine learning and how they're revolutionizing the manufacturing sector. Each episode we share new ideas and best practices to help you put your business data to work. From the shop floor to the back office, from optimizing supply chains to customer experience, the factory of the future runs on data.
Andrew Rieser: Welcome and thanks for joining us for season two of Data in Depth. The podcast exploring data and its role in the manufacturing industry, I'm your host Andrew Rieser. Today we are joined by Ed Kuzemchak. Ed is a Chief Technology Officer and Director of IoT and Embedded Systems Engineering at Software Design Solutions which is an Applied Visions Company, welcome Ed.
Ed Kuzemchak: Thank you Andrew for having me on.
Andrew: Yeah super excited about today's topic kinda like digging a little bit deeper into it. But before we get into the meat of things, it'll be great to hear, a little bit more about your background and what led you to IoT in this world of embedded systems and what led you to Software Design Solutions?
Ed: Sure, I have about 30 years experience in embedded systems and the first almost 15 of those was actually at other companies. I was part of a defense contractor, Raytheon and then part of a small startup doing embedded systems, then that small startup, got purchased by Texas Instruments, and so throughout that the common core of all those things had to do with helping people build embedded systems software, very tight code, very power efficient, or memory efficient code. And then as we started, Software Design Solutions 16 years ago, we focused on that particular software, embedded software firmware kind of market. And back then there was no IoT. You know, IoT wasn't even a word, it was formed, but certainly the same concept still existed. Back then it was called machine-to-machine communications. And you know, I still kind of like to bring that up to folks. That you know, IoT didn't spring out of thin air, it was an evolution of machines talking to machines, but now the internet has enabled more things to talk to each other. And so as Software Design Solutions got involved more and more, in more embedded systems talking to other embedded systems or embedded systems talking to computer control systems we got very involved in the machine-to-machine communication, and then finally into what sprang up as IoT.
Andrew: Yeah I think that's a good point to point out that a lot of technology, I think when you think back on it has been around for a while and just these evolutions of things like the internet and different programming languages and different ways of which systems communicate. Certainly evolves but the concepts still hold true to things that have previously been completed in prior evolutions. So obviously the internet was a big tipping point to now allow traditionally kind of dumb devices if you will, to become smart devices, or turned on and able to share data between one another. So we'll tackle a little bit of that here in a second, but I think maybe we can keep pulling on that stream with just IoT. So now we fast forward, machine-to-machine communication is in play. This new buzzword of the Internet of Things has now become prevalent. So what's your point of view on that? And maybe more specifically, how does a company frame or draw a box around the Internet of Things and wrap their head around it, so that they can make something tangible?
Ed: I think the most important part for a company to do is to look at their systems that they have today and say, what part of these systems that we have today, can we make more efficient, or more cost-effective, or higher-performing if we had better information? 'Cause that's really all that IoT is all about. It's about gaining data, where you didn't use to have data, or you couldn't get as good of data or as up-to-date of data. If you had to wait until the reports came back from the field, from your field sales tech or your field service techs on machine failures, and you might have a two-week lag on machine failures and your data that you're looking at, is always two weeks old. Well what if it was only five seconds old? You know, would it improve your system? If it wouldn't then ignore that for the moment? You know, maybe that's not worth looking at for you, but if it would that's important or if you even better, it could reduce the number of truck rolls that your techs have to even go out and do to gather that data. Maybe they don't have to go visit that piece of machinery out on a pipeline in the middle of nowhere, in the woods somewhere. Unless that machinery is not behaving the way it should and I think that's the box that as you say, that the companies need to draw around IoT. Sometimes folks come to us and a C-level has pounded her fist on the table and said, you know, we gotta get ahold of this IoT thing. We've gotta get IoT in our system. And so the C minus one levels, come to folks like us and say well, you know, what can IoT do for us? And you know, our question back immediately has to be, what do you have? What do you want to make more efficient? Because that's what you need to address.
Andrew: I think that makes perfect sense. I was listening to a webinar earlier today around the state of manufacturing. And most manufacturers that we talked to think the constant theme is also trying to do more with less. And so I think with COVID-19, we're seeing this really come to light as well. So trying to identify areas of opportunity where technology and things like IoT and sensors can reduce the manpower footprint, but also provide scalability, as it relates to leveraging some of these technologies to your point, in example that you gave, avoid potentially having to send somebody out into the field to check on something. Whereas the data could be streamed from the sensors back into the manufacturers home base and provide then that real-time update.
Ed: Yes because it used to be that reducing those kinds of truck rolls was all about the dollars and cents of the truck, and the gas, and the person driving, but now it's also a hazard that you have to consider. You know, it's a way, that you can make your employees your most valuable resource, safer. And that's going to, as you say, kinda change the calculus of some of these return on investment decisions that are made. It might not have to do any more with, well, it's saving us enough in gas? And that guy has to go there anyways. And what if he doesn't? what if he doesn't have to go there? What if it can be done remotely? What if it can be done with the staff that's there, it doesn't need our technician? Let's keep the folks separated and just have them initiate the sensing to do the data reading.
Andrew: Right, so I think a lot of times when you think about these projects and the evolution of them. There's a typically at least in some studies, a high propensity for failure or deeming the project as being a failure or not meeting the expectations of what it was set out to do. So when you were speaking earlier, I think you had shared really this concept around an agile mindset. And so maybe you can expand upon that a little bit more and how that applies to these types of projects.
Ed: Sure I think that the very first thing to say that is a little controversial is don't be afraid for it to fail, and you do that in every business. You do small things quickly and expect some of them to fail, and some of them to win and some of them to win big. You know, you play small many bets, and I think that the important thing there is to not consider IoT as this big multi-year, six, seven figure-project that we have to understand all of it and then cost out and do the ROI on all of it and then get all of it approved and then go do all of it. That is the most unagile way to behave. The more important way to do this, or the more efficient way to do this is to let's go look at some short wins. You know, some low hanging fruit that can be addressed and let's go look at the most important pain points that you have, or perhaps not that it's the easiest ones to address. Let's go try that out and expect some of them to fail. And hopefully they'll fail fast. You know, we might be able to go out and with off-the-shelf hardware, and off-the-shelf sensors and something like our asset management system, to collect the data. We could in a very short time frame, say, you know what, that data is not very helpful to you? Let's go do this other data instead, and what you've done, is you've gathered a piece of information that you didn't have to spend a lot of money to learn and you pivot and you say, oh you know, now this data was important to gather. Let's go do the next step on that and go down the next step and say okay, now we're not gonna do off-the-shelf hardware. We're not gonna do off-the-shelf sensors. We're gonna do something a little more exotic, something a little more cost-effective potentially, that we can produce tens or thousands of. And we can get them out in the field and we can have battery lives instead of, you know, instead of two months on a prototype, maybe we can have two years on a battery.
Andrew: Yeah I think the agile mindset is definitely a key element of this. Not only just to, your point identify what's working and what's not working and be able to iterate off of that. But I think it also helps lower the bar to where you feel like you aren't boiling the ocean and trying to tackle too much, but it makes these projects a little bit more bite-size.
Ed: Yeah I think that's the key. You know, folks tend to lump if they're not doing IoT yet, they tend to lump IoT into an R&D department. And it really has a hard time there because what you really need to do is do some quick small projects. It's almost better if it stays out of the R&D budget, because R&D is usually a two to three-year kind of timeframe and that's not what we want here. We want a two-month timeframe. We wanna get data back in two months and figure out whether that data is even worth collecting and that process needed to be reasonably inexpensive to do.
Andrew: Yep so in projects like this, talent becomes a key element. So you've got the business value of the ROI that you're looking to accomplish, but then you also have the stakeholders and the talent of executing this project. Maybe you can expand a little bit on that and kind of what you see works and doesn't work as roles within a company.
Ed: Sure and I think that one, of the most important things to do is as you say, is to identify the stakeholders, and that's not just the people writing the checks or the people who are going to identify the plus minus on the ROI, but it's also the people that are going to help understand the data. I mean one of the most important things, when you work with any outside firm, whether it's Software Design Solutions or somebody else is to realize that they're not experts in your business, almost all the time. Very seldom are you going to go find someone, you know, like maybe you run, a set of industrial facilities, that stamp out metal parts. Anybody who knows that stuff, is probably not a consultant and probably your competitor. And so the most important thing to do is to bring someone in who understands collecting information, and collecting data and sensing of course, because sensing is important. But get them together with your own internal domain experts, we call them. So this is, you know, not necessarily someone in a lab, with a lab coat and a PhD. This might be the foreman on the line that has been with that machinery for 15 years, and they understand that machinery. That's who we would refer to as a domain expert, and so if you're talking about machine downtime, it's very likely to be someone who works on that machine and understands that machine. And so by pairing that person, who understands the domain with a classical data scientist from SDS and our classical hardware engineer from SDS, so that they can understand, the combination of what's possible to collect in terms of hardware for sensors and things like that. And what's a reasonable analytics to do on that data. They compare with the domain expert to say is this reasonable? Is that reasonable? What do you do today? What do you wish you had? You know, we work with customers who have terrific data and domain experts. You know, we have a customer, that they can dig out old notebooks full of data from decades ago. To say, here's these parts, here's how many times they were serviced, here's what the test results were from QA, and you know, to come in and say to the customer like that, no, we know better, you know we know better how to do that, ignore that information. We're gonna provide you this whiz-bang you know, cloud-based fog compute system, and you can ignore everything you currently know. That's just silly.
Andrew: Mm-hmm, mm-hmm, recipe for disaster. So the the big thing around data that always intrigues me with the Internet of Things, I don't know if it would be a misconception, but I think it's a fear, that with sensor data, or data in IoT if you will, that there's just so much of it. Like how do you sift through all that noise and find the signal, so with sensor data how do you communicate that with your customers of look here you're gonna be inundated with data, whether it's from the sensors, the machines, the systems, the processes, the customers, how do you make sense of all that and kind of filter it down into either dashboards, reports or results that provide value for the company?
Ed: Yeah that's a very good point Andrew. You know, I fell into the trap early on in the IoT of following along with what people were saying, which was collect it all and sort it out later. You know, the cloud's a big place, just store it all, you'll find use for it later, and you'll throw away what you didn't need, and that's not really correct. That's not really the way to approach it, and it scares people. Especially after they get a couple of cloud bills. I think that the most important thing is to go back to the processes they're trying to improve and the systems they're trying to look at and say, what data interacts with those systems? You know, if I want to measure machine downtime, I probably care about vibration, and temperature and those kinds of things on the machine. I probably don't care as much about, you know, trying to think some things maybe I don't care about, maybe I don't care about the humidity, or the rate at which the machine next to it is working. I might find out that I care about which operator is which on the machine. Maybe that there is some operators that are a little kinder to this machine than others, you know. And so that's where involving that domain expert is really key because they can help you narrow down from the potentially hundreds of things you could collect, and really inundate and confuse the process to maybe the four or five. And that's why we really have very early on switched our model to, okay we're only gonna collect a few things and go from there. Kind of this you know, very small low hanging fruit. So let's just put a temperature sensor on this bearing, see what that does, You know, is that it's an inexpensive to do? Yes, off-the-shelf temperature sensor, off-the-shelf, you know, radio modules, sending that data to our asset management system to collect it and view it, and what analytics do you use? Maybe you just use Excel, maybe that's what you're happy with for now. Let's see what that gets us, instead of, you know, really making the process into this large, you know, we need this great big analytics system and this dashboard, and these wizards soon, we'll get there, but we'll get there incrementally. And well, we'll end up with is something that we did thoughtfully, rather than kind of shoved it in the back door.
Andrew: Sure so with some of your customers and specifically, I think some of these domain experts or folks that are on the shop floor and are responsible for manning and tending and the maintenance of these machines in some cases. What sense do you get from them when you're engaging with them? Do you feel like this is just voodoo to them of this will never be as accurate as their gut feel for this machine or the system or do you feel like they embrace it as something that provides value, and yet another thing that enables them to kind of coexist in this world between data, and sensors, and the machine, if you will?
Ed:I think that that's a very important thing to address early on in your conversation, when we talked about stakeholders and the reason why we feel like finding those domain experts and getting them in the room early is an important part of this because we need their buy-in because we need their help. And so if it was just you know, SDS meeting with the C-levels, signing a purchase order and saying go off and do this cool thing. And then we show up with it a few months later and try and bolt it onto the machine. While the guy who is really the domain expert stands back and say, you know, that's never gonna work. You know, he had no part of it. He had no part in it and he has no ownership of it, and I think that that's important. This person is just as important as a stakeholder. Similarly IT, you know, there's this whole IT versus OT adversarial relationship that doesn't have to be adversarial. You know, if we have the IT representative in the room, she may be able to upfront say, well, you know what, what you're saying will work, but we have to do it this way. But again, if we show up three months later, she might just say, uh-uh that's not going on our network. And you know, that could scuttle the whole project.
Andrew: Yeah I think, at least I agree a hundred percent that inclusion of those stakeholders early enough and provides nothing but values. And so obviously there's road bumps, and hurdles, and things that often have to be overcome. But I think it's definitely important to make sure that everybody's on the same page and marching in the same direction.
Ed: Sure that's right.
Andrew: So a couple more questions before we wrap up. So kinda tying things back to data, where do you see the biggest challenges and or the biggest opportunities as it relates to data in this new world of IoT?
Ed: I think that there's been a lot of discussion about machine learning, and I think that machine learning has a good deal of opportunity, but I think it has to be treated as a tool. That the combination of the domain expert and the data scientist uses. I think that machine learning is often kind of treated like a panacea and folks say, well we want machine learning on that. And we kind of have to talk to them, talk them back off the ledge and say, well, what you're describing isn't a machine learning problem, it's a heuristic problem. You know, what you're trying to achieve here can be achieved with a simple heuristic and here's the heuristic. Temperature goes above the set point, raise this alarm. Now there might be plenty of machine learning opportunities in the broader scheme of that temperature versus this vibration, versus whether it was, you know, the Monday after Superbowl and all of those things. Believe me lots of machine failures probably happen the Monday after Superbowl. And so especially on the losing team. So I think that there's a lot of opportunity there in terms of collecting data. I think the opportunity to have the, you know, the new hardware that's available, and low power sensors, has allowed us to put sensors in harsh locations, in remote locations. In places where we couldn't have before and make them battery operated. And I think that that is allowing us to play centers on machinery where we wouldn't have been able to five years ago.
Andrew: So that kind of leads into the final question of what's next? What do you see on the horizon as it relates to IoT, these types of projects, and you kind of alluded to it a little bit there about the cost going down and the ability to deploy these in previously on deployable locations, but any other tidbits of information that if you had a crystal ball, where you see the next five years?
Ed: I really think the entry of these low-cost cellular connectivity technologies, and I'm not talking 5G. 5G is kind of the antithesis of what I want. I'm actually a little upset that 5G and what I care about which is NB-IoT and LTE Cat 1 came out at the same time, or roughly because 5G gets all the press and all the push and folks ask us, do we care about 5G in this sensors? I said, I don't know are you gonna stream Netflix onto the sensor? I don't need 5G on the sensor. What I need is an NB-IoT cellular connectivity that is power friendly, and it will cost me a buck a month instead of 40 bucks a month for a cell phone kind of connectivity And it will let me place this out in the boonies somewhere. 'Cause something like Cat 1, runs on the current LTE network. And so that is going to allow the kinds of things where you talk about agricultural sensors out in the middle of fields, you know, maybe with a little bit of solar power, but maybe only a battery. And those kinds of things would just be unheard of five years ago. And they're just now coming into the forefront. As we go further and we start talking about these sensors providing this data and maybe mesh networks, being able to hop that data back to where they can get to finally a connection to the internet. I think that that's going to allow for new types of data to get collected and then analyzed.
Andrew: Perfect, well Ed thanks so much for joining us today. I'm always fascinated to hear other people's points of view around these topics. And to our listeners hopefully have some good nuggets and takeaways of this conversation today.
Ed: Thank you for having me on Andrew.
Andrew: For those of you listening, if you'd like to learn more about Ed and Software Design Solutions, I'd encourage you to visit, https://softwaredesignsolutions.com. And if you'd like to connect with Ed, we'll be sure to provide relevant links to the online profiles in the show notes. If you enjoyed this episode, please take a moment to rate the episode and subscribe to Data in Depth, available on iTunes, Google, Spotify, Stitcher, and pretty much anywhere else, you might listen to your podcasts. Thanks again for joining us today,
Announcer: Data in Depth is produced by Mountain Point. A digital transformation consulting firm, focusing on the manufacturing sector. You can find show notes, additional episodes, and more by visiting dataindepth.com. Thanks for listening and be sure to subscribe wherever you get your podcasts.