Hirotec America recently embarked on its first IoT effort and, as new as it is, the effort is already paying dividends, says Justin Hester, Research Development Project Manager. Hirotec is a $1.4 billion tier one parts and tooling supplier to automakers, specializing in closures (such as doors and hoods) and exhaust systems. Hester was instrumental in getting the IoT effort off the ground at the company’s US headquarters in Auburn Hills, Michigan, but has since moved to Japan to work on Hirotec’s global IoT efforts from the company’s global headquarters in Hiroshima.
How did the IoT conversation start at your company?
Hirotec is mainly a tier one production company for the automotive space, but we also sell tooling to produce the same assemblies, so what we learn from internal production we implement on the tooling side and what we learn from tooling we implement in production, so both businesses benefit. Once we started thinking about that same model for the data side, we started to see the potential benefit of what data and data analytics could give us for both our tooling and production customers.
In our opinion, IoT isn’t just about receiving information. IoT really is a closed loop automated system where we’re collecting data from all our devices, whether in our production facility or our customer’s production facility, automatically analyzing the data, automatically tying it to other datasets -- whether they’re public or private -- then making at least automated suggestions if not taking automated action.
For example, our system could theoretically look at our production schedule for the day, look at the weather, look at traffic patterns, and predict a traffic backup on a main delivery highway. Knowing that will delay our truck for an hour, the system could automatically rework the production schedule to optimize for the trucks that will be available. That gives you an idea about where we want to go and the potential that we see.
If that is the nirvana vision, how do you get there from here?
We knew we couldn’t get there right away, so we started looking at how we could do this in little chunks. What we realized was our CNC shop here in metro Detroit, which is the manufacturing headquarters where we make production tooling we sell to the North American automotive industry, was a perfect area to start -- it has machines of different ages, so we have to connect them differently, and they spit out various data types. And while the machines themselves are very complex, the data we need to collect isn’t very complex. Is the machine running or not? Is the machine being set up or is the machine turned off? Very basic data points that we can pull.
So that was a great place to start because it’s a small area, it’s local, it exposes us to variation between machines and it will bring some value to the organization. We’re actually in the midst of the project right now. We are connecting eight CNC machines to a server from Kepware that collects data using various protocols and sends it up to the cloud where PTC ThingWorx does the analytics and the data visualization for us.
Are you looking to collect more information than you would have historically?
Yes, and to be clear, the new dataset is a small portion of where we think we’ll be in the long term. Again, it’s the idea of small projects, six-week sprints, adding incremental value and providing us with a proof of concept. But one of things we found was that uptime data, cutting data, etc., was available, but not in a usable sense. It couldn’t be consumed in real time with relevant context around it. That’s really where the value is. So even with this small project we’re bringing value to the organization because the data is available in a quick, labor-free or real time fashion.
A lot of scheduling in the CNC shop is based on after-the-fact analysis and conjecture. Now we’re going to be able to give our manufacturing leadership real time data on what’s actually happening on the floor, which is helpful in itself, and start giving great data to help streamline schedules and help understand our asset and resource allocation. Do we maybe need to add more resources? Are we overtaxing the resources? You can make those decisions without this tool, but it is harder and not as accurate. The immediate value we can bring is providing that data upfront in real time.
And as we continue to grow, we’re going to use that as our basis to add more and more value. The next step in North America is to tie this data into our scheduling ERP system so we can start doing real time scheduling of parts to our CNC machines. If we know when the machines are running and we know how often they can be on and manned, then it’s very easy for a computer to take the hours of the jobs coming in and optimize the schedule.
The Kepware server you mentioned helps you get over the initial hump of just connecting the various piece parts?
Exactly. We call it our universal translator. We don’t have to worry about what protocols our machines use, whether it Ethernet/IP, PROFINET, Modbus, DeviceNet, any of those industrial communication protocols. With Kepware, I don’t have to force my machine builders or my production teams to support a certain protocol that might not fit their application. They may have a legacy machine that requires a legacy protocol. They may need high speed communication which requires a different protocol. It’s not our place to make the business conform to the tool. This IoT tool should conform to the business, and that’s where Kepware plays a huge, but behind the scenes, role.
It’s one of those roles that’s not big and fancy, but it is essential to get things talking. That’s why we’re so excited about it. It’s one of the few tools we haven’t put much effort into, not because it’s not important, because we don’t have to. It just works.
And you’re using Kepware to pass data off to ThingWorx? (Ed note: PTC acquired Kepware in January, 2016.)
Right. ThingWorx is really the IoT platform. I love the name ThingWorx because the software does exactly what they call it. It just makes things work together.
At its core it is really a relational database, but a very open-ended one. We use ThingWorx as a scalable, flexible IoT platform that gives us customized visualization of our data and customized analytics of our data. ThingWorx doesn’t care what kind of data it’s getting in. It conforms to our business processes. At its core there’s a lot of computing power being used to allow these different connections and data points to relate to each other, but from a user standpoint, it’s conforming to us.
In the first project we’re using it as a visualization tool to give us this real time look into our CNC shop, but within the next couple of years we’ll potentially be using it to do things like rescheduling the line in real time and for predictive maintenance, telling us a machine is going to break before it breaks, those kinds of things.
You called it a platform, so I presume you’re building on top of it.
Absolutely, and we are using their interface to do it. They call any type of screen you create a mashup because you take these different data types and put them wherever you want on a screen and it does all the hard coding in the background.
That’s another thing that drew us to this ecosystem -- I don’t need hardcore professional programmers. I can take engineers or business leaders who understand their section and with limited training they can get what they need out of the system quickly. That was very important to us, because Hirotec’s expertise lies in automotive manufacturing and automotive production. We’re not programming experts.
There are so many “IoT platforms” emerging now, do you think you’ll end up with multiple platforms or will you strive like hell just to have one?
One of the key things we’ve determined is the need to stay flexible. We always understand that the market brings new technologies and new solutions and we’re evaluating them all the time. That being said, when we did this initial evaluation we said we needed an ecosystem that’s scalable and flexible because you can run into a lot of trouble if you start having multiple solutions across multiple business functions because then you have to create custom connectors and it gets confusing and convoluted.
We need an umbrella that has different flexible tools under it. We’re not interested in getting a separate tool for each function; one IoT platform for production, a different one for tooling, a third one for our back office, a fourth for our service division. To us, that’s just asking for problems down the road.
I imagine, however, that you’ll eventually want to integrate your systems with other suppliers at some point, so will you end up running into this problem anyway?
I think the industry definitely has that challenge. But again, that was a reason we went the route we did. As long as we stay flexible in our ability to connect to things, we can bring them in.
Right now everyone sees the value of platforms and there are a lot of vendors trying to bring solutions to the market, and I think over the next five years we’ll see consolidation and some standardization. That’s one of the benefits of working with a leader like PTC with ThingWorx and Kepware, because they’re a leader that understands the manufacturing space, and you know they are helping to set some of those standards.
Did you evaluate many other platforms?
We did. We started with our traditional automation partners, Siemens and Rockwell, Mitsubishi, all these companies, and they all have interesting solutions. We also looked at nontraditional suppliers like Microsoft. We think of Microsoft as a business software provider, but we looked at them and some of the other major players. They all have great solutions. But no one other than PTC, in our opinion, was able to bring this robust ecosystem to the floor. Everyone had a solution for a portion of our business, but they couldn’t give us that overarching toolset to solve all our problems.
I want to change gears a bit to consider organizational change. You’re in RD, but has this new IoT push changed the way you work with IT?
It absolutely has, and I think it’s very exciting. IT in an engineering company really was the superman in the background that kept the business running, but it was really more a request and fulfilment role. The business or the engineering side would come and say, “I have a request to do this.” Then IT would say, “Okay, we’ll execute that.”
Now we’re seeing -- and this has us very excited – that IT is starting to play a more vision-setting role up front. So we’re engaging IT on jobs earlier, whereas previously they would have had no visibility into our roadmap and strategic goals. Even in this small-scale project, our RD engineering team engages with IT on a daily basis. From an RD and IT standpoint, we’ve engaged with them more in the last six months than probably the entire history of the company.
And what we found is that, not only do you get better answers to the questions you’re trying to solve, but that additional perspective is really helping all of us improve across the business, not even just in this space we’re working in. When you’re dealing with other teams on a daily basis, it’s amazing how those benefits go outside of the projects you’re working on because we better understand each other’s daily life which helps us support each other better on a daily basis.
Do you think this may eventually lead to some larger scale IT/RD organizational overhaul at some point?
The way I put it is, I don’t think the standard business’s org chart will look the same in five to ten years. As the world marches down this IoT path, this smart manufacturing path, we’re going to start seeing the lines blur between the traditional kinds of reporting structure we’ve had. We don’t have an answer today, but we can see that something is going to change. We don’t know what, exactly, so right now we’re just dealing with cross-functional teams.
In the interconnected world of IoT, the question of data ownership gets interesting, especially considering your business as a tool supplier. Will you be collecting data about the performance of your tools in other people’s operations, and will they permit that?
That’s an ongoing conversation that we’re having internally, and then will to start to have it externally. How do two companies share data? Who owns it? How do you put it in the proper sandboxes? These are all great questions, and the honest answer is we don’t have a solution today. But what’s great is the industry is starting to recognize this challenge and we’re starting to brainstorm answers. It’s just a matter of us all coming to the table and finding a solution that fits everyone’s needs.
Anything else you think is critical to this whole IoT movement?
When it comes to IoT in the industrial space, two things, and they tie together.
One, I’m passionate about the six-week sprint idea. I’ve seen more creative and lower-cost solutions come out quicker than I’ve seen on other projects, larger or smaller. Six weeks in, people can see the light. I’ve seen our team present new solutions that we’ve never come up with before, just because of the sprint model.
And I think that ties into the big fascination I have with IoT, which is, I don’t necessarily think we’re waiting on technology to solve any of our challenges. I think what we’re doing is understanding culturally in business how to implement these solutions. The sensor data is there. The communication protocols are there. The tools like Kepware and ThingWorx are there. It’s more a matter of what does that look like in my business? It’s all very much cultural and human things that we need to solve, not so much technology challenges anymore.
Technology will continue to move forward and give us even better solutions, which is great, but the reality is it’s more of a business/human transformation than anything else.