Understanding Interoperability and the DMIS Experience
September 29, 2009
Because they enable true interoperability, information exchange standards such as the Dimensional Measuring Interface Standard (DMIS) can help manufacturers significantly reduce cost and improve product quality-but only if the standards are sufficiently supported and correctly developed. Some key manufacturers have embraced this claim and require standards-compliant software throughout their enterprise, but such manufacturers are in the minority.
A manufacturing information exchange standard precisely defines the information passed between the following manufacturing activities: design, planning, execution and analysis.
Furthermore, all standards are, by definition, non-vendor-specific and non-proprietary. Standards ensure fair and open development of the standard, free use of the standard in commercial products and legal safeguards relating to copyrights and patents.
Design, planning, execution and analysis are performed by all manufacturers and, surprisingly, the same information content emerges out of each activity to a large degree, no matter which vendor produced the software. For example, product information always includes part geometry, features and tolerances. Process results always include measured feature dimensions.
It is all the same underlying information at each interface; traditionally, however, without information exchange standards, each software vendor communicates (reads and writes) this same underlying information in its own proprietary language, making it an experience where no one understands the other because no one is speaking the same language.
As a result, there is no interoperability unless a single vendor’s language is mandated enterprisewide, a translator is written and used, or a single standard is mandated throughout an enterprise. An information exchange standard is the only option that enables true interoperability.
True Interoperability and Illusory InteroperabilityMany manufacturers currently believe that interoperability is attained by enforcing a single-vendor product line throughout the enterprise. A certain degree of intra-operability is hereby attained, but at what cost?
In the early days of technology, islands of automation caused language incompatibility nightmares. In a flurry born of urgency and ignorance, many manufacturers responded to the nightmare by requiring use of a single vendor’s product line throughout the entire enterprise for each manufacturing activity. For example, an automotive design system manager recently proclaimed, “interoperability is not translation; interoperability is native formats,” which means, “if tier suppliers want to win our contracts, they must send us design data in the native format of a single CAD vendor’s product.”
Unfortunately, this approach just pushes the interoperability problem down to the tier supplier, who often must support many end-user companies, each with different single-vendor requirements, and the supplier must pay the multiple software maintenance fees, purchase and maintain format translation, pay for additional training and manually fix (or suffer from) translation errors. So, the interoperability gained is largely an illusion.
Corporate mergers can bring the problem home with a vengeance. For example, a major manufacturer recently installed single product lifecycle management (PLM) software throughout its manufacturing enterprise. All was well until the company acquired two large corporations.
The PLM products at the other two companies were from a different vendor, and because the PLM products either did not comply with existing standards-or such standards do not exist-and no quality translators existed, there was no interoperability. Because of the urgency of the problem, the PLM systems manager chose another PLM product and installed it enterprisewide. He is now three years into the task and it is still incomplete. No one has quantified the cost, but given the three years of consistent effort, it is surely substantial.
Finally, single vendor requirements restrict freedom of product choice and increase price structures for software maintenance, due to lack of competition from other vendors. This solution is common among some large companies, which cannot mandate a single vendor enterprisewide.
There are at least two problems with the translator solution: translation is costly and some data quality is always lost in the translation. Furthermore, translators constantly must be maintained as new software versions arise. Therefore, the translator solution also creates illusory interoperability.
A standard information exchange language, such as DMIS, is created by domain experts within a standards-generating organization. A critical mass of vendors worldwide implement the standard in their software product offerings, meaning that the vendor software encodes and decodes in the language, and end user corporate purchasing requires standard-certified products. The certification is based on conformance tests.
The standards solution reduces the cost of proprietary solutions because translation costs are eliminated or minimized, there is immunity to acquisitions, freedom of product choice and reduction of data errors due to things such as semantic misinterpretations during translation.
Because both the translator and the single-vendor solutions to interoperability are illusory, the only other option for interoperability is the standards solution. Since standards can minimize or eliminate the costs of proprietary solutions, true interoperability is only achieved with information exchange standards.
The ROI of Information Exchange StandardsThe return on the use of standards is simply that the costs of interoperability failures are saved, but what are these costs?
Accurate quantitative estimates on the cost of non-standards-based solutions to the interoperability problem are hard to gather. Nonetheless, some attempts have been made.
A recent estimate made by the National Institute of Standards and Technology (NIST) on quality measurement results data is an accurate estimate, although it is not exhaustive: Quality measurement data format translation costs statistical process control (SPC) software suppliers worldwide roughly $5 million per year. The estimate does not include quality measurement data format translation costs from the end users and their tier suppliers, which could be substantial.
On the design side, costs get substantially higher. NIST reported in 1999 a $1 billion annual cost for design data exchange problems in the U.S. automotive supply chain alone.
PitfallsIf there is one pitfall above all for reaping benefits from interface language standards, it is when the customers of quality measurement software do not demand standards-compliant products in their purchasing.
Information exchange incompatibilities are costly to everyone: vendors, suppliers, end users and customers. Costs include translation costs, unnecessary training costs, high product costs, data quality losses and constrained freedom of choice. The information exchange standards mandate is the best solution to information incompatibilities because standards have none of the non-value-added costs of the single vendor mandate.
Now that information exchange standards have been discussed thoroughly, let’s get into specifics about DMIS, specifically for coordinate measuring machine (CMM) operators.
What is DMIS?DMIS is an information exchange standard published with the International Organization for Standardization (ISO). DMIS defines measurement process plan information for CMMs. Because DMIS is both human readable and computer readable (such as C++ or Java), it can be called a programming language for CMMs. DMIS is a language, which means that software implementing DMIS must be able to encode DMIS or decode DMIS. Like any information exchange standard, this standard is intended to enable interoperability by allowing the use of DMIS programs, without alteration, on many types and brands of CMMs.
DMIS is written to control many types of CMMs, including computer numerically controlled (CNC), manual, classic touch-trigger, touch scanned, noncontact scanned, five-axis scanned and CMMs with rotary tables. Portable CMMs are typically not addressed by DMIS, including articulated-arm CMMs, laser trackers, white-light scanners, theodolites and robotic CMMs.
Because DMIS is so large and there are so many different functional applications, such as prismatic and thin walled, DMIS developers have defined conformance classes, which are essential for interoperability.
There are two common uses for DMIS:
Dimensional measurement planning software presents the metrologist with a 3-D computer-aided-design (CAD) model of the part to be measured and provides software tools to choose which features are to be measured and how they are to be measured-including specification of sensor types, sensor paths and distribution of points. The automatic output of the software is a measurement program encoded in DMIS.
The metrologist writes a DMIS program by hand and may debug it using a simulator.
In both scenarios, the measurement execution software then decodes the DMIS program and executes it on a CMM.
True Interoperability?The DMIS effort has only provided true interoperability for a minority of users and vendors, even though a majority of CMM software vendors have DMIS implementations of some sort. This less-than-ideal situation does not appear to be because DMIS is lacking in completeness or correctness. The culprit appears to be that, until recently, there has been no definition of conformance classes, conformance tests or a certification program, which is essential to interoperability.
With these now in place, end users can require DMIS-certified software enterprisewide and be ensured of noticeable savings as a result. It is hoped that this will increasingly happen, but only if a critical mass of end users require it, which is not yet the case.
Is DMIS actually better than proprietary approaches? Yes, because no vendor can mandate a fee for using or certifying ISO DMIS in another vendor’s software; and no translation is needed as long as most vendors sell DMIS-certified implementations and most end users require them. At a DMIS-only shop, a CMM operator need only learn the DMIS programming language to program a variety of CMMs, which saves money on software training and provides the metrologists freedom to choose from several DMIS-compliant vendors.
Currently, the level of DMIS compliance varies, mostly because certification has not been required by large end users. High-level quality managers and purchasers need to see the monetary and technical value of DMIS-compliant software.
DMIS and TechnologyWhen touch scanning hit the CMM market several years ago, DMIS was posed with a substantial challenge. The now disbanded European DMIS users group almost single-handedly developed appropriate additions to DMIS addressing scanning.
When five-axis scanning entered the market around two years ago, DMIS responded in a timely manner with a new version, DMIS 5.2, which recently has been approved as a national standard by the American National Standards Institute (ANSI).
DMSC's RoleThe Consortium for Advanced Manufacturing, International (CAM-I), along with its industry partners, started DMIS. About five years ago, CAM-I dropped its support for the DMIS effort. The Dimensional Metrology Standards Consortium (DMSC) was quickly formed thereafter as a separate non-profit standards organization to generate and maintain DMIS and other quality measurement standards for manufacturing.
End-user organizations, such as Honeywell, Lockheed Martin, Chrysler and John Deere belong to the DMSC as well as CMM software vendors, such as Siemens, Wenzel-Xspect Solutions, Renishaw and Hexagon. Anyone who participates in the DMIS standards committee of the DMSC has input into future ISO DMIS standards.
What Role Does NIST Play?This concept of compliance to a standard through conformance tests and certification procedures is at the heart of what NIST does. NIST is writing the conformance tests for each conformance class, starting with the most common first.
A new certification program for DMIS, based on DMIS conformance tests, was launched by the DMSC at the IMTS 2008 show; there are currently three vendors that have applied for certification.
With these programs in place, it is hoped that test and inspection professionals will begin requiring their equipment to be DMIS compliant-saving them time and money in the future. Q
Editor’s Note: To learn more about DMIS, listen to Quality’s Q-Cast podcast interview with John Horst of NIST at www.qualitymag.com.