In this episode, we discuss the state of the IIoT business from the solution provider point of view, and the direction of end user organizations as they are orientating themselves around IoT solutions. We deep dive into 2 case studies – 1 on the revenue side and 1 on the cost side.

What is the main obstacle to successful implementation in traditional industries? How does IoT change the relationship with customers? How did companies successfully generate incremental revenue and reduce costs using IoT?

Note: DataV Track will be packaged with another application by Bsquare. Find out more on their product page here.

Dave McCarthy is a leading authority on industrial IoT. As VP of IoT Solutions at Bsquare Corporation, he advises Fortune 1000 customers on how to integrate device and sensor data with their enterprise systems to improve business outcomes. Dave regularly speaks at technology conferences around the globe and he is also a frequent contributor to IT publications. Dave earned an MBA with honors from Northeastern University.

For over two decades, Bsquare has helped its customers extract business value from a broad array of corporate assets by making them intelligent, connecting them and using data collected from them to deliver better business outcomes.

Erik: 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.

Welcome back to the IoT spotlight podcast. This is your host, Erik Walenza, CEO of IoT ONE, and I'm joined today by Dave McCarthy. Dave is the Vice President of IoT solutions at Bsquare. And Bsquare is a company that provides services around data science, IoT Integration and application development, as well as specific software for managing IoT networks, doing prediction repair and asset tracking. And so they're very focused on heavy assets and industrial environments.

We discussed with Dave the state of the business and the dynamics of organizations as they are oriented around IoT solutions, that means breaking down silos and changing communication lines in order to be able to communicate better between the technical teams and the business teams. We also deep dived into two case studies; one, looking at the revenue side, adding incremental revenue stream to a sensor business and the second looking at the cost side, adding telematics to a heavy trucking business to be able to improve asset uptime. I hope you enjoy the conversation.

Dave, thank you so much for joining us on the podcast today.

Dave: Great, thank you for having me.

Erik: Dave, as I kick off, I would love to learn just a bit more about what you do personally and then of course, Bsquare does. I know, you have quite a track record in the industry. Can you just maybe found us in your role at Bsquare and then also share a little bit about your past experience?

Dave: I'm currently the vice president of IoT Solutions. And that Bsquare, that means tracking market trends, and understanding customer needs. The output of that typically ends up being some sort of thought leadership, product strategy, some marketing messaging, and then ultimately architecting customer solutions. And if you look at Bsquare, in general, as a company, we've been around for 25 years doing different things that today all fall under the umbrella of an IoT solution. So whether it's the software side, or the services side that's required to deploy some of these things, ultimately, we're helping our customers improve the uptime, manageability and performance of key assets.

Erik: So just so I understand, are you working more in the front end or the back end of the business? And by that, I mean, are you working more helping to present solutions to the market and craft that revenue generating strategy, or integrating the solutions, developing them and maybe supported on the data analytics side?

Dave: Yeah, so I'm probably these days more on the front end of the business. I've actually personally been with Bsquare for 12 years. And over that time, I started working a lot internally around product strategy and some of the product management around the things that we wanted to do, either whether those are repeatable software components or service offerings that go with that. And a lot of that was based on just experience of being out in the field with a sales team.

And more recently, I've been acting in some ways as an evangelist to try to make sure that when we talk about these types of technologies, and IoT is by far a perfect term for the things that we're talking about, but certainly, a unifying concept. But it does require sometimes some interaction to say, here's the core technology and matching that up with what customers might be thinking about, and trying to dispel some of the myths that are easy to fall into when you have a technology discussion.

Erik: I think we've seen at least over here at IoT ONE is that the technology has matured to a point where in higher proportion of cases in any case, it's not the bottleneck. So the technology exists either off the shelf or it's possible to work with a partner to develop it with a relatively high degree of certainty that you'll build the solution that you are intending to build. But then it's around do we have the right business model? Have we properly understood how this solution will actually be deployed and used by the end users?

Talk a little bit about the type of company that you're working with. Your typical client, are they going to be quite a traditional company that has maybe more of an electrical mechanical engineering background and relatively little experience in data science? Or are you working with larger companies like Bosch, maybe that already have 10,000-20,000 software engineers? What's a typical profile?

Dave: Yeah, it's a mix. Maybe I should start with the industries that we mainly focus on. And so we do define ourselves as an industrial IoT provider, meaning that we're typically looking at heavy equipment, capital intensive, often revenue gathering assets. And this could fall into transportation, manufacturing, oil and gas and energy. And I agree with what you said about the technology now being at a point where it shouldn't be the barrier.

And so when we started down this journey, at least, down the journey of calling it IoT, for me, personally five years ago specifically, it was many times we saw projects being driven by the operational side of the business. And there are sort of different levels of sophistication on that side. But in all cases, I think, lots of silos of responsibility. And I think that that's where you get a little bit into that who's driving these projects? Are they coming out of the operations side or the IT side?

