Transcript.

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.

This podcast is brought to you by PTC and Live Works, the world's most respected digital transformation conference. In this series we will feature partners of PTC who are driving digital innovation and value creation today.

Welcome back to the Industrial IoT Spotlight podcast. I'm your host, Erik Walenza, CEO of IoT ONE. And today we're speaking with J-L Beaudoin. J-L is VP of platforms and Innovation at Averna. And Averna specializes in developing and deploying smart testing and measurement systems. With J-L, we discuss technology development trends related to core components of testing and measurement systems such as machine vision, RF and automated handling. We also discuss the importance of an IoT data management platform and building systems that are both scalable and easy to customize and modify over time. I hope you enjoy our discussion.

J-L, thank you so much for taking the time to speak with us today.

J-L: I'm happy to be here, Erik.

Erik: J-L, before we kick off and really dive into our conversation, I'd love to learn a bit more about yourself and Averna. But before we dive into the conversation around your technologies and your expertise, just personally, where are you coming from if you look at the trajectory of your career over the past 20 years or so, maybe would be useful for our audience to understand the expertise that you're bringing to the table today?

J-L: First of all, I've been with Averna for the last 10 years approximately. I've touched multiple areas of the company. I've studied electrical engineering back in university a while back, and I've started into an IT company, a company that was manufacturing products that would be integrated into a final computer, and worked into different types of markets from financial to medical to just pure consumer electronics.

And then from there, I moved into a company that was doing manufacturing gear. And we were the approved supplier for Intel and AMD for some of their semicon manufacturing process. And then after that I've joined Averna, where we focus on bringing product quality for our customers, which are generally electronics OEMs. And this is where we basically provide solutions from design to manufacturing and repair.

Erik: And then from our earlier conversation, I recalled Averna is focusing on connecting assets and making sense of data? Why this focus? Why is this important in the manufacturing demand?

J-L: I guess the type of product or the type of solutions that we do, we developed and define complete systems and sometimes a complete assembly and test process for a company. We can do that in the design phase or we can do that in the manufacturing phase. But those solutions that we engineered develop and deploy, the whole objective is to confirm the quality of either the design or the manufacturing process. And the only way to be able to convince the customer that those machines work is the show the data and to prove to them with the data that the test satisfied their needs and the product went through the proper validation process.

So connecting that data to a system and presenting it to the customer is key in making sure that those systems are accepted and to prove also that those systems are doing the job that they're expected to do.

Erik: And are you then focus primarily on Greenfield systems or deploying new production lines or new equipment into facilities? Or do you also get involved in retrofitting brownfield environments?

J-L: Yeah, so we definitely do both. Big area of our businesses, of course, when customers need new equipment, because they have a new product introduction, and there's new technology that's coming up. So they either need to test something new or they need to build a new line. But also some of the practice that we do for connecting the assets and managing the product process information is to be able to help our customers connect something that's existing out there in the field or improve on something that they already have. So we do come in with an offering for both those use cases.

Erik: What is the difference in the process, maybe the challenges in these two situations, if you're looking at a greenfield situation? I suppose, you have much greater control over the equipment, and also the software being used in the system. And if it's brownfield situation, you have a lot of legacy technology that you're dealing with. Do you have a perspective on how the typical process would differ through these different environments? Or is it really more on the individual case of each factory, and they're not necessarily singular differences between a greenfield and brownfield deployment?

J-L: So if we're talking about a Greenfield, where a customer is looking at using new technologies for brand new line, or it's a startup that's making it to production, in that case, we have a lot more influence on the technologies that can be used for such a deployment. So all of our expertise can come in, and we can provide the recommendations for the infrastructure, and also recommendations on the process to develop and to integrate that within the infrastructure.

And, of course, if we come in a greenfield, we suggest to the customer that all of the assets that they're using must be by default open to receiving or connecting with the infrastructure. So, sometimes customers buy an application that's closed, in which after that it's very difficult to extract the data or to connect to the unit. So that's a key element. And it simplifies after that all of the integration.

