NO MACHINE IS AN ISLAND

MTConnect? is an open, royalty-free standard intended to foster greater interoperability between controls, devices and software applications by publishing data over networks using the Internet Protocol. Today, individual machine tools make up the backbone of the manufacturing plant. These machines function independently of each other and create an effect much like a collection of production islands. MTConnect is a basic first step in connecting those islands and moving towards the goal of a seamless manufacturing operation from design to production.

By establishing an open and extensible communication standard for interconnectivity between devices, equipment and systems which produce data in different "languages," MTConnect will allow all of these sources to understand each other's data. That common communication using proven Internet communications technology – widely accepted Extensible Markup Language (XML) – will provide managers with near real-time data from throughout a factory, that will empower them to develop more efficient operations, improve production optimization and increase productivity.

With MTConnect, the manufacturing technology industry will mirror the success experienced in the information technology industry, where a common standard is being used to design hardware (such as the USB) and software that enables different manufacturers' products to work with each other.

BEHIND THE SCENES
The increasing integration of information technology (IT) with manufacturing, at all levels of the design and manufacturing process, has already resulted in tremendous efficiency gains–but barely the tip of the iceberg compared to what is possible. Consider:

• ? Data mining and statistical analysis techniques are enjoying a renaissance. Inexpensive computing power makes it practical to analyze large data sets for interesting patterns, as e-commerce giants Amazon and Netflix do when they "recommend" products based on cross-correlating different customers' buying patterns. What measurable parameters of dynamic tool behavior are most highly correlated with premature tool wear? What parameters of a particular machining process are the most robust predictors of tool failure? During what critical points in a milling process would compensation be most helpful in reducing machining errors or manufacturing stresses?

 

• ? Although CAD/CAM processes have become very sophisticated, in many cases there is still a "missing link" between the desired CAM operations and the actual operations, especially when many production lines are involved. Are all of the lines adhering equally closely to the CAM programs? If one line has a different defect rate than the others, what is different about the machine telemetry on that line that might help pinpoint the problem?

 

• ? Existing machines are often augmented with additional sensors or other equipment to improve the quality or rate of telemetry obtainable. Yet as often as not, the software/hardware systems that pull and analyze machine telemetry are not able to integrate such "shop floor customizations" gracefully. And integrating data across different machines in a production line can be difficult or impossible.

 

What these scenarios have in common is the need for a software/hardware platform that facilitates ex-change of information between shop floor equipment, data analysis software, and monitoring systems. MTConnect? is a lightweight, open and extensible protocol and data representation to allow the exchange of dynamic sensor data, configuration data, and control information among MTConnect-compliant machines, software applications and controllers. While MTConnect is not the first attempt to address this problem, it is the first to be designed with all of the following first-class goals in mind, in the interest of wide and rapid adoption by vendors of equipment and software:

• ? Incremental adoption–the technical barrier to MTConnect-enablement of existing equipment is extremely low, and a clear migration path exists for legacy equipment or equipment conforming to other standards.

 

• ? Evolution–MTConnect can incrementally evolve without jeopardizing backwards compatibility of existing equipment or software.

 

• ? Customizability–MTConnect's extensibility makes it easy to create value-added software and tools that are machine-specific or installation-specific, without jeopardizing compatibility with other equipment or software.

 

• ? Non-proprietary—built on open standards, backed by a consortium representing industry leaders, developed with the help of a leading university, and unencumbered by intellectual property restrictions on licensing, every step is being taken to foster the rapid and wide adoption of MTConnect as a standard.

 

MTConnect codifies a portable, low-overhead, easy-to-implement set of standards for communicating local knowledge about machines and sensors, making it easy to create domain-specific, machine-specific, or workflow-specific applications that synthesize and analyze that data without worrying about the mundane (but onerous) details of how the data is gathered from the shop equipment. Creating such applications becomes a high leverage activity because, once created, an application can be easily adapted, refined, retargeted to other equipment, or applied to new equipment without the tedious work of re-coding the communications functionality or data format translation.

By removing the obstacle of dealing with a multitude of transports and data formats, MTConnect will catalyze development of value-added software and functionality in the manufacturing area just as USB did for personal computer peripherals and Bluetooth has done for cell phones and mobile devices.