And so oftentimes, what I would see is the operational side of the business would understand the use case, and the business drivers better, but maybe not the technology. You would have people from the IT side of the business that certainly understood the technology and might be off shopping for a platform, but not necessarily understanding the business problem.

And in practice, either these two groups were working independently, or maybe it was just one or the other. But I think that that's what led to some of the slowness and adoption in those early years technology wave. And now I'm seeing much improved coordination between those groups.

Erik: One of the questions that comes up quite often among companies that we're working with, is what is the right structure for us, especially when you're innovating in a new space? So improved coordination, what is the reason behind that? Is it that these two groups are coordinating better? We were seeing positions pop up, like digital office, so kind of new organizations to an extent that are founded with the intention of aligning between different units? What do you see from a structural perspective? Do you think this is more of a matter of just better communication and flow of information? Or are you seeing new structures in terms of how organizations are developing, they’re positioning the resources and developing reporting lines in order to help to bridge this IT/OT divide between the business unit and the technical teams?

Dave: One way often, I think, to judge the maturity of that company in terms of how deeply they thought about an IoT strategies is whether there's a sort of overlay organization exists or not. Because a common practice I've seen, especially in large companies with multiple business units, that each of those operational business units are often off going and getting their own solutions to the point problems that they have. And eventually, centralized IT group gets a hold of it and they quickly learn that there's 20 different projects going on using 20 different vendors. And for them, it's a nightmare because the IT organization is typically there to help standardize and ensure security and those sorts of things.

So we walk into a company and we see one of several things. You'll either see a sort of a steering committee around digital transformation, or maybe you'll see it in terms of a center of excellence, either in IoT, specifically, or something else. But in both of those cases, I think the aspect that's important is that there are cross-functional teams. And then the best one, that's not just cross functional teams have operations and technology, but also other areas such as legal because we're often talking about data and data privacy and data security concerns that have to be part of that.

And then, of course, requiring some sort of strategic buying because some of the early days of IoT, at least as far as how I've seen these companies go down these projects, sometimes it get side card into a technology experiment in a lab, and it never gets the backing to become a justify project with funding. And so the ones where you can actually see that they've done some organizational changes to make it clear who owns these things and to remove some of those cross-departmental blockers and that they have that executive backing in order to make sure that there's funding and support, those are the ones that you can see moving forward in a larger way.

Erik: So we've got a situation now where there's a company that has one new unit that is discovering new technology, and then often working with partners to develop that technology. When particular solutions show promise and start to move towards commercialization, should this unit, because they understand the solution best, should they then continue to own this particular solution as it moves towards commercialization, or should they figure out where in the organization that solution fits best and then basically handoff?

What's your perspective on this in terms of when you have a situation where there's a question around, do we hand this off from? Like you said, it's not a traditional R&D department, it's a cross-functional digital office that does have marketing, and does have some capability. So in theory, they could bring this to market, they'd have to build up sales, or coordinate on sales support and so forth. But they could do this. But it's an open question of whether it makes sense.

Dave: I wish there was one simple answer to that question. I think that every company has to figure out for themselves how best to manage this. And I think we were touching on this earlier that technology is not the blocker, these organizational changes in a way of thinking. And I've even seen cases where IoT starts challenging viability potentially of certain units.

Like one case, an example was the company we're working, where we had an engineering team that was building a connected product and then they had a service or repair team that was responsible for maintaining that once it was out in the field. And they were running this way in a very happy harmony. But what was happening is we were just demonstrating how using some of the IoT technology, we could actually improve the uptime and reliability of that equipment such that service repair was not needed as often. And the service repair organization saw that as a threat because they're paid on the idea of rolling trucks and solving these problems.

And so that’s from a global view, this is best for the business because it was going to put them in a more competitive situation, improve customer experience. There was lots of good reasons to do this. But the individual business areas couldn't see that because it had to change the way they were thinking. And that's why when you say who really gets should own this? One of the things that we try to look for are those areas of conflict.

And if we see them early on, we try to use that as guiding whoever our champion is in the company to say we've seen these types of situations before, and if we don't solve or figure out the correct level of ownership, it's very easy for somebody to come in at the last minute and shut down one of these projects. And unfortunate that's a shame, because oftentimes, it's not because the project doesn't make sense, it's just that it's threatening an area of business that perhaps wasn't intended.

Erik: You'd mentioned, Dave, earlier that you're focused right now on supporting companies on the revenue side of the business. So one of the hypotheses that I had, and I believe was maybe a bit mistaken a few years ago was that if you just divide the business into revenue and cost, that the revenue side had bigger upside in the longer term, but that most companies that are adopting IoT would focus first on the cost side of the equation because they're the business case is a bit simpler to write out. You can look at what an improvement in a particular metric, how that would impact your bottom line and you can make a decision based on that.

