Carry a new Lexmark printer or Canon scanner into your office and plug it into your Dell computer. Chances are that it will work right out of the box. Get on the Internet to interact with a Java applet or print out a form in Adobe Reader, and you’ll be able to do it right away, regardless of whether you’re running Windows Vista, Mac OS10 or Linux.
Now, step over to your 5-year-old Okuma lathe and try the same thing with a new cutting-force monitor or a door-guard safety interlock. Or maybe you want to feed the machine tool’s throughput rate into that factory management software you recently installed.
Unless a single provider has supplied all of the machines, all of the peripherals and all of the interfaces, chances are the information won’t flow. Sure, there’s probably a (costly) black-box solution, but why should there be?
That’s precisely the question that officers and members of AMT – The Association For Manufacturing Technology asked themselves a little more than a year ago. The trade association staff decided that there was a vacuum that needed to be filled. Therefore, they launched an organization to come up with a communications standard that could address the interoperability issue on plant floors. Voting money to set up a program in conjunction with professors at the University of California, Berkeley, AMT’s board started the ball rolling toward a cohesive data pipeline for manufacturing.
The organization now embraces equipment builders, manufacturing users and university researchers who are working on a draft computer standard they call MTConnect. The developing standard, which will be shown in use in September 2008 at AMT’s International Manufacturing Technology Show in Chicago, is described as a “bridge” to allow manufacturers to collect, transmit and leverage data from discrete equipment.
At its most recent annual meeting in October, AMT devoted most sessions to MTConnect to give its members and others an update on the standard’s progress: what it is, what its goals are, what it can do and what it cannot do.
What Is MTConnect?
The technical advisory group that’s running the effort writes, “MTConnect is a ‘middleware’ standard that will provide the capability to pass data from machine tools to higher-level systems for further processing using the XML-based standard.”
At the last AMT meeting, recent former chairman Douglas Woods, president of Parlec International, explained the background of the standard and its importance. “Simply put, MTConnect is an open, free, standards-based bridge for all,” Mr. Woods says.
“It’s open for you to see, open for you to use, open for you to manipulate,” he says. “You don’t have to pay for anything; just go to the Web site and download it. There are no fees, and it’s standards-based. We’re not developing some new, rogue piece of software. There’s already great software out there. By basing MTConnect on XML (extensible markup language), we’re opening it up to a huge army of programmers who already use the language.”
Mr. Woods explains the objectives of MTConnect. “We’re trying to develop an open standard that defines a multi-platform protocol for exchanging data for communication between all different types of devices and applications, not only from a machine tool or a piece of assembly equipment to a class of software. It could be any piece, any application, and any device within the factory.
“What we’re creating is the standard to make all this happen. We’re not developing a software product to put on the market,” Mr. Woods emphasizes.
A hallmark of MTConnect is that it’s extensible. To information technology types, the term “extensible” describes a program or protocol that’s intended to have its capabilities added to by users or developers. Why is that important? “When you develop a brand new set of products like these, it’s impossible that you’re going to get everything right the first time,” observes the former AMT chairman. “So you’ve got to avoid pigeonholing yourself into a software platform that doesn’t allow you to expand backwards and forwards. Otherwise, you’re going to have a problem.”
How It Will Work
The developing communications protocol incorporates a method for announcing and detecting any piece of equipment that’s on the network. Take a component and connect it, and it will in effect say, “Hi, I’m an MTConnect-compliant device, and this is exactly what I am.” On the other (network) side, there’s a facility that will say, “Hey, I know that an MTConnect-compliant device just got plugged in.” It works the same way that a USB mouse tells a PC that it’s an optical mouse with a wheel button.
Once that handshake happens, the benefit can be as simple as smoothing the installation of a rotary table onto a different make machining center. Or, it can lead to much, much more. Dr. David Dornfeld, professor of manufacturing engineering at University of California, Berkeley, chairs the MTConnect technical advisory group. His view of the ultimate benefit of the new communications protocol takes into account the entire “manufacturing pipeline” with product design at one end and shipment to the customer at the other.
“I want to be able to see everything that happens in that process and in sufficient detail so that if there’s something that’s going to cause problems, I can design around it,” Dr. Dornfeld tells the AMT meeting attendees. “And of course, that’s all done with software these days.”
With MTConnect, Dr. Dornfeld says manufacturers easily will be able to look at all sorts of information. Examples include the machine tool itself and its performance characteristics, the tool changer, the tooling, the fixture, the cut and its unique parameters like cutting force. “We’ll look at delivery schedules, utilization, lost time to accidents, energy consumed, quality data and sensor data,” he says.
The professor says, with a data communications standard, “MTConnect is the pipe, and we can look through and see the data that’s flowing, and what we do with that information is entirely up to our own imaginations.”
Whole-factory integration via MTConnect is an admitted goal, but there also are short-term benefits to being able to look down the pipeline, according to Dr. Dornfeld. Let’s say your goal is minimizing post-machining deburring operations. By connecting typical islands of automation like spindle dynamics and tool design, you’ll be able to more efficiently work toward a solution.
Someday, if MTConnect becomes widely adopted, all software-connected pieces of factory equipment will have it, but at the start everything is a legacy machine. Therefore, the new steering committee is being careful about writing a standard that is easy to put in place. The group looked at existing IT infrastructure, being concerned about possible barriers, before coming up with a standard nomenclature and ID system. It reviewed related standards and possible interferences. “In the end,” says Mr. Woods, “there’s no reason why MTConnect can’t co-exist with any other software out there, from an SAP system to remote machine diagnostics.”
Early on, the Berkeley group began working closely with the manufacturing research center at Georgia Tech, which has been the driver behind a similar “middleware” standard used by electronics producers. Dr. Armando Fox is the computer science research associate at Berkeley’s Reliable Adaptive Distributed Systems Lab who has been a lead participant in developing MTConnect. Dr. Fox says Georgia Tech’s IPC CAMX (computer-aided manufacturing using XML, developed for the Illinois-based IPC electronics trade association) did for the semiconductor-manufacturing industry what MTConnect is intended to do for metalworking. “By working with them, we’re going to try to avoid skinning our fingers the way they skinned theirs,” he says. “And it means that, right out of the gate, MTConnect equipment will be interoperable with IPC CAMX equipment.”
Dr. Fox notes the old saw, “The great thing about standards is there are so many to choose from. There’s no shortage of previous efforts.
“We do, in fact, have a great many standards today. Unfortunately, many of them are mutually incompatible” or just too unwieldy. Dr. Fox showed AMT meeting attendees a bird’s-nest-looking schematic diagram of Manufacturing Automation Protocol (MAP), which General Motors unveiled circa 1985, but which is not widely deployed today. “I can imagine having someone come up to me and say, ‘We have this protocol that’s going to allow you to interconnect a lot of your equipment. The good news is that the standard embodies everything, from process flow to CAM to quality management and all the way down to how you communicate signals on a wire. The bad news is that it encompasses absolutely everything, from process flow to CAM to quality management and all the way down to how you communicate signals on a wire,’” Dr. Fox says. “‘All you need do is implement it,’ that somebody would tell me. I might run away screaming.”
By contrast, Dr. Fox says having a simple standard like MTConnect reduces the apprehension that an ROI is years down the road, if ever.
MTConnect is designed as a least common denominator around which innovation can occur, without worrying about breaking compatibility on either side. The draft standard as it exists right now is only about 15 pages, about the amount of material that in one afternoon an engineer can read and understand. And implement.
Progress Toward IMTS Roll-Out
If MTConnect is now in the evangelism stage—with staffers contacting other trade associations in the U.S. and abroad getting prospective users interested—its timetable is to continue to move quickly toward full implementation. A so-called v0.9 specification is due in this quarter, which will engender more discussion among the steering committee.
That’s to be followed in the first quarter of 2008 by a series of student competitions—a great source of cheap labor, Dr. Dornfeld quips—to design innovative projects using the protocol. By the second quarter, industrial partners will lock down pilot projects, which will be demonstrated at the Chicago AMT show. At IMTS, the Emerging Technology Center at the entry to the McCormick North building will be entirely focused on MTConnect, as will many demonstrations scattered around the show.
During the IMTS introduction, MTConnect’s proponents hope to convince users to specify the protocol and convince manufacturing technology equipment builders to offer it. “In the course of 6 days, roughly 100,000 people will pass through that show,” notes AMT President John B. Byrd III. “How often do we get the opportunity to talk to that many people?”
The benefits to users are obvious, at least to Mr. Woods. “You’re running a factory and have disparate equipment all over the floor, and you want to be able to figure out how to maximize throughput and know what’s going on each moment. There could be a sensor on a machine, a piece of conveyance, a temperature issue—any piece of information. You may have a great shopfloor management system, but you need data to drive it. Getting info in, with the ability to be shared, is key.”
Likewise, the benefits to suppliers, according to Mr. Woods, are many. “On the other side, I make equipment and services for use in shops. For me, MTConnect creates opportunities. If I had an easy, common way to get data transferred, what kind of neat, innovative products and services could I come up with to sell into that marketplace? I’d spend my software-development time not worrying about how to capture that data, but how to put it to use.”
At the recent AMT meeting, Mr. Byrd summed it up. “This isn’t that difficult. Fear is really the only obstacle to adoption.” And at IMTS, once people see how the protocol works, hopefully that fear will be alleviated.
Joe Jablonowski is editor of Metalworking Insiders’ Report, the Gardner Publications newsletter for executives in the factory equipment business. Visit www.metalworkinginsider.info.