ARCHITECTURE: PRINCIPALS & MESSAGES
An MTConnect principal is a machine, sensor, or software application that can exchange data using MTConnect protocols and data formats (see Figure 1). Each principal has a globally unique ID (akin to a VIN number for a car) that allows its history to be unambiguously preserved, e.g. an external sensor can be tied to its calibration history as it moves from machine to machine by means of its MTConnect ID. MTConnect's primary messages among principals are as follows [1]:

• ? Naming/Probing: An MTConnect application can send a probe message to discover what principals are in the MTConnect environment–for example, when a new machine is added to the floor, or a new sensor is placed. The MTConnect-enabled device, either directly or through its MTConnect Agent, reports a hierarchical set of data (feed, configuration, etc.) that it is able to report. The hierarchy includes basic information about each data item: Is it an external sensor or a machine? What kinds of sensor data can it provide? With what version of the MTConnect standard does it comply?

 

• ? Read data: request telemetry from a machine or sensor (process parameters, tool parameters, dynamic data, configuration data). Additional options such as sampling frequency can be specified. The application knows what information is available to read from the information in a previous probe mess-sage.

 

• ? Monitor: ongoing monitoring for a particular condition (e.g. "Notify me when the temperature at sensor X exceeds some threshold") or on a regular basis for routine measurements (e.g. "Report the speed of spindle Z once per second until I request otherwise")

 

All MTConnect–compliant principals are required to recognize these primary message types, but MTConnect provides a well-defined way for a principal to respond "I can't comply with that message." For example, a simple sensor may only be capable of continuous data reporting, rather than notification-based monitoring.

DATA FORMATS: XML FOR INCREMENTAL EVOLUTION
MTConnect messages are encoded using XML (eXtensible Markup Language). XML is a streamlined descendant of SGML (Standard Generalized Markup Language), which was used for decades as a portable way of specifying data interchange formats. A machine-readable XML schema defines the format of MTConnect messages and the data items within those messages. Each data item has four properties:

1. The name indicates what kind of entity is supplying the data; e.g., a spindle. The MTConnect specification delineates the minimum set of names that any MTConnect-compliant principal must recognize.

2. The value is the information being reported; e.g., RPM in the case of a spindle, or an "open/closed" indication in the case of a machine door.

3. Optional attributes specify extra properties about the item that may or may not be of interest to the principal receiving the message; for example, the tool's manufacturer ID or part number.

4. XML representations are hierarchical, allowing related items to be grouped together. For example, a spindle will also report load and rotational velocity; all relevant data for a spindle can be retrieved by a single command, rather than having specifying each item separately.

This "self-describing" structure of each data item allows a principal to safely skip over data items whose names are not meaningful to it–for example, a general monitoring application might ignore some work-flow-specific telemetry, whereas a workflow-specific analysis might consume sensor readings that are not of interest to most other applications. The MTConnect specification will delineate a minimal "universal" set of items whose names must be recognized by any MTConnect-compliant principal, in order to guarantee a baseline level of inter-operability.

IMPLEMENTATION: ENABLING EQUIPMENT FOR MTCONNECT
When a new protocol or standard is proposed, by definition all equipment is initially "legacy equipment" with respect to that protocol. That's why MTC makes incremental deployment a first-class concern. The MTConnect Agent software features a plug-in architecture that allows hardware/software adapters to be developed to communicate with non-MTConnect-compliant equipment.

The hardware part of the plug-in includes any hardware needed to retrieve telemetry data from the machine or sensor, such as a wireless transceiver or proprietary cabling, and make the data accessible to a PC-class computer. The software part of the plug-in translates between proprietary and MTConnect data formats, making it available in response to MTConnect messages from other principals. From the point of view of the MTConnect environment, the legacy machine "fronted" by the MTConnect Agent appears to be an MTConnect principal.

MAKING TOMORROW'S EQUIPMENT READY "OUT OF THE BOX"
Through its use of open standards for protocols and data formats, MTConnect is designed to be easy to integrate directly into the design of controllers. MTConnect can run over any type of transport (communication protocol) that provides a reliable ordered stream of bytes. Because MTConnect's specifications and reference implementations are themselves open as well as being built on open standards, and because the functionality required for minimal MTConnect compliance is modest, manufacturers and integrators will be encouraged to design MTConnect into their controllers.

MTCONNECT AND OTHER COMMUNICATION PROTOCOLS/STANDARDS
Other important standards efforts, including IPC-CAMX, OPC-UA, and STEP (ISO 10303), are taking a comprehensive view of the problem of enabling communication among "smart machines." Relative to these standards, MTConnect serves two important roles:

• ? MTConnect provides a "lingua franca" that facilitates baseline communication among principals by standardizing a simple, lightweight message protocol and data format. Therefore MTConnect can serve as an incremental step along the migration path toward full compliance with higher-level standards such as STEP.

 

• ? MTConnect provides a lightweight alternative for enabling simpler inter-machine applications that may not require the full power of more comprehensive specifications. MTConnect is designed to be quick and easy to retrofit to existing equipment, and should later circumstances indicate that a move toward full compliance with a more comprehensive standard is desired, MTConnect compliance can then serve as a building block for that effort.

 

By way of analogy, imagine that we have at our disposal a team of the world's most talented engineers, architects and construction contractors. Their job is to collaborate on a complex construction project. But they come from different countries, speak different languages, use different terminology to mean similar things, and are accustomed to different social and professional interaction norms. In this scenario, a first step would involve teaching all of them a simple language that would put them on common ground and allow them to communicate about basic concepts, thereby allowing them to educate each other about their differences. For some, having this common language may be enough to allow them to form a sub-group and do useful work; for others, having this common language is simply a first step toward discussing and agreeing on a project plan. MTConnect serves the role of this common language: by enabling basic communication, it allows immediate progress to be made on simple problems (one-off applications and installation-specific scenarios), and provides a foundation for tackling more complex problems (com-pliance with comprehensive standards such as those being codified by ISO 10303).

AMT has made available, via its MTConnect.org website, open-source reference implementations of code modules that can be used to construct MTConnect adapters, including the MTConnect Agent software and all software used in the IMTS '08 demo and example applications (sensor analysis, configuration discovery, workflow visualization, etc.) compatible with any MTConnect-enabled environment. It will also make available the design documents, draft specifications, and other technical details of MTConnect free of charge.

UNENCUMBERED ROYALTY-FREE LICENSING TERMS
All documentation, specifications, source code, and prototypes developed for MTConnect are made freely available via the MTConnect website under a liberal non-exclusive, royalty-free license agreement [2]. Parties will be free to use, modify, improve or redistribute these artifacts on any terms they wish, or incorporate them into commercial products, without the need of royalty payment. The MTConnect Consortium will publish detailed specifications that will allow a product to carry the "MTConnect? Compliant" certification and use the MTConnect name and logo.

BUILDING ON ESTABLISHED OPEN STANDARDS
Wherever possible, MTConnect leverages existing, widely-deployed, open protocols and standards. This reduces barriers to adoption in three ways:

• ? Existing IT infrastructures do not need to be modified: most are already set up to accommodate the standards on which MTConnect builds.

 

• ? Open standards protect adopters from being locked into proprietary tools and software as their needs evolve.

 

• ? A "knowledge ecology" of high-quality tools, documentation, and (most importantly) trained programmers and technicians has evolved around successful open standards.

 

The reference implementation of MTConnect will transmit data using the globally-deployed HTTP protocol over TCP/IP, using SSL for secure connections and DNS for naming and uniquely identifying machines and sensors. An XML-based data representation will encapsulate the data transmitted among MTConnect principals.

FREQUENTLY ASKED QUESTIONS
Does MTConnect compliance require me to reveal proprietary design information?
No. For example, consider a proprietary real-time spindle compensation mechanism that results in lower operating temperatures and longer tool life. In this scenario, the tool might export actual spindle operating parameters via MTConnect, without revealing the internal state of the controller implementing the proprietary compensation algorithm. The compensator's effect would be visible in the form of more favorable operating parameters being reported by MTConnect, but the details of the algorithm's operation would remain proprietary.

Similarly, consider a proprietary design improvement that allows real-time behavior data about a tool to be gathered inexpensively and reported via MTConnect. Again, the hardware and software details of just how this is done–i.e., the proprietary differentiator–would not be revealed; MTConnect would be used only to provide the behavior data itself, where other vendor's competing tools would not be able to pro-vide that data at all.

Why not specify data types, machine parts, etc. in more detail? Why not make the "universal data dictionary" as large as possible?

To paraphrase William Strunk, "the perfect spec has been achieved not when nothing further can be added, but when nothing more can be taken out [3]." A small, simple spec is easy to understand, lightweight to adopt, and fosters rapid innovation. The key to MTConnect is specifying enough of a framework that it remains possible to define desired additional features and behaviors in terms of what the framework provides. The selection of universal components and the collection of abstractions provided by MTConnect are key to this, which is why those areas are receiving careful attention from a respected group of manufacturing industry representatives as well as software and protocol architects.