Now, in a brownfield application, what we've seen is customers have people who are building production line or design solution, there are so many ways to do this. And it's like painting, the engineer is the artists, and he can decide to do it, or she can decide to do it the way they want to. So it's unless the company was really strong with a standardization process, a brownfield will require us to adapt to a plethora of different software architectures and even some sometimes different hardware architectures.

Erik: The types of clients you're working with, do they tend to be Fortune 1,000 companies, or do you work more with medium sized enterprises?

J-L: I guess we're about 400 people worldwide as a company and most of our engineering resources are in the Americas and in Europe. And then we focus on automotive customers, met devices customer, consumer electronics, telecom, semicon, and defense and aerospace. So that’s six big markets for us. But most of our customers are Fortune 500 customers. So this is where we found that our value proposition was the strongest with our customer base.

Erik: And I suppose fortune 500 in those industries, then your customers would be fairly sophisticated in terms of their understanding of what they want to do or what is possible. Is that generally the case now that your customers have a fairly clear idea of what's possible and what their objectives are? Or are you, in many cases, doing some hand holding in terms of educating your customers along the way?

J-L: There's a little bit about, most of the time they're educated. But the fact that we work in different types of industries gives us opportunities to take technology that's been proven in one of the fastest pace market and take it to a market that may be slower paced in terms of changes. So for example, automotive consumer, they move much faster than medical and defense and aerospace.

So, while the customers might be very sophisticated in medical and defense, the pace of change may not have given them an opportunity to try technologies that we've already deployed in some of the markets where the pace of change is much faster.

Erik: The solutions that we had discussed earlier that you focus on were smart test and measurement systems, intelligent machine vision, RF and automated handling and integration. Am I getting that right? Or are there other core areas that you also focus on?

J-L: I guess, definitely, we do focus on those. I mean, smart manufacturing and test measurement system is the bulk of what we do, meaning that all of the other elements are subsystems of that.

Erik: If we look at machine vision, my assumption is that you're not developing this technology yourself, you're working with partners, is that correct that you're not the hardware and the software is coming from technology partners rather than from Averna?

J-L: The hardware usually comes from technology partners. The software, in part, sometimes we do all of the software ourselves, like including the automation, the FPGA, the algorithms. So it depends on the application. Some applications, what's available of the shelf does not provide the right level of capability. So there's a lot of software that we need to do.

But anything that we do requires a platform the overall environment to save enough data that if you do a change after that, you can actually put that change in effect on the previous results and see how big of a change there is. So you can rerun the algorithms on the last 1,000 parts, for example, and see if your yield in production or if your design requests if they would have changed with that new algorithm. So it's extremely powerful to be able to save images and save the data.

Erik: Would you also then be involved in in building the algorithms, taking you through the testing process and then in the continuous improvement for some period of time after the solutions deployed? Or do you build the system and ensure that it has the required capability and then hand off to your clients to build the algorithms for their specific use cases?

J-L: It's a really good question. And then typically, the customers that are coming to us for those types of application rely on our expertise to provide them with the right algorithms and the right functioning system. So we do that through a process of evaluating samples and doing some pilot projects. But once it's in production, unless there's a problem, things are running smoothly. If there's something that's happening, they'll usually contact us to take a look at the system, see if it comes from the vision software or from the mechanical solutions or sometimes it comes from their own manufacturing process.

So this is where working on the proper set of data gives you a quick indication as to where the problem lies. And we've seen that in the vision space. But if you do electronics testing, or RF testing, being able to acquire the right set of data from product testing, and after that from process will give us such depth that once a problem arise you can help the customer define if the problem comes from the product, the process, the suppliers, or potentially the station itself, so the asset itself.

Erik: How much learning can be shared across companies? Of course, there's a data privacy issue here, so you're not going to be sharing data across. But if you have just deployed a solution that's maybe screening for scratches on some sort of automotive component for one customer, and you have another customer that's also looking at scratches on a metal product, is there a lot of learning that can be transferred? Or are you fundamentally building up the algorithms with unique data in each case, and there's, in fact, not actually much learning that can be transferred across projects?

