Quality Conversations: The Association for Manufacturing Technology (1 of 2)

Last month, ARMATURE Solutions Corporation became a member of AMT – The Association for Manufacturing Technology. Our first order of business was to schedule an interview with AMT’s VP of Technology, Tim Shinbara Jr., to talk about the past, present, and future of manufacturing technology. Tim is a real expert on this topic: he started his career as a manufacturing engineer with Northrop Grumman before moving over to AMT to lead the organization’s manufacturing technology department. Tim’s winning combination of experience, perspective, and enthusiasm made for an exciting interview. We covered a lot of ground during our 30-minute conversation, so we’ll break this Quality Conversations interview into two parts. We hope you enjoy Part #1 below.

Hi, Tim. Thanks for joining us! You’ve been with AMT for almost 7 years, and are now the VP of Manufacturing Technology. What drew you to this organization, and what do you feel are some of the key benefits it offers to members?

Hi, happy to be here. Wow, I can’t believe it’s been almost 7 years. I came out of Northrop Grumman and the aerospace industry, and what really brought me out of that world was the larger portfolio of manufacturing technologies that AMT and its membership covered daily and, in a sense, also recognizing how they all work among one another. I understood all the breadth of technologies available and how people were using them, and then I started to see challenges of adoption and interoperability. AMT gives me a way to help the industry by raising those issues and then trying to walk with members through both education and access to technology partners to solve them.

That’s a great answer, and it leads nicely into my second question: I like what you say in your LinkedIn bio about the importance of standards based on open interoperability, modularity, and founded in security. Can you expand on this?

Sure. It all starts with the premise that data-centricity is a thing. You have to believe that the data is valuable and that moving that data, utilizing that data, is what is going to differentiate you. Once you’re on board with that idea, then for me, it follows that technology solutions have to be open and interoperable amongst themselves, or else this digital thread doesn’t exist and your digital factory/smart factory can’t function. Anything that comes out, especially in the enabling, foundational, fundamental area of the technology stack—by that I mean things like USB ports and MP3 format—all of these different standards people don’t think about until they want to go buy a new device and it doesn’t use that port or format. So you are taking out such friction; improving your overall capabilities. That’s why interoperability is so key for me, and why it’s such a priority here at AMT. We don’t go around racking and stacking standards by any means—we happen to do the MTConnect standard, which I’ll touch on later—but when people ask us about standards, we answer with criteria. If these standards aren’t accessible, open, and free to some extent, for interoperability and further extension, it’s not useful.

And for modularity, part of the challenge we have in the manufacturing world is what do you want to do with plug-and-play? People always talk about it, and it’s almost pie-in-the-sky, because if you ever go off on the floor, and you see how much concrete has to be broken up, and cables for power and connectivity laid down, the thought of being able to move machines and automation equipment around like you would printers and routers…we’re nowhere close to that in the manufacturing world.

But we’re even further from that if you look at it from an interconnectivity and a data transport area. So if you want to plug-and-play a different machine in, to make whatever product you’re about to make, the connections are one thing, but the information transfer for modularity is another thing altogether. So we see standards around modularity as not only key, but essential. And even if you wouldn’t move your equipment around physically in a plant, you certainly want to upgrade your plant. So that still plays to the whole modularity plug-and-play world which we’re getting better at building standards around, but we haven’t seen the unification and the harmonization like we have in the printer and the network and www kind of world.

And the last part is, unfortunately today, security is an afterthought, especially cybersecurity and even more, cyber-physical security. So we haven’t even described the language nor the requirements that would guide someone to build out a solution with security in mind. What we do today is siphon off or create physical barriers—air barriers—from data, whether it’s from cabling or it’s a firewall, but we do it as an afterthought. We’d love to see more standards that start to prioritize security. That’s why “founded in security” is there in my profile. Everything we’re doing these days, I’m hoping that the cadence of the language puts security first. And if not first, then at least within the top three for any solution that’s going to connect a factory, visualize data, or make something more intelligent.

Absolutely. Okay, so let’s hear about the MTConnect® standard.

You got it. Almost 12 years ago, we started working with two Daves. One, Dave Edstrom, a prior Chief Technologist of the Americas Software Practice Sun Microsystems, and the other, Professor David Patterson, from UC Berkeley. Dr. Patterson came from the computer science world—he was one of the developers of RAID and understood protocol stacks in the server storage world. He knows what he’s talking about when he thinks about standards and how to work protocols and standards into a stack solution. We had taken him to a few different plants to show him the manufacturing world, and he saw how far behind we were. Both Daves pointed out that everything speaks a different language and no one knows what the definitions and the semantics mean around even the language that exists. So we started the MTConnect standard based on that premise that language should be normalized and shared amongst things.

The MTConnect standard is an information model for the manufacturing domain. It does two things for us: it structures and defines the data so that it’s hierarchical. Let’s say, for example, you’ve got three machines: A, B, and C. One is made in Spain, one is made in France, and one is made in Germany. They all say “ON” in their native language. Unless you have a three-way translator, you don’t know what any of them are saying. We define that normalized single language and it’s a layer above whatever that OEM might produce. So we’re not telling people to change how you write your code internally; we’re just saying “add a layer on top of it that translates.” In the standards world, in the MTConnect world, we call that the adaptor—that adaptor normalizes it to the MTConnect-prescribed model with definitions for other people downstream, like software app developers, to use it.

We now have a Standards Developing Organization, MTConnect Institute, that has become quite the stalwart as far as IIOT standards organizations go. Basically, no one was doing anything in the world, there weren’t even the letters IIOT 12 years ago, and no one had really thought about it. Many people were attacking connectivity from just a transport perspective, meaning, I’m going to get some 1’s and 0’s from a place A to a place B, but during that piping process, no one could identify the fluid that was going through the pipe. That’s why semantic models like MTConnect have become so valuable, because now people realize that they need to know what that data means. So we’ve been developing this model with over 200 member companies for about 10 years; we have quite a bit of data items covered.

Sounds like you’ve made a lot of progress in the past decade.

For sure, but there’s still a lot to do. Another takeaway from this call is how we see the future of standards in general and we think the word is “harmonization.” MTConnect was never meant to boil the ocean. It was meant to do a specific thing for a specific group, and that is information models, domain models, for manufacturing technology. Period. Obviously that’s not the only thing you’re interested in in a whole entire factory: you might have different technology that’s not manufacturing, like packaging, rotary tables, or you might have shipping stuff you’re interested in. So there are other domain models that can be utilized together and that’s the harmonization we’re describing. We use reference specs and companion specs to allow models to map and fit together. So the whole world of standards is really starting to change: how we develop them, who’s developing them, it’s all changing. We’re trying our best with the MTConnect Institute and are thinking differently about standards to keep up with the change.


Stay tuned for Part #2 of our chat with Tim, where you’ll hear his perspective on the past, present, and future of manufacturing technology. To learn more about The Association for Manufacturing Technology, visit AMTOnline.