And at least what I feel I'm seeing so far is that this assumption was wrong, that maybe companies are feeling like on the revenue side we have to move now because if we're not an early mover, to do predictive maintenance point, if we don't do it, somebody else will do it, a third party, they'll come in, and they're going to take our service business anyways by maybe deploying some third party sensors, and doing analytics on our machine. So we need to move on now.

Whereas on the cost side, companies are maybe feeling like they can wait a couple years because we'll wait till the asset or the technology matures because they don't have the risk of losing out on a business opportunity. Basically, they can deploy that when they feel like timing is fine: there's not the competitive pressure. What's your perspective on just the simple question of where the bulk of the focus is on the revenue generating side or the cost control side of the equation?

Dave: Well, so we have customers that we're helping on both sides. I still see the ones that we're working with solidifying with your original idea, which is do you mean something in efficiency and cost savings is something that's very tangible, something that's easier to calculate, and it feels more real? And so we still have companies that are going through those types of operations.

And it still surprises me today how even larger organizations that will seem somewhat sophisticated still have lots of opportunity to maximize that cost benefit. But I do absolutely identify with what you're saying around people who are selling especially products that have some sort of connectivity and are concerned about commoditization and low cost entrants into the market and trying to figure out how do we differentiate again, where maybe at one point in time they had clear differentiation that seems to be eroding certainly one of the hardest things to achieve. And so we have seeing some interesting new business models. And when we get into some of the customer examples, I can share definitely one of those.

Erik: Maybe before we jump into a customer example, let's just understand a little bit more about Bsquare. So I understand that you're currently more on the front end of the business, but your roots, as I understand them are somewhat more than data science as a service. Could you just explain the different areas that you might plug into a project?

Dave: So one thing to clarify is, even though we're labeled as an IoT company, we don't provide any hardware ourselves. So we're not a sensor company, nor do we provide connectivity. But we are doing on lots of areas outside of those two categories. And so maybe this gets back to your earlier question of the types of companies that you're engaging with, where are they in their level of capabilities internally because that often matches what we do?

Now, there are lots of companies that we deal with in these true and well established industries, especially like manufacturing in oil and gas that are still doing things what I might refer to as the old fashioned way, and never ceases to surprise me how much equipment they might have out there but still not necessarily leveraging the data. So there's an aspect of what Bsquare does around helping companies with the data acquisition side.

And whether that means adding software out to the equipment itself, whether it's a PLC or a gateway to be able to do some of the protocol bridging that's required to bring that data into a more modern platform, and then, of course, the whole challenge of bringing together different communication types and data format and even things like data sampling rates and units of measure and all the complexity that goes on there, we've developed some techniques to ease that process to be able to bring things into a common data store.

And oftentimes, the first things that people want to do if they haven't had access to it before is some level of dashboard and visualization. And we look at that as a good first step in your IoT journey. But in almost all cases, it's really a short term aspect of a full deployment because trying to manage especially equipment scale through dashboards is incredibly difficult. You either run into a scaling issue of just the amount of conditions that you can monitor, and the types of accuracy you can get. And so we've developed software that allows you to apply sort of rules engine based logic, so to applying rules and then workflow.

So the idea is help automate the acquisition of data, help apply logic to detect patterns, and then trigger workflows that either do command and control back down to the device or be able to do integration in other systems. So back to the maintenance example, if you were to see a particular condition that might warrant accelerating a maintenance schedule, then you could fire into CMMS system to inform an operator to perform a particular procedure.

And for a lot of companies, just being able to define some of that simple logic is enough, because they have enough subject matter expertise, and domain experience to be able to say that we can take a lot of their manual work and automate it. Now on the other side, there's a lot of situations where companies aren't sure what it is that they need to be looking for. So for example, I heard a company the other day that was metal manufacturing, and they had a furnace. And they're trying to optimize the multiple stages of heat within that furnace to get the maximize output without compromising the integrity of the metal on the other side. And it's this balancing act between throughput and quality.

And so understanding what the right set points are at any given time to do that was something that they weren't sure about. And so they would typically take a more conservative approach to make sure that they wouldn't ruin a batch of metal. And what we're able to do through some of our data science capability is show them where the safe thresholds were to run things at a maximum level and retain that quality, such a thing, they can automate that through the system. So there's a little bit of data science in terms of things but it's also combined with their subject matter expertise to be able to deliver a comprehensive system.

Erik: So I see you have these two sides of at least from a customer perspective, two aspects of the business, the software, we have data V manage, predict, repair, track, I think these are almost self-explanatory. I love the names because they basically tell exactly what the product does, so it helps you to manage your devices, do prediction, manage maintenance, repair and track assets. So I can see here you're very focused on helping to optimize large high value assets, and then you have the service side data science IoT services applications connected solutions.

Is that first you'd come in with a service, you might help them to assess what data they have to look at the use case and how to structure that use case and then one of the software may or may not be applicable in that case. Is that how a typical discussion or project flow might run? Maybe you could just give us a high level overview of how a conversation might emerge, and then the different aspects of your business that might be involved in a typical project.