J-L: So I guess the methodology, some ways it's similar. So if you know the big parts that go into this system, the methodology will be similar. But for example, for vision applications, the materials, the size of the part, the way it's handled, the vibration, the type of issues that you're looking at, all of those details typically varies from one project to another. So while the methodology might be the same, the final algorithms or the final system will differ because there will be many moving components or, let's say many different characteristics that will change in the final product that you have to inspect.

In RF, typically, what you have to deal with is a lot of different protocols. So, all those protocols will vary a little bit. And even though sometimes you may think that by having the same type of failure on two different customers, the way that they design the boards themselves will also differ a little bit. So the failure or the origin of the failure might be different because of the design, even though it's the same protocol or it's the same technology that's underlying.

So, the job that we have is to create the methodology to deliver a test solution that will be able to exercise the product in such a way that we will be able to find the failures. And then once the failures are found, then we need to be able to rely on the process data or some of the manufacturing data to be able to pinpoint where the issue may come from.

Erik: This issue of the proliferation of protocols, do have a perspective in terms of where this might be trending? Do you see a movement towards greater standardization? Or do you advise your customers towards more standardized solutions? Or do you think we're going to continue to exist in an environment where communication technology is highly, highly customized in each facility?

J-L: So I think we can talk about two types of communication technologies. So, one is on the shop floor. Most of the time, what we see it's Ethernet. So that's still what we see on the shop floor. We think that this is going to continue to be the connection between the assets and the central server. Within the products themselves, it's highly dependent on the market that they're in. So, of course, WiFi and Bluetooth are very popular. As you know, there's Bluetooth over the air for medical that's taking off with everything that we see from having device being implanted inside people.

And then you have the new telecommunication protocols like 5G that are coming up and that should be a big transition. But in general, all of those protocols, there's multiple revisions of them. Even WiFi has six or seven revisions, and there's always a new one coming. So what we see is that customers just need to continue to invest in tools that are as standard as possible. But as the communication protocols evolve, they sometimes have to do a revamp and just move to the next generation. So on that side of things, sometimes they just have no choice but to reinvest.

Erik: You'd mentioned the importance of having a platform to store data for use in machine vision or other situations. I know you're partnering with ThingWorx, is this platform that you would typically go to? Or do you develop unique platforms for customers? What's the perspective on the platform that you would typically use for customer deployment?

J-L: They, I would say that, have two types of deployments. One is when the customer already has an infrastructure, they already are standardized on some kind of software. In this case, it could be an MES software, which stands for Manufacturing Execution Software. Sometimes we need to connect to an ERP. Sometimes they have custom database that they've built internally. So for deployment, where we don't control the environment, or the customer is not looking at the environment, is just trying to add in the existing one, we just need to comply to their requirements. And in that case, we need to connect the tool to their preferred solution, and make sure that the flow of data back and forth it is acceptable and works well.

What we've seen in the market is that it's very diverse, there's a lot of software packages out there. Larger company, sometimes they've been on an acquisition spree, they've merged with or acquired a bunch of different companies. And what we see is that a lot of our customers have a very heterogeneous infrastructure. And it's very difficult for VP of ups to be able to know exactly if all of the plants are at the same level. In general, they have multiple software packages, multiple revisions even within the same software package. And from an IT perspective, what we've seen it's kind of a nightmare for those big companies.

So because of that, that's what kind of prompted us to go towards something that's a bit different than the traditional. I call them Industry 3.0 packages, but we looking at Industry 4.0 or smart manufacturing, we found that PTC and their IoT platform is bringing a lot of value to the chain. As a company, this is our platform of choice when we can help the customer go into a certain direction, we’ll direct them towards PTC ThingWorx actually.

Erik: So ThingWorx then can be used either as a substitute for a MES system if that does not already exist in the facility or it can be used to connect data across disparate systems if a company grew by acquisition, for example, and has quite a complicated portfolio of data management solutions. Is that then the different use cases for when ThingWorx might be relevant in a deployment?

J-L: I guess it's a complex answer. But the best answer I can give is there is an immediate value in using PTC ThingWorx just for asset management. It's very well suited for that. It's got some machine learning capabilities that's called Analytics. So you can connect your asset to it. If you've got the right sensors, and you send the right information to the package, you can use the value of that platform to do some preventive maintenance. It's a very specific application. And that's what actually brought us there at the beginning.

