Subscribe to CMM Quarterly
Sponsored Links
Current Issue Headlines
- Automate your Quality Reporting
- ‘Soft Locators’ Simplify Holding Flexible Parts for CMM Inspection
- Tolerance Zone Constraints for Feature Groups and Patterns
- CMM Development Memories of Joe Watson
- Point cloud to CAD comparison in OpenDmis
- New Training Videos Demonstrate Simple CMM Fixture Construction
| Reduce Costs and Increase Quality with Information Exchange Standards for Manufacturing Quality |
| Written by John Horst, NIST |
|
Information Exchange Standards: What value do they bring? Information exchange standards enable common activities: bring a notebook computer anywhere in the world and one will quickly and cheaply find a wireless Internet connection — all due to the presence of globallyadopted WiFi standards. On the other hand, bring many U.S. cell phones overseas and you will spend frustrating amounts of time and money before you can fi nally call your friends and colleagues again — all due to the absence of globally-adopted information standards for cell phones. Like cell phones users, quality professionals suffer from the absence of globally-adopted standards for the exchange of information between software products. Common travails include: These incompatibilities and impediments are accompanied by software translation costs, program rewrite costs, an unnecessary proliferation of hefty software license fees, loss of new technology capabilities, and sizeable integration costs. The cost of translating quality measurement results alone is in the range of $5 Million per year for SPC (Statistical Process Control) N orth American software vendors1. But this is trifl ing compared to costs in the CAD domain. “There are probably about 180 companies in the US alone providing CAD migration [translation] services, representing a market of about $2.3 Billion US, $5.5 Billion worldwide.2” Translation is a completely non-value added cost, since translation is unnecessary wherever there is a globally-adopted standard. Information exchange standards will solve the information incompatibility problem with a modest investment of time, effort, and patience – all without the high costs associated with other approaches. This simple claim about standards is commonly met with concern and honest skepticism: Doesn’t it cost lots of time and money to develop and maintain standards? Isn’t standards development dependent on wide user support for success? What exactly are the approaches to solving the language barrier other than the standards approach? Why do you claim other approaches are inferior to the standards approach? Will information standards hamper vendor competitiveness and technical innovation? Is it hopeless to expect competing interests to agree on a single information exchange language? Will the information standard exclude information not required by a single (powerful) vendor? Will the information standard be incomplete? Will the information standard be developed too slowly? Who will pay to get this work done? These are legitimate concerns, and before we are done, we hope to adequately address each one and persuade the reader of the value of information exchange standards. The incompatibility problem for quality measurement systems
Figure 1: Measurement-related activities are shown in the five different boxes (PMI = Product Manufacturing Information). Example vendor products performing each particular activity surround that activity . Nearly every vendor product reads and writes the same underlying information in a unique format or language. Therefore, without translation, there is no interoperability if passing information to another vendor’s product.
We are not concerned with the standardization of the internal workings of these activities – that is where the
The current market offers a wide variety of product offerings: quality measurement equipment, quality results analysis, measurement process planning, measurement program execution, and product design. A multitude of products are currently available to perform each activity, shown in Figure 1. Each product claims some unique-ness or superiority in the performance of its activity. This provides freedom and choice to users. However, there is a downside to the abundance of product choices – language barriers abound. Each product reads and writes the same information communicated by its competitors, but in its own unique language. Unless neighboring products come from the same vendor, costly translation is required, and translation is completely non-value-added. As if that weren’t enough, translation diminishes information quality. Solving the incompatibility problem End users and tier suppliers have long been aware of the information incompatibility problem. It must be solved. Otherwise, we can’t move our data and still be free to choose any product. But do we have to suffer with endless information incompatibilities? Are we doomed to waste money and suffer quality losses? As end users and tier suppliers experience the incompatibility problem, three solutions have emerged: translation, single-vendor, and standards. Let’s describe each solution and examine the costs and benefi ts of each. When end users do the translation themselves, they generally build translators wherever incompatibility exists. For example, they may possess an older product with an old interface language, neither of which is supported by the product vendor. In such cases, it is common that little or no portion of each individual translation effort is used to resolve other incompatibilities. Not surprisingly, this solution can be very costly and generally lacksforesight. Since the information incompatibility problem has been around for such a long time and since the problem must be solved, the great majority of vendors develops and maintains translators (internal to their products) one for each vendor’s product with which it must communicate. As can be seen from Figure 1, the number of required translators goes up geometrically for each appearance of a new vendor product.
As an example of the single-vendor solution, users may require “native file formats” (i.e., proprietary interface languages) from their suppliers. This provides a “solution” for the end user, but incompatibility is not solved for the supplier, who typically must support several end users, each with different product requirements. Costs borne by the supplier, such as additional training, license fees, and data translation, are simply passed back to the end user, through higher product costs. The end user simply shifts the incompatibility problem on to their tier suppliers, which the end user ends up paying for anyway. The standards solution The standards solution delivers benefi ts only to the extent that those standards are correctly, completely, and unambiguously defined and implemented. Both compliance and interoperability tests are required. Figure 3 illustrates the essential elements to standards success. Benefits of single-vendor and translation solutions End users and tier suppliers need not consult with a standards committee of peers to solve their information incompatibility issues. They can either fix the immediate problem themselves or fix it with the help of a single knowledgeable vendor (the translation solution). They might take a somewhat longer term view and require a network of one vendor per activity corporate-wide or division-wide (the single-vendor solution).
Costs of the translation and single-vendor solutions With the translation solution, each vendor on one side of each interface must “speak” the proprietary language of every other vendor on the other side of the interface, if that vendor expects to service all potential customers, which can be a substantial cost to each vendor. This cost is either passed on to the end user or else borne directly by the end user. For example, metrology process planning software products commonly support as many as ten different native CAD file formats. This support is also a constantly moving target and the cost of such maintenance is substantial, see Figure 4. Commonly, large end users solve the translation problem by requiring that all their tier suppliers “speak” to them via a single native CAD file format. Tier suppliers counter that such a “solution” is costly to them, since they must support a variety of end users, many requiring different native formats. The authors know of an automobile manufacturer that transferred all operations for a particular vehicle model to a different facility. The transfer required use of measurement execution software from a different vendor. All the measurement process plan programs developed at the old location were now completely obsolete at the new location, since the new system required its own proprietary language. Labor-intensive data translation efforts were required, including overtime. The schedule for the transfer of operations to the new location was so aggressive, that the translation work was not completed prior to launch of the new operations. Critical first lots of vehicle parts and assemblies in the new operation escaped the scrutiny of dimensional inspection, leading to degraded product quality and increased in-warranty repairs. Loss in quality Best-in-class constraints The equipment vendor was willing to integrate the new sensor, but the quoted price was equal to buying an entirely new measurement system, including the cost of the sensor. Agility constraints Reduced competition Reduced innovation Increased training and license fees Unnecessary software development This significant software development cost to the vendor is again ultimately passed on to the tier supplier and end user. For instance, it is common for measurement execution software vendors to maintain interface translators for over sixty different dimensional metrology devices.What is more, each of these proprietary languages is constantly changing, requiring each vendor to update their translators frequently. Legacy systems require that translators be maintained for multiple versions of the same product.
Figure 4: Vendor software development costs Proprietary license fees Information access fees Product delay High dependence on vendor viability Benefits of the standards solution If one were to pick a single word to describe the benefi ts of the standards solution it might be “freedom.” The end user and tier supplier are free to choose best-in-class or best-in-value among the full range of technology options, if those product options comply with information exchange standards. They are free to enter into mergers with other corporations who use entirely different vendors for the same measurement activities. They are free to move operations to different facilities without concern for retranslation, loss in quality, and lost time. They are free to make any changes to any system, without concern for any non-value-added cost. They are free to spend resources on things other than unnecessary training, maintenance fees, and license fees. When vendors are standards-compliant and because the end user and tier supplier are able to select freely among all options, a more competitive environment between vendors will emerge, with accompanying lower prices. The end user and tier supplier are free to use the standard anywhere they wish without payment of royalty fees as is so common with non-standards solutions. Another word to describe the benefi ts of the standards option is “innovation.” Standards enable a level playing field for all vendors, and a level playing field enables healthy competition. Lack of healthy competition reduces innovation, since the smaller, innovative vendor is commonly excluded. Therefore, standards enable innovation. The large savings of time, money, and frustration that accompany standards implementation will spur investment in new technologies, trends, and possibilities. Another major advantage of the standards solution is that there are greatly reduced copyright and patent problems than are found with the single-vendor and translation solutions. Once anyone has legally purchased a copy of the standard, they may implement the standard in any number of products without additional cost, such as is found in the single-vendor and translation solutions. Costs of the standards solution Weak end user and tier supplier support End users and tier suppliers must lead and participate in standards development efforts, but equipment and software vendor involvement is also essential for the success of the standards solution, since vendors typically understand the details of the information better than any end user or supplier. Happily, user involvement naturally encourages broad vendor support and participation. Ultimately, end users and tier suppliers must require standards compliance in their corporate purchases. They must promote the standards cause at various public forums, such as quality trade shows, conferences, and trade publications. Copyright and patent risks Slower development and maintenance Deficient standards development Conclusion on costs and benefits There is a small but strong group of end users worldwide who are committed to the standards solution on principle. They see the simple analogy to human communication, knowing that the proliferation of multiple human languages is always costly. Many end users and tier suppliers have committed to the standards solution only after experiencing fi rsthand the high cost of data incompatibilities resulting from the translation or single-vendor solutions: lost time, lost quality, lost agility, and non-value-added training, translation, and licensing fees. End-user leadership is critical to successful standards. However, the level of end user involvement/leadership required is quite minimal. Investments include cybermeetings about once every few weeks, two or three faceto-face meetings a year, and perhaps two extra hours of work per week. Single-vendor and translation solutions have a multitude of high cost items over the long-term, but may provide an integrated solution sooner than the standards approach. Although standards have reduced costs in the long run, there may be delays bringing the standard on-line and maintaining it, since standards require some level of consensus. However, the standards community is attempting to respond to these delays with new standards development models, one of which we discuss in the next section. A new model: accelerated standards development The DMSC, the AIAG Metrology Project Team (MEPT), and the I++ group are all attempting to follow this model. Once a specifi cation shows unique and important value to the worldwide market and is reasonably mature and tested, it is released to an organization like the DMSC, who has manufacturing quality expertise as well as ISO and ANSI accreditation. The standards organization will progress the specifi cation to a formal standard and maintain it. The standardization process is critical, since it ensures input from interested vendors not participating, for whatever reason, in the specifi cation development process. The standardization process is also critical, due to the rigorous rules laid done by groups like ANSI and ISO which ensure high quality standards. The DMSC is an important element of this new model. It is the sole maintainer of DMIS, which is the most widely-used and most successfully implemented measurement information exchange standard worldwide. Most CMM metrology systems read and write in DMIS, albeit at varying level of compliance. Many companies such as John Deere have standardized their entire metrology process using DMIS as the conveyor of information. The DMSC is also the only ANSI-accredited manufacturing quality information exchange standards body worldwide with a fast-track to ISO standardization. How are standards developed? Define, write, implement, and test! Organizations like the DMSC, the AIAG MEPT, the I++ Group, and the IA.CMM are repositories of hundreds of years of metrology experience, both from a vendor and user perspective. They well understand the nature of this information and are well equipped to defi ne it, both correctly and completely. Standards experts from the National Institute of Standards and Technology (NIST) are useful at this phase to help with completeness and correctness through validation tests. …write a computer-readable standard for that information …implement the standard Though not necessary to the success of a standard, it is enormously helpful to implement the standard concurrently as it is being defined. This is will do at least two things, 1) help gauge the support it has from users and vendors and 2) help ensure that the definition of the standard is well grounded in the “real world” from the start. …write and use compliance tests to test implementations Therefore, compliance tests are required that will verify the completeness, correctness, and unambiguity of an implementation. These tests are software applications in themselves and can be used by vendors to verify the level of compliance of their own implementations. An example view of the operation of a web-based compliance test for implementations of the Quality Measurement Data (QMD) specifi cation is shown in Figure 5. This is an excellent role for NIST. Several test suites for different standards have been generated at NIST and are available to the public to verify the compliance of their implementations for various specifications and standards.
An information exchange standard defines the information passing between key activities (design, planning, execution, operation, and analysis) and does not defi ne how those activities are to be accomplished. Furthermore, boundaries do not greatly vary between activities among vendors. Generally, there seems to be an underlying logic to the information boundaries as they have emerged (illustrated in Figure 1 and Figure 2), having to do with the nature of the information. For example, the defi nition of geometry, features, dimensions, and tolerances as an output of the design activity, and input to the process planning activity, is virtually universal across all vendors (notwithstanding the fact that there is an important, ongoing, and serious discussion as to the exact meaning of these items). Neither competitiveness nor innovation are hampered, since there is general commonality about the boundaries between activities, and activities themselves are not part of the standard. Any new information required can be added to the standard in subsequent versions of the standard. Vendors can distinguish themselves largely on how they perform a given manufacturing activity.
Figure 5: An example of a compliance test (generated by NIST) for an implementation of the Quality Measurement Data (QMD) specification. The application is web-based, allowing the simple uploading of a QMD implementation. This example shows an implementation that failed validation. Detailed statistics on the number and types of errors in the implementation help the implementer to quickly bring their implementation into compliance with the QMD specification. Objection 2: “It is hopeless to expect competing interests to agree on a single interface language.” Objection 3: “A group of powerful vendors will create a competing standard or control contents of an existing standard.” Objection 4: “The information standard will be incomplete.” Objection 5: “The information standard will be developed too slowly.” Objection 6: “Several large corporations have embraced the single-vendor solution and continue to be successful in a competitive marketplace.” Objection 7: “No one wants to pay for standards, so working on it is time wasted.” In addition, the U.S. government has shown a sustained and long-term commitment to the standards solution,arguing that standards promote healthy commerce. NIST has been a focal point of resources and expertise dedicated to enabling interface standards for all industries, including manufacturing quality. However, NIST cannot justify resources towards standards unless industry shows its support for standards by joining with organizations like the DMSC and the AIAG and commits the supporting standards efforts with personnel and resources. Who’s working on quality information standards? These corporations are joining with standards-generating bodies such as Automotive Industry Action Group Conclusion
|




