Dave: First and foremost, we've learned over time that the best way to start a conversation is to always focus on the business objective because it's too easy to get enamored about technology and what it can do and let's do some demonstrations and all of that, and miss the larger point. And in fact, I think that there's evidence out there that in some of the early days of IoT, people did just that they went to a lab and they collected some equipment, and they showed it on a dashboard, and perhaps even invested in doing that on a larger scale, only to look back and not be able to justify the value that they got out of it, and be able to provide an ROI in order to continue that sort of deployment in a wider scale.

So we've learned to really focus on business drivers and use cases. The naming that we do of the different offerings is really to be tied around that use case. So, some of the use cases around uptime and I like to think of uptime as two sides of the story. There's things that you can do ahead of failure events to be able to prepare for it so it doesn't feel unplanned or on schedule, but to make sure that you're managing it at your pace. But then there's always these unexpected events or things that have to happen. And so how do you remediate a piece of equipment quicker?

And so if you can do sort of predictive understanding before failure, and then do automated diagnostics, and repair afterwards, you've really improved the uptime story on both sides? And so that's one example of a conversation we would have. So is it something like the optimization of that furnace that I mentioned? Or is it trying to look for planned downtime events? And once we can understand what it is that they're looking to do, and ideally put some metrics around it, like I want to be able to improve the uptime of that piece of equipment by 10% or something like that, then we turn it into almost an architecture conversation of well, what would you need to do that.

And as some elements of the pieces I mentioned, before, we need some access to the data that's being generated, both in real time and historical. We need to be able to oftentimes pull in other things like maintenance schedules, or even warranty or factory configurations to understand the different nuances of it. We need a way of doing the rules and workflow. And so we started mapping out here's the use case, and here's what you would need to achieve it. And then we take a look at what the company has already invested in.

Because almost every company has invested in some portion of this and we want to preserve their investment. Doesn’t make sense for us to come in and try to take something out if it's already serving a purpose. So we look to our portfolio of capabilities. In some cases, there might be some of the software that you mentioned that falls into our data V family. And the goal there was really to not just give platform components, but to try to provide more complete solutions for those particular use cases.

And then almost always requires some level of service to go along with that. Because whether you're trying to integrate that software into those other components, whether that's out on the edge into equipment itself, or maybe it's back in a datacenter, or cloud repository to combine with other systems, that's important, as well as the you mentioned the services that we can do around data science. So then we can kind of put together a plan and say, this is what you want, and this is what you have. Here's what you need to do it for mixture of software and services. And then we look at it from a phasing perspective.

Because another trap that I think companies can get into or have gotten into is trying to do too much too soon. And there's some information out there, I think, some analysts have published around a few, if you haven't received some positive ROI within the first year of your IoT deployment, something is wrong, either because you had an ill-defined problem, or either your vendor isn't serving you well, or what have you.

But for you to see that quick win, and then also show a roadmap forward to where either you would bring in perhaps additional volume of equipment, so let's prove it out on a single asset or a single site and then showing the success, use that to bring in additional equipment or additional sites, or maybe it's broadening different use cases. So maybe you're tackling your maintenance situation at first, but then you want to get into perhaps other business models and service opportunities after the fact. We try to walk the customer in a very consultative way through what might be best for their business, and that's actually proven to work very well.

Erik: And then I see that you have, at least on your website here, about 11 partners that have been showcased. I imagine that often especially, if it's an environment where there's need for sensing capability, there's need for embedded technology, you're going to be working with some external companies to be filling technology gaps. How do you manage this? I see you do have these 11, or do these tend to be the 11 preferred partners that are in your network and those solve 80% of the need? Or is there a Rolodex in your CRM of specialists that have the technology in different areas?

Because I think one of the areas that we've seen the IoT domain is that IoT, as you said, is an imperfect term, but it basically describes a system that includes many different moving parts and different technology domains, and very unlikely that any one company has all of the competence in-house. So this means that it's a partner game. From the partnership perspective, what is your general approach here?

Dave: From our website, we certainly have a small group of companies that I'll refer to them as our first degree partners, the ones that we often work with the most. We've been in situations where we didn't need a retrofit kit from a hardware perspective to be able to collect data from the machine that maybe didn't natively have that capability. And so Intel is a place that we use a lot for reference designs for different boards and we're part of their IoT alliance.

And what's nice about that is they also have an ecosystem of partners. And so many times Intel will provide you the reference design. But if you're looking for a finished good, we can dip into that partner ecosystem to pull somebody in. I call that sort of a second degree partnership that we leverage to Intel. And the same thing on the cloud side. So we've been doing a lot of work lately with both Amazon and Amazon Web Services and Microsoft Azure. And so, when there's, again, solutions that require something that may not be something that we do on a regular basis, and so we may not have a sort of first degree partnership with them but we can leverage our participation in some of those ecosystems to bring in people that can help. And in fact, I was just on the call the other day where we had a unique RFID situation and we leveraged that kind of partner ecosystem to pull together a solution.