But the overall value of a platform like this is that you don't need to transition all of the different MES and custom platforms and custom database right away to one standard package. So another MES, for example, what you can do is use this IoT platform on ThingWorx to connect from the PLM, which is your Product Lifecycle Management software where you have your bill of material and some of your mechanical drawings and your electrical drawings.

So you can go from there to a release bill of material that can be used for manufacturing. And then you can see each of the lines within ThingWorx. And with the same package in that was one of the strengths of PTC, you can actually use something that's called Augmented Reality to have additional information about your process when you're at a station. So you could actually expand on an asset and see its drawing, see different parts or extend on the product or the operator [inaudible 21:43] information available when an operator does its work using all augmented reality.

And that's a different path than the ERP. ERP is more of a financial tool. And we found something that comes more from the product design that has more value when it comes down to trying to troubleshoot something in manufacturing. So that's why we kind of took this approach rather than another approach for the IoT platform.

Erik: You'd mentioned augmented reality. HoloLens is releasing, I believe, now it's pushed back to June or so their next version, which is supposed to be a significant upgrade. But do you see a movement towards using these headsets? Or is the majority, do you think for the foreseeable future, going to be on mobile or pads, how are people actually deploying or engaging with augmented reality in the cases that you've seen?

J-L: Augmented reality is something new on the manufacturing floor. So people are slowly looking at that, and thinking that this could bring value. Of course, when it comes down to games, it's a clear benefit, it's more virtual reality there. But augmented reality, in the case of manufacturing, what we've seen is from a training perspective, you can really help train an operator in a much faster way than if you don't have that augmented reality gear available to you.

So there is a clear benefit for training. And then people needs to be accustomed to that in their work environment. So there's always a reluctance to change. From what we can see and from the power of that platform, the fact that you can bridge the drawings of the product to the operator and be able to give them more information can really help the whole process and the whole quality of your manufacturing process. So we've seen that those operators will take advantage of that value.

Erik: So ThingWorx is a platform where you're able to develop customized software for different situations. Do you have standard solutions that your team has built on ThingWorx that you're then able to modify for specific situations? Or are you typically doing a fresh build up for every environment?

J-L: Yeah. So the answer is that we do both. So we have some basic IP that we developed within the context of ThingWorx that can be reused from one customer to another. But the integration, the connection to the outside world we will have to be adapted a little bit. But for example, we're looking at some asset management dashboards that are fairly simple. We are looking at connectors with some off the shelf solutions.

Like we've seen that in the test space, National Instrument Test Plan is a very popular test executive. So we developed a solution for that we call it Connects Thing. And we have an Averna thing inside ThingWorx where people can have access to we're in the test the solution is at, what is the past results for that station, the throughput, the OEE. We have KPIs that give you really quickly if [inaudible 25:11] about your asset and see if that asset is performing well or not. So it's easy for customers to install it and get value.

Our goal is to continue to develop some applications. For example, we have our eyes on an SPC application, where people can do CPK, Xbar, and [inaudible 25:32]. So these are statistical calculations that gives you information about your manufacturing process, and can give you some level of trending on your test. So, all of those things can be connected after that with alarms or with machine learning. And then as you learn about your process, then you can register that information.

And the ultimate goal is to be able to predict when the process will fail and stop it before you have too many failures down the road.

Erik: Would you be able to share one or two case studies for a preventative or predictive maintenance?

J-L: I guess I can maybe talk about one of the case study. And that case study is with a big telecom OEM. What we're doing with them is we've helped them put together an infrastructure to make sure that they could acquire the data from all of their stations out there, irrelevant of the station architecture, and then bring the data back into a central location, be able to confirm what is the type of software installed. And do they have the latest information installed?

So we bring KPIs about the status of those assets. Have they been running or not? What's the yield of each of those assets? And we collect all of that data worldwide. I think we have about 2,000 assets that we're collecting data from. And we do two types of things. We have some asset-related information, where we manage the status of those and the performance of those assets. And we have the product test data aspect as well. And the product test data is used to understand if there's something wrong on the process, or also in the product design.