Domain-specific standards such as IPC-CAMX and overarching standards such as OPC-UA have made progress in defining ontologies. Will MTConnect leverage any of this?
We are in consultation with standards-committee representatives and architects of IPC-CAMX, OPC-UA, STEP, and other standards to make sure that the best ideas from those efforts are included in MTConnect (and that the unexpected pitfalls from those efforts are avoided).

Why does MTConnect deal with "low level" telemetry when the information I really care about is "high level" information, such as whether a machine can accept a new workpiece?
Consider a machine equipped with a door that opens when the machine is ready to accept a new work-piece. A sensor can detect whether the door is open or closed; the value of that sensor is the kind of local data with which MTConnect is concerned. It's tempting to conclude that MTConnect should allow ex-pressing the concept "Ready to accept new workpiece," but that concept is really a global condition whose precise definition depends heavily on the specific scenario.

For example, are machines downstream of this one backing up? Is the upstream machine finished working on the piece? Are there external error or halt conditions that should result in the temporary suspension of work? The "ready" condition really depends on each installation. For that reason, MTConnect's goal is to provide the least-obtrusive path to obtaining local datain a standardized way, thereby making it easy to synthesize that data into domain-specific, machine-specific, or workflow-specific analyses.

Why doesn't MTConnect model workflows or provide a framework for overall control of a workflow?
It's tempting to try to specify such scenarios in the basic protocol, but the goal of the basic protocol is to guarantee the communication necessary to answer such questions. Like laying the foundation for a building, these basic elements will rapidly enable addressing higher-level questions; in other words, by removing technical obstacles to creating technology that deals with higher-level scenarios, more engineers will be free to focus on those tasks rather than worrying about the minutiae of communication.

Furthermore, overspecifying the basic level protocol risks "bloating" the spec and making it onerous to adopt, since any given "high level" scenarios are not universally applicable to all machines. As the Web has shown, the ubiquitous availability of relatively simple protocols for communication (HTTP, SSL) and data representation (HTML, XHTML) makes it easy to evolve higher-level protocols and sophisticated applications to solve specific problems.

Does MTConnect include a notion of "work sessions"?
XML-encoded documents allow the use of REST (Representational State Transfer) semantics to synthesize sessions if needed. Not all scenarios will require session management, but for those that do, a combination of REST techniques and reconstruction of sessions from audit logs can be used to synthesize sessions. Keeping the basic protocol stateless tremendously simplifies its implementation; indeed, we are emulating the success of HTTP, itself a stateless protocol onto which mechanisms for session-state management (e.g. cookies) were added later as an optional element.

Why an ASCII based transport protocol and XML encoding, rather than more compact binary protocols?
Historically, ASCII protocols have always trumped binary because they are simple to program, portable across platforms, resilient to technology changes, and human readable during debugging. Off-the-shelf libraries allow compression and tokenization of XML with size reductions up to 70 percent; combined with Moore's Law, this makes ASCII-based protocols easily "affordable," and the perceived advantages of binary protocols are more than offset by increased programmer efficiency, leading to more agile adaptation to changing environments and faster turnaround time.

Why the emphasis on an extensible data representation?
No protocol in history has "gotten it 100 percent right" the first time. Hence it's essential to design for back-wards-compatible evolution that will occur after the protocol is fielded. HTTP graphically illustrates the success of this approach: after millions of deployed servers were running version 1.0, a slew of important engineering features was proposed and tried out on subsets of servers (all without breaking backwards compatibility), and ultimately the features deemed most valuable were codified in version 1.1 of the proto-col. The backwards-compatibility afforded by an extensible protocol then allowed existing servers to in-corporate the new features over a period of time, rather than requiring a "flag day" on which all servers were required to change over or stop working.

With open standards, how can manufacturers differentiate their products?
Open standards actually help, rather than hinder, value-added differentiation. With open standards for communication and data representation, differentiation can take the form of value-added data analysis, monitoring, aggregation, visualization, and workflow-specific intelligent control applications. Furthermore, by not having to worry about the details of communication with a variety of equipment, the development effort and time-to-market of such differentiated products are greatly reduced.