Erik: So let's dive into a specific project and maybe just walk from initial discussions through deployment and post deployment. Is there one in mind that you'd be able to discuss today?

Dave: Yeah. Maybe we'll talk a little bit about because we definitely expressed an interest in that idea of using IoT for competitive advantage or additional revenue streams. And we absolutely have a great customer in that space. The company's name, it’s Itron. And Itron is a manufacturer of metering solutions for water, gas and electric utilities. And they've been doing this for decades all across the globe.

But they were sensing some of the same issues. They were once considered at the premiere in their space for the metering solutions that they provided. But they were seeing more commoditization, more competitive pressure, and they realized that they needed to come up with some more differentiation.

The other side of it, though, for them too was they wanted to figure out how to change the relationship that they have with their customers. So, Itron will sell to a utility and then we're engaged specifically right now with their electric division. So Itron will sell electric meters to utility and utility will put them out in residential and commercial buildings. But these meters have a 15-20 year lifespan. So for Itron, if they sell you something and come back 15-20 years from now they sell you something else, they wanted to figure out a way to create a recurring revenue model.

And this was actually prior to the engagement with us specifically, they inherently knew that they needed to do something. And they had a product management team internally at Itron that was trying to understand what could they bring to market that would address those concerns. And so they looked at the electric utility market in general, and they can kind of be broken into three areas. So there's power generation which are the power plants, there's power transmission which are those long distance lines, and then there's power distribution, which is effectively that last mile. And that's ultimately the area that Itron spends most of its time in because that's where the metering solutions of it. And for the longest time, there was low visibility into that distribution network or that last mile, if you will, of that network.

And then it wasn't required in the past, because they had very reliable mathematical calculations that say, for a particular area given housing density and what have you, they knew how much power needs to be generated. But the world has changed over the last six or seven years where you have more electric cars that are drawing power off the grid and then you have solar technology that's adding power to the grid. So all of a sudden, their standard math was no longer working.

And then the problem for utilities means that because it's a regulated industry, they can't under-produce power. So instead, what they were doing was over producing power and that's wasted energy and wasted money that they can't reclaim at the end because they had no way of storing it. So Itron said, okay, well, I think what we can do is we can develop a new metering technology that turns what the meters were doing, which are just single function counting usage to becoming more of a multifunction device, where we can do things like active demand response. If we see certain conditions, we can alert back to the utility that they need to either fire up another energy plant or shut one down, or whatever it requires to rectify situation.

And then there was other things like that detection. So whether people are bypassing meters to avoid paying for the electricity, or even safety scenarios, especially in high rise buildings, where there's many meters, and you might have high impedance connections that could cause a fire, incredibly difficult for a utility to pinpoint where those hotspots are. And so they have the idea of saying, we can add this incremental functionality. And in fact, their marketing team actually said that they wanted to become the Apple App Store of the utility business.

But they definitely had areas that were not core competencies for them. So they knew how to build the meter. They knew what needed to be done as far as like they understand electrical physics. But they lacked a way of saying, at scale, when I say at scale, we're talking potentially tens of millions of meters really large environment, where each one might have a different set of these applications. And so how do they distribute and license and manage and monitor all of this granularity going out into their network? It was just something that they weren't clear how to do.

So they knew they needed to find a device management solution. And specifically, not a traditional enterprise device management solution, but they needed a device management solution that would work in their unique environments. And almost all of these cases where you have device management of IoT devices, there's some sort of constraint, either constraint of network or constraint of processing power storage. And so their difficult vendors just didn't have a solution that fit into that.

So we met Itron as part of, I think, engagement at a trade event, where we were proposing some of the solutions that we had out there that we thought were unique, they kind of shared this idea with us around what they wanted to do. They also said that there was going to be a heavy level of integration effort because they didn't want this to be a standalone system; this is going to be a new offering that they were bringing to market so they needed to be branded as an Itron solution, they needed to fit into their existing structure.

So we started with how a lot of these projects do, which is through a proof of concept. Effectively, they put us to the test. They gave us one of their meters. They gave us access to some of their back end systems. We worked with their engineering teams to do some integration, both of our software out on the meter itself as well as on the back end unit. We went through a test of let's show how we would do deployment to make software deployment changes. Here's how we would do configuration. Here's how they could manage it on an easy way that wasn't just for them, but then also giving the power out to their utility customers to make some of these changes themselves.

And we passed, thankfully, with flying colors, and we went through their procurement process and became a partner now within their solution. So they're just actually in the process now. They've been working on this for a while before it became commercially available publicly. For so for them, it's called their Open Way Riva platform, and you won't see the word, you won't see Bsquare anywhere in there because it's been rebranded. But it's our technology helping them do the things that I just mentioned.

And now what that does for them is now says no longer am I selling something to a utility every 15-20 years, but now I can have a monthly or yearly subscription to these value added services that provides new revenue for them, solve the customer problem, and I think it's a pretty elegant solution.