And over time, what we've been able to do is incorporate elements of the suppliers. So, basically, if you are able to integrate the data related to the bill of material along with the test data, and the process data, that will give you almost a 360 view on your manufacturing process. And the beauty of that is that when you connect this to machine learning algorithms, or machine learning process, you can define if the issue that you're seeing today is coming from one of your supplier, or if a trend that you see in some of the measurement that you're doing, with overtime, if it’s known to come from an asset or it comes from a drift in your manufacturing assembly process.

So this is something that we've been working on for years. Of course, it's not something that you can deploy in a day. But the acquisition of all of that data into a single central location is what gives the power for our customer to be able to create additional value for their supply chain and also for their quality department.

Erik: Maybe we can wrap up with some of the lessons learned from your experience in these past 10 years working with Averna. You mentioned in our prior discussion that managing processes is critical. Can you maybe give us a perspective on why this is important? And what would you do in order to provide the highest probability of successful deployment?

J-L: Well, first of all, I'd say one of the most important thing I find is that tests quality is usually what makes or breaks a name. So branding is important from a marketing perspective. But quality helps keep that name nice and beautiful across a long period of time. So in order to make sure that you keep your brand and you keep quality as part of your brand, then I'd say, one, is to make sure that design of a product is well tested. And maybe companies should take just enough time to do the testing, but then have the best processes from design to new product introduction to manufacturing to transfer after that design into manufacturing.

And if you have a good tool set, you can quickly bring something from a final design stage to manufacturing. When we talked about processes the design, the release to manufacturing process is an important one. The other one is once you're in to manufacturing, I would tell all OEMs that data is yours. So it's important that the assets that tests at the end of the line that makes sure that your quality is good, either they belong to you, or you have clear ownership of the data that comes out of it. It's important to have background information to verify that things are aligned and also to build a proper set of tools inside the company to be able to understand which of your supplier is the best supplier.

And also, are there any failure mechanisms that that you can easily understand and automate so that down the road, you reduce your scrap, you increase your quality, and you improve your product design. Because this feedback loop between manufacturing and product design is an important feedback loop as well.

Having a platform that can make sure that you can easily see that data acquire it, be able to plug a machine learning system and analytics system to it and having a capability to disseminate the information within the enterprise is all part of making sure that if something happens, people are learning about it quickly and your organization learns about it as well.

Erik: You mentioned data ownership, I suppose this default at this point is that the OEM owns the data, although for smaller companies, there's sometimes a leverage issue with their equipment providers where they might be pressured to give up ownership. What is your perspective on sharing data when it makes sense to provide access to suppliers or partners to specific datasets in order to help them improve their services, improve their technology? Is this a topic that comes up often in your cases?

J-L: Yeah, that's something customers sometimes ask if the data that they see if they can have portals where their suppliers can see only what's related to them. So they'd like to have segregation of data, and they'd like to be able to share. Especially if it's a partner, that's an important supplier, they want that supplier to grow with them. So yeah, that's definitely something we've seen and we've been requested to look at.

Erik: But I suppose technically, that's ThingWorx, for example, not particularly challenging. It's more of the question of what to share and with whom that would be a potential sticking point?

J-L: Yeah, absolutely. And with ThingWorx, you can define dashboard mashups that are specific to a supplier. So it's fairly easy to do. So you can publish it. You can present it. So that platform will definitely allow customers to do that.

Erik: So J-L, last question from my side, what is the best way for somebody to reach out to Averna?

J-L: I think I suggest people to just go to our website, and we have our different locations, and you can contact the appropriate region and the sales manager of the appropriate region. If you're interested in hearing more about us, we'll be happy to support you.

Erik: Well, we'll put that in the show notes. Again. J-L, thanks so much for taking the time today.

J-L: Thank you, Erik. Have a great day.

Erik: This episode of the industrial IoT spotlight podcast is part of a collaboration with PTC, the global software company that helps companies design, manufacture, operate, and service things for a smart connected world. To learn more about PTC, visit www.ptc.com and to collaborate on future podcasts with IoTONE, please feel free to reach out to us at team@IoTone.com

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.