Is MTConnect secure?
Within the scope of a single administrative domain such as a shop floor, existing Internet techniques such as a firewall/DMZ (demilitarized zone) architecture can be used to protect the intranet from outside observation or probing. Standard encryption and identification protocols, such as SSL combined with certificates and/or password-based authentication, can be used to provide a limited, controlled level of access from offsite (e.g. for performing offsite monitoring of an installation). These architectures and protocols are in successful production use at millions of commercial e-commerce installations.

Is MTConnect fault-tolerant? Does it provide for redundancy in the case of failure of a principal or software agent? Does MTConnect allow auditing of operations and messages?
The basic protocol itself does not specify these capabilities, because they can be deployed in a manner that is orthogonal to the basic protocol and because no single redundancy scheme or auditing methodology is appropriate for all scenarios. Consistent with the well-established end-to-end argument in network design, we expect that additional tools building on MTConnect's basic protocol will evolve to provide a variety of solutions to these problems appropriate for different environments.

Will my engineers/developers have to learn new languages or protocols in order to make use of MTConnect?
No. Reference implementations of artifacts will be provided that make it easy to get machine tool data via MTConnect and very easily pull that data into tools such as Microsoft Excel?, Visual Basic?, relational databases such as SQLServer? and MySQL?, etc. The goal is to allow developers to use the tools and languages they already know to automate data collection and analysis.

How is MTConnect different from previous efforts to provide data communication between different types of manufacturing equipment?
MTConnect is not a proprietary piece of hardware or special-purpose software to link machines and systems together. It is an open, royalty-free communication standard using proven Internet communications technology. The standard is designed to enable engineers and designers to extend the types of data to be transferred to enhance their product offerings. Example software also has been developed to test the soundness of the standard. That software can be downloaded from the MTConnect.org web site and used as-is, modified for special needs, reverse-engineered, or used as a template to create one's own software interface that meets the requirements of the standard.

By using this open, extensible, non-proprietary approach, MTConnect will allow connectivity from the lowest end of the process chain – nearest the workpiece or shop floor – to the highest design or process planning tool. It is expected that MTConnect will enable any third-party solution provider to develop software and hardware to make the entire manufacturing enterprise more productive.

When will the MTConnect standard be completed?
MTConnect Version 1.0 is in the review stage by the MTConnect Technical Advisory Group (MTCTAG). Following this review the standard will be voted on by the MTCTAG for adoption as an Open Standard. It is estimated that this will occur in the 4th quarter of this year.

Who is participating in the MTConnect Project?
AMT-The Association For Manufacturing Technology began working in 2007 with the University of California at Berkeley, the Georgia Institute of Technology and several manufacturing technology companies, with seed money provided by AMT.

MTConnect currently is governed by the MTCTAG, whose voting members are:

 

Additionally, more than 20 other companies are actively involved in the development of MTConnect. The full list is at http://mtconnect.org/index.php?option=com_content&task=view&id=96&Itemid=120.

Who can be a member of MTConnect?
Any company or organization in the world can be a member, participant, or contributor to the further development and application of the MTConnect open standard. Those who wish to participate in committee work or be a member of the MTCTAG must agree to the MTConnect Intellectual Property Policy that can be found on www.mtconnect.org in the Agreements and Policy section of "About MTConnect."

Anyone who wants to be a contributor throughout the process of review, comments, or testing of the standard can sign onto the web site and agree to the "Public Comment and Evaluation License," then download any MTConnect material provided. By signing onto the website, one automatically receives the MTConnect Newsletter that outlines the standard's progress.

Are universities getting involved?
Yes. In addition to UC/Berkeley and Georgia Tech, several universities from both inside and outside the U.S. participated via the first MTConnect Student Competition. Seven submitted pre-proposals and four full submissions were provided:

 

What are the next steps?

 

Who is the contact for additional information?
Paul Warndorf, Vice President – Technology, AMT, pwarndorf@amtonline.org, (703) 827-5291

Paul Warndorf is the Vice President of Technology at AMT – The Association For Manufacturing Technology, 7901 Westpark Drive, McLean, VA  22102-4206, 703-827-5291, Fax: 703-893-1151, pwarndorf@amtonline.org, www.amtonline.org.

Armando Fox works in the Computer Science Division of UC Berkeley, 387 Soda Hall, Berkeley, CA 94720-1776, 510-642-1042, Fax: 510-642-5775, www.cs.berkeley.edu.

Will Sobel is the founder of consulting firm Artisanal Software LLC, www.artisanalsoftwarellc.com.