Erik: And did they end up deploying this concept of having multiple apps? So a utility can say in this particular narrow neighborhood or this this region, I want to have this added capability but maybe in another region, I have a different set of capabilities, is that the route that they took?

Dave: Yes, absolutely. So whether it's on a utility basis, so Itron being the sort of overall operator of this system, I mean, they have the ability to see what's happening globally within all these distribution networks. But then they also provide sort of in that multi-tenant fashion that every utility gets its own management console so that each utility can manage their specific meters. And even within there, there are certain ways for the utility to start grouping meters together, because like, for example, that fast detection is not something that utility feels like they need everywhere. But there are certain locations or neighborhoods are higher occurrence of death versus others, and so they can be a little bit more specific around where they want to deploy that technology.

Erik: And the deployment, is it as smooth as your mobile phone? So you say, in this particular phone, maybe there's a house, based on the energy patterns we recognize that they have installed solar energy? Are these meters on particular residencies, or they one meter per block, just what's the level of granularity here?

Dave: So that's yet another one of these applications that they build was around locational awareness. So they are putting meters, so every residence would have its own meter. But what was interesting about your question is utility knows where your meter is because they know where to send the bill every month, so you can pay for your electricity.

But if you were actually asked them, how is that meter connected back to like which transformer or feeder or phase of power, like how was that all really constructed, and the sort of the dirty secret of the industry is that most don't know? And they don't know because a lot of these meters and the infrastructure was put in decades ago, and the documentation was poor. Or when there's a power outage, and they're trying to fix things, things will always go back together the same way.

And so, each meter has the ability to report what it's seeing. And they would typically not deploy on an individual [inaudible 36:59]. So that software would be there. But what they would be looking is for a trend in a particular community, because the way that those distribution networks work, there's usually a transformer that's feeding a community. And if they start seeing that that community is having a higher or lower power demand, then they can sort of reroute the rest of the distribution network to accommodate for it.

Erik: And you said, this is already commercialized, but it's still in the early version one, version two, is that the state, so it's still been improved upon but already in the market?

Dave: Yeah, it is. So they're actively selling and deploying this today. I don't know what their current deployment numbers are off hand. I think it solves some of those problems that I mentioned, though it's a reason now for utility when they're making choices about do I buy an Itron meter or do I buy somebody else's? They're showing the differentiation that they're hoping for because they're now providing different value.

And again, all of these are really for the utilities. So even though these are applications that are being put on the meters side of my house, it's not really for me, at least not directly. Whereas I think there may be some other use cases around energy meters, where they might provide a homeowner an application that just shows you well, here's your current meter reading. Anybody that's tried that finds out you check it once or twice, you probably never look again. The value wasn't really there on the consumer side. It was more on this industrial utility side.

Erik: Since I see Itron is based in in Washington, I imagine they do also a good amount of business in California. Has the bankruptcy of PG&E come up, and I mean, this is obviously a very important use case to solve, this issue of utility causing fires just by accident. But certainly, there's a need for a solution here. Has that come up at all in discussions about whether better control of power distribution or a better insight into where there are faults and so forth in a system would be useful for controlling this issue of causing forest fires?

Dave: Not directly. And I get to hear about that rather recent news story, and it'll be interesting to see as more information comes out about that. But what I do know is that, I think, and whether it's Itron in the electric business, or whether it's a manufacturing company, or whether it's somebody running an oil field, everybody is realizing now that there are blind spots in their business in terms of operations. And while it may have been somehow they've made it this far in life without addressing them, I feel like there's more and more pressure than ever, whether driven by regulation, or whether they're driven just by being a good corporate responsibility to really understand how to [inaudible 39:44].

And I think maybe one of the things that's driving some of that now is that to do some of the things that we just talked about 10 years ago would have probably been prohibitively expensive. This just the technology itself may not have existed. As we started this conversation today, a lot of those concerns are gone. I mean, it's not as expensive as it used to be. The technology is tried and true now. There's lots of options.

In fact, if anything, often the types of challenges, there's too many different ways to do it that it can be difficult to figure out, which is the best. And usually, my recommendation there is the right tool for the job, that what works for one company directly may not be the best in the next situation. It's one of the values that Bsquare tries to bring is that we're not tied to a particular equipment vendor, like we're not a Bosch trying to sell a Bosch solution along with the equipment that we sell or GE and so on. We can act a little independently to say that, given different situations, there might be different combinations of technology that makes sense best given certain parameters. And it's our mission to make sure that we're fitting the right solution to the right problem.

Erik: One of the promises of 5G is that it is better designed for IoT solutions than 4G or 3G, so designed to also handle these small volumes of data. Do you have any particular perspective on 5G and whether it will dramatically impact the cost structure of IoT deployments? Or are you in a wait and see standpoint right now?

Dave: Yeah, it’s still wait and see; there's lots of promises coming out about 5G and some successful recent tests of that technology. So oftentimes I want to see it work with my own eyes to make my full opinion. But it is interesting, though, the difference between different ways that people have been trying to approach some of the connectivity. So there's certainly been a lot of talk around like LoRa, like low power WAM, different forms of narrowband, LTE and different ways of trying to figure out that balance between cost and speed and I guess maybe ubiquity of connections being available.

So I mentioned Itron, again, just to use them some more, I mean, one of the things that is not a constraint for them is electricity, on the electricity side, because they have that. So putting a high powered radio on there to transmit isn't necessarily their biggest concern. But in their other business line where they have water meters, for example, these are often battery-powered device. And so, they want to be able to design in batteries are going to last 15 years.

And I realized 5G is going to cover a huge spectrum of capabilities. I think that certainly, prerequisite for all of these solutions is to have connectivity to devices and being able to transfer data, hopefully, bi-directionally in a seamless way. So I'm looking forward to see where that continues to develop.

Erik: Well, do you have time to maybe walk us through one more case on the cost side of the business just to look at a from a different perspective?

Dave: Sure. So the example I'll use for this is a heavy trucking company. The parent brand is Packer. And they are the parent brand of Kenworth and Peterbilt heavy duty trucks. And so they came to us with a challenge of trying to improve the overall uptime and service repair scenario. Because if you ask them, why do customers buy their trucks? They buy them for reliability. And that works all the way down the value chain. They most reliable trucks and fleets want to buy from manufacturers that have the most reliable trucks.

And so, they for decades have developed strategies on how to make these things reliable. And there was about two or three years ago, I think, where they engaged with us to another meeting at a trade events where we were talking about transportation solutions. And they were just at the point in their company where they had decided to invest in telematics because they wanted to be able to start diagnosing and understanding conditions that were happening on these trucks while they were driving down the road.

And so they went through that first necessary step of putting in a telematics gateway and connecting it to the canvas of the truck and start pulling back data points in the cloud that they could see. And they again, I think, as I mentioned earlier, fell into one of the most common traps when you first start doing this is you sort of underestimate the volume of data coming in, and how noisy it can be in terms of understanding condition.

And so what was happening like a check engine light, if you will, was illuminating on dashboard. The driver wasn't really sure the severity of a problem. He would call the fleet manager, the fleet manager would say, well, take it to the nearest dealer or service center, and I was taking that truck off the road. And again, since those are revenue generating assets, every time they take that truck off the road, whoever that fleet owner is, is losing potential revenue. Not to mention that, when those trucks would come in, they would have to go through a lengthy diagnostic process.

And unlike in the consumer car world where it's quite normal for us to drop off in the morning, pick it up in the afternoon and repaired, these trucks can often be offline for days, or even weeks, depending on parts availability or even technician availability. Here’s another thing that shows up in a lot of these scenarios are a lot of these industries where there's an older generation of knowledgeable workers that are kind of moving out of the workforce into retirement and taking with them a lot of institutional knowledge about how to diagnose and repair. There's a younger generation coming in, doesn't have that same level of experience.

So they were starting to feel the stress of the cost of a warranty perspective of every time these trucks were generating faults, and being taken offline and going through this lengthy process and then having to pay the warranty claims on those repairs, they wanted to figure out a way of how to make that more efficient. And so the first way was to do then was to get ahead of the problem while the truck was on the road. Like how can we reduce the number of unnecessary service or perhaps false service events?

Because the presence of a single error code often isn't enough to truly understand the disposition of that particular vehicle. Oftentimes, there might be 20 root causes that are correlated to a particular failure mode and some of them could be considered very severe and some of them could be more of just a nuisance than you can just complete the job that you're on and come back for maintenance later. But they didn't have enough visibility into that operation to know.

So what we showed them was by using some of the combination of some of the data analytics to understand for any particular error code. And if you were to combine things like the current operational data, so like engine parameters, maybe it’s temperature and pressure and electrical voltages, you could take those 20 potential root causes, and eliminate maybe half of them because the data just doesn't support the current condition. And then using historical information, things that we were able to pull out of previous warranty claims and maintenance events, start probability ranking what's left so that now you have a pretty good level of competence as to what the root cause most likely is.

Because once you do that, you can then be much more informative to the driver and to the fleet manager as to the best course of action. And so they were actually able to reduce the number of services, just because they realized that they were sort of almost over-alarming, if you will, situations that just weren't necessary.

Now, the second side of what we did for them is to say, well, if we're doing this automated root cause analysis while the truck is driving down the road, and there is an event that warrants bringing it in for repair, let's help that second side that I mentioned earlier, which is, okay, so the truck has to come offline, how do we diagnose and repair quicker? And so since we know now the most likely cause, and we can correlate that to parts and service, their technicians skill level, we can now start querying different dealers and service centers in the area to say there might be one five miles down the road from where your truck is today. But it doesn't have everything that's required to resolve your problem. There's another service center 30 miles down the road that could probably get you up and running in a day. Oh, and by the way, all indications aren't safe to go there.

And so, we're getting more guided directions to these fleets and drivers as to where to go. And then when it arrives, the technician is presented with an optimized repair plan that's already ruled out all of the unnecessary diagnostic steps, and optimized that such that they can really start the repairs. It's also the way that we allow those junior technicians to work at a higher level because we're being more prescriptive and sort of almost a step by step.

There's certain things we can determine directly off of the diagnostic data from the telematics gateway. But there's always things like visual inspection items. Do you see something leaking on the ground? Does it smell unusual? Those sorts of things that the technician can sort of enter in, have the system recalculate sort of a decision tree format. If you see these things, this is the way to go. And so what they're doing now is shrinking diagnostic time and the end result means increased first time repair rate so less returns coming into the same problem.

And also, solving another one of their problems, that anybody who has a warranty exposure on an item that requires repair is making sure that people are using, perhaps maybe the least amount and the least expensive parts to get the positive outcome that you're looking for. And so, for example, after going through this process, you may end up with a 50/50 chance that it's a $500 part or a $5,000 part that's going to solve the problem. In the real world, it's not uncommon for the technicians to say, well, I'll just take the $5,000 part because chances are it'll just solve the problem.

When it's possible, the other one would have done that. This now allows Takhar and Kenworth and Peterbilt to be more prescriptive and saying, we're willing to take that chance to say try the cheaper part because there's a 50% chance that that will solve the problem to reduce the vendor warranty expense and improves sort of the overall operation for them. So, we've the two different angles of how we're helping keep those trucks up and running, it improves uptime reliability, makes the [inaudible 51:03] happier, and also provides positive cost savings to the business themselves.

Erik: The service centers, are they also owned and operated by Packer? Or are they kind of exclusive partners? Or is this more of a wide disparity of service partners that have different contractual terms, because then you have this flow of data across organizations?

Dave: Yeah. So, in almost all cases, these are separate legal entities. So like the dealers are not necessarily associated with Packer. But Packer, what they've been working on is ways of providing incentives to dealers say that if you use this more advanced diagnostic approach, but they're making it attractive for the dealers to want to do it this way than the sort of manual process way.

And I was concerned at first, whether or not the dealers would be happy about this because if you think that they get paid based on hours that they can build back to the OEM, then common sense would say, well, we don't want to reduce the number hours, we want more hours. But what we found in actuality was the opposite that somebody used this sort of comparison of service bays in a trucking service center to almost hospital beds, where there's never enough of them.

And so they actually are incented to want to turn them over quicker because there's almost always a waiting line for people to get in there and resolve their problems. So the fact that a dealer or a service center could process more service events or service tickets using this way, they actually saw as favorable.

Erik: Well, Dave, thank you so much for walking us through these, I think both very relevant to a lot of companies and a lot of our listeners. Any other closing points that you wanted to share either about Bsquare or more generally, your perspective in the direction that the IoT domain is moving?

Dave: Well, I think maybe in closing, you always sort of find these two types of companies. So there's always ones that are first movers and early adopters. And the couple of stories that I told today are I would actually both put in that technology forward really trying to push what they're doing to improve their businesses.

And if you're not one of those companies, and you're listening to this, it almost can create a sense of anxiety. Like, everybody's so far ahead, and I'm not there yet. And what am I going to do? I like to caution that you're not alone, that while there's some really good early examples of companies in many industries that are doing this, the majority are still trying to find their way through.

And so even if you don't have your strategy decided today is the perfect time to try to understand what this means to you, and actually leverage those leaders in this space right now as examples of what can be done, and probably recognize that they had to pave the way in ways that might have made it more difficult for them initially, and that those lessons learned can be translated into greater good.

And sometimes maybe the other thing is just that oftentimes whenever there's a new technology wave, and IoT, of course, being the one, people wonder if it's fleeting, will we be talking about IoT five years from now? And my answer to that is whether or not it's still referred to as IoT, my crystal ball says that there's only going to be more connected devices over the coming years generating more data, and even more pressure for businesses to figure out how to use it to their benefit. So, terms and technology names may change over time, but this is an incredibly important concept that I think is going to affect every business.

Erik: If we drew an analogue to the startup domain, looking at new technologies, you could say the first movers have moved. And they've paved the way and they've made a lot of the expensive mistakes and then learn to lessons the hard way. Now it's time for the fast followers. And that's a good position to be in as a company that can learn from the first movers, but still be quite early in their market.

So, Dave, I think you're in an incredibly interesting space. So I really appreciate you taking the time to share your experience with us. I will certainly share your company website and so forth. Is there a best way to get in touch with you personally if somebody is interested in having a conversation?

Dave: Oh, yeah. There's a couple of ways that you can find me. So you can look me up on LinkedIn, David McCarthy, Bsquare and also you can follow me on Twitter at businessofDave

Erik: Great, and we'll put those both in the show notes. Dave, thank you so much, and have a great day.

Dave: It was my pleasure.

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.