| by Dirk Dusharme
The much-maligned Bill Gates
had it right. It's all about the software. While Big Blue
placed its bet on hardware, Gates and company laid the foundation
for computing software that eventually transformed the information
world as we know it. Understanding what Apple did not, Microsoft
ensured that anybody could easily get into and out of its
operating systems, an open architecture that freely let
any kitchen-table programmer write applications that could
tie into Microsoft's operating systems and have access to
any other hardware or software running under that system.
This kind of accessibility so pervades our culture that
industries seemingly far removed from information technology
expect and increasingly demand plug-and-play compatibility.
Even in the relatively small market of dimensional measuring
equipment software (in particular, the software used to
control, collect and analyze data from coordinate measuring
machines), customers are pushing hard for open standards
that allow PC-like plug-and-play compatibility.
For the past 20 years CMM customers --largely in the automotive
and aerospace industries --have been pushing for an open
standard --software, hardware or both --that would allow
different brands of CMMs and CMM software to share data.
Although seemingly good for the customers, this type of
compatibility makes CMM producers cringe even while they
give in to customer demand. At stake is competitive edge
and, as one CMM manufacturer put it, fear of "the commoditization
of CMMs."
It isn't always easy or even possible to make a measurement
routine written for one brand of CMM work exactly the same
way, or at all, on a different CMM using different software.
As more companies look to upgrade their existing CMMs
with new software or controllers, or to move or outsource
their inspection, system compatibility becomes a big problem.
The Metrology Automation Association estimates that compatibility
issues cost users more than $1 billion annually.
To understand this, consider just one of the costs of
outsourcing dimensional measurement: Even if a client has
already written its own CMM part inspection program, an
inspection service usually must rewrite the programs to
run on its own software and equipment, at a cost of about
$85 per hour, says Larry McInerny, programmer and inspector
for QC Inspection Services in Burnsville, Minnesota. Depending
upon the number of measurements, one part can take from
one to 40 hours to program, says McInerny. Even when inspection
stays in-house, changing software or CMM hardware can mean
thousands of hours of reprogramming and debugging for hundreds
of parts.
Although harder to quantify, compatibility issues hurt
CMM manufacturers as well. As CMM software functionality
increases --such as enhanced user interfaces and the ability
to directly read CAD files and compare CAD data to measurement
data --so does the user's reluctance to switch software.
In many cases, a fortune has been spent on programming and
training. In other cases, a specific software package is
required companywide (e.g., Volkswagen just signed a contract
with Metrologic Group that makes the French software company's
Metrolog II the standard metrology software for the German
automaker). If a CMM manufacturer doesn't support the software,
it may lose a sale --not a good thing, particularly at a
time when the MAA reports that CMM manufacturers have sustained
at least two straight quarters of losses, and CMM company
mergers and acquisitions are almost a quarterly event.
So what's the big deal? Why is a common CMM interface
so difficult to accomplish?From the manufacturer's point
of view, a common interface solution based on an open standard
leans toward a lowest-common-denominator interface that
diminishes a manufacturer's competitiveness. Back in the
1960s, at the dawn of CMM computer automation, each CMM
manufacturer developed its own CMM control and measurement
hardware and software. As the products evolved, manufacturers
built features into the hardware and software that gave
a CMM its particular edge over the competition. These edges
are important in a relatively small market.
Brown & Sharpe estimates that there are only about
100,000 CMMs of all brands in the field worldwide. By making
your product accessible via an open standard, "you
can work yourself out of business," says Dave Genest,
marketing director for Brown and Sharpe. "If the customer
says it would like to have an open architecture choice,
you have to change your product to be open architecture.
But, if everyone has an open architecture, we all start
to look the same and we lose a marketing advantage."
To protect that advantage, manufacturers take steps to
hide key features from any software but their own, say many
software producers. "Today most CMM controllers are
almost the same, but each may have it's own advantages,"
says Bertrand Gilli, president of Metrologic Group, which
produces both CMM software and controllers. "If CMM
makers want to have an advantage, they won't make available
the commands that take advantage of these enhancements."
Additionally, manufacturers like Brown & Sharpe don't
want to lose business to aftermarket retrofitters. The 100,000
CMMs in the field are made largely of granite and steel
and will last until the sun goes out. Rather than buy new
CMMs, existing users choose to upgrade the electronics and
software. Manufacturers want to make sure that existing
owners come back to them and not a competitor for upgrades.
Open standards make it easier for existing customers to
go elsewhere.
Finally, jumping through hoops just to meet the needs
of a few customers doesn't make good business sense, says
Bill Fetter, CMM marketing manager for Sheffield Automation
LLC. "The real issue is that this industry isn't big
enough," explains Fetter. "For every CMM that
the CMM industry sells,
the machine tool industry sells 20. The CMM industry doesn't
have the volume. You have customers trying to drive the
behavior of the manufacturers. But the manufacturers realize
that they're only going to make two of these things. This
is a real frustration."
The first concerted effort at standardizing data-sharing
among CMM software came about in the 1980s. Aerospace and
automotive industry leaders wanted a common language that
would give them the ability to read data directly from a
CAD package and create or perform a measurement routine
on one brand of measurement software and have it work on
another brand. In fact, in 1983, at a meeting of 100 quality
professionals at the Consortium for Advanced Manufacturing
International, the need for a common interface among inspection
equipment topped the list of key issues facing quality professionals,
according to Bailey Squire, CAM-I's director of standards.
Several years later, the Dimensional Measuring Interface
Standard emerged from CAM-I.
Because CMM manufacturers were anxious to align themselves
with Ford Motor Co. and the other large manufacturers behind
DMIS, they did their best to implement it, says Curtis Brown,
chairman of the DMIS standards committee. The results weren't
outstanding.
"One application could spit something out in DMIS
format, and another could suck it in," says Brown.
"[But], DMIS obviously didn't contain all the capabilities
that people needed. CMM companies adhered as best they could."
The problem was that, although set up to do so, the DMIS
committee couldn't quickly accommodate changes to the standard.
CMM-specific commands, the commands that gave a CMM its
edge, took too long to get reviewed and entered into the
DMIS specification. This and the lack of enforcement to
the standard led CMM vendors to release their own flavors
of DMIS. Each DMIS version supported that particular manufacturer's
specific commands.
DMIS quickly devolved into a nonstandard. What was left
was better than before but fell short of what was needed
or intended.
To address the issue of a weakened standard, the recent
DMIS 4.0 release provides a general description of what
it means to conform to the standard and provides several
levels of conformance, says Squire.
Despite its shortcomings, DMIS is still the only game
in town for CMM application-to-application compatibility.
For in-house dimensional measurement, compatibility between
different software applications probably isn't as serious
an issue as the ability of a software title to communicate
with different brands or models of CMMs. As both OEMs and
third-party CMM software producers add functionality to
their software, it becomes more important to the end user.
In a sense, CMM hardware has almost become a commodity,
a peripheral device, a very expensive data gatherer. Except
in special cases, the user's choice is less, "What
can the CMM do?" and more, "What can the software
do?" It's for this reason that we see CMM manufacturers
partnering with third-party software producers. The writing
is on the wall: Customers have begun to gravitate toward
the application rather than the equipment and at times,
as with Volkswagen, specify the software and not the machine.
Should a company want to upgrade its CMM or purchase a
new CMM, the inability of its existing software to communicate
with a different CMM or CMM retrofit puts the company in
a bind. The options are to reprogram inspection routines
using the other CMM's software (expensive and time-consuming),
retrofit the other CMM with electronics that the current
software supports (very expensive and not a wise move say
some CMM manufacturers), or export test routines from the
current software, import them into the other software and
hope that the translation is accurate. DMIS was supposed
to allow this type of export/import functionality but because
of the flavored-DMIS problem, the translation is often buggy.
To address the machine compatibility issue, most OEM and
third-party software producers include drivers for the most
popular brands of CMMs. Some manufacturers provide these
drivers to software producers on demand. Others do not,
or only provide the drivers to particular software companies.
When they don't have access to controller-driver specifications,
CMM software producers are left with two choices:
Partnerships. The software manufacturer signs a partnership
agreement with the CMM manufacturer. The manufacturer agrees
to share all information necessary to allow the software
company to write the communication portion of its software
so that it can control that company's devices. The advantage
is that hardware/software communication issues are addressed
during development and with both parties participating in
problem solving. This likely means a more stable and integrated
interface. It also means that both parties have better access
to each other's clients.
Reverse engineering. When a software company doesn't have
access to driver information it can still reverse engineer
the CMM's communication protocol. The advantage is that
this can be done with any controller without the consent
of the manufacturer. The downside is obvious: If a problem
occurs, to whom does the user turn, the CMM manufacturer
or the software producer?
The ideal solution to communicating with all CMMs would
be some sort of common equipment interface --the Holy Grail
of dimensional measurement equipment. A common interface
would be the standardized method for communicating to any
CMM controller. All software would speak the same language
when talking to the interface. Rather than the burden being
on the software to understand how to communicate to all
controllers, each manufacturer's controller would understand
the common interface language. All controllers would have
to support this standard.
In 2001, a European consortium of automakers (Volvo, DaimlerChrysler,
Volkswagen, Audi and BMW) formed I++ and fast-tracked a
common machine interface called I++ DME.
Utilizing a small team relatively unhampered by bureaucracy,
I++ outlined, spearheaded and delivered a standard in less
than two years.
From the user's standpoint, I++ DME provides a common
machine interface that, when used with I++ DME-compliant
CMMs, ensures that all CMMs behave the same way with any
I++ DME-compliant software.
From the manufacturers' viewpoint, an advantage with I++
DME is that it allows the manufacturer to hide sensitive
information while still giving users full access to special
features.
As with DMIS, the sheer force of the European automakers
has ensured that CMM manufacturers begin implementing the
I++ standard, again, grudgingly, though maybe a little less
so.
Manufacturers acknowledge that the force behind I++ (read,
customers) is much larger than that of DMIS.
"I think I++ is a necessary evil," says Genest.
"The European automakers have decided that they want
to buy CMMs like you buy printers. You buy a printer, a
computer, some software and you put it together. The advantage
is you aren't limited by any manufacturer's weakness.
"The disadvantage is the whole thing may not work.
Who takes responsibility for making the whole system work?
Currently, the CMM manufacturer takes responsibility. [Open
standards] may put the pressure back on the customer."
In order to meet the needs of users, software companies
and measurement equipment manufacturers, the I++ DME interface
will have the following characteristics, according to release
1.3 of the standard:
State-of-the-art technology that remains useable in older
systems
Scalability
Extendibility. It will be possible to add new types of machines.
The complexity and vendor-specific know-how of the real
machine can be hidden behind the interface.
Self-explaining, consistent and complete. Although complex,
the interface will be in a notation that is easily understood.
Also responding to the need for a common machine interface,
the DMIS committee developed a common machine specification,
DmisEquip, as part of the DMIS Part II specification. The
goal of DmisEquip is much the same as that of I++ DME.
Early on, DmisEquip addressed key issues omitted by an
earlier version of I++ DME, such as support for scanning,
nontouch commands, rotary tables and calibration. The I++
committee quickly addressed those issues in release 1.3.
I++, driven largely by European automakers, seems to be
taking a much stronger hold than DmisEquip. Most software,
hardware and industry people interviewed for this story
indicated that the I++ DME standard will become the machine
interface standard of choice over DmisEquip.
Both DMIS Part II and I++ DME are working with NIST to
develop conformance standards for DMIS and a test suite
for I++ DME.
Many software companies indicate that the industry should
be keeping a sharp eye on Renishaw, the Illinois-based probe
manufacturer. Holding a majority of the probe market, the
company's probes are ubiquitous among CMM producers.
Recently, Renishaw has been ardently promoting its Universal
CMM Controller, UCC1. Many in the industry believe that
the UCC1 may eventually become the controller that customers
demand in systems that call for scanning probes.
In an ironic twist, in the same way that CMM manufacturers
claim that the best way to take maximum advantage of their
CMM is to use it with their software, Renishaw is making
the same claim about the UCC1 and its scanning probes --which
are the scanning probes that many CMM manufacturers use
(Renishaw also has the majority of the scanning probe market).
"To take full advantage of the powerful capabilities
of Renishaw's new generation of scanning probes, such as
the compact SP25M and ultra-high accuracy SP80, CMM users
need their machines to be equipped with the UCC1 controller,"
says Renishaw's Ben Taylor.
Because the UCC1 interface is in the public domain, it
opens up the UCC1 and scanning probe capabilities to all
software producers. Renishaw's controller could do to the
CMM industry what Fanuc did for machine tools or what Intel
did for the computer industry, says Ken Sheehan of Entelegence
Software Solutions, producers of Virtual DMIS software.
"You have to pay attention to the significance of
Renishaw," says Sheehan. "You will see CMM manufacturers
making just the mechanics and then plugging in Renishaw.
They are the Intel of this industry."
So what does all this mean for the customer? The third-party
software producers will tell you it's great for the customer
because, as Gilli says, "Customers can order the machines
they need rather than the ones that have the software they
need." The CMM manufacturers don't paint quite as rosy
a picture. Although Genest and others agree that it does
give customers versatility in matching both hardware and
software to their particular needs, they also believe customers
should be made aware of the pitfalls.
If Brown & Sharpe puts its own PC-DMIS software on
an LK CMM, it's the company's responsibility to make sure
the software works with the hardware, says Genest. "We're
in the driver's seat in terms of making it work. But, if
the LK machine [breaks] we wouldn't fix it. The customer
would go back to LK."
Also, unlike using PC-DMIS on its own CMMs, Brown &
Sharpe doesn't take responsibility for overall system accuracy
when mixing and matching software and hardware.
Sheffield Automation has taken a hard line on this issue
and doesn't help third-party hardware or software producers
connect to its CMMs. It's all about maintaining the quality
of its product, says Fetter. He points out that unlike other
CMM manufacturers, Sheffield has been making motion controllers
for many types of equipment besides CMMs for decades and
understands their dynamics better than others. Therefore,
Fetter believes that Sheffield's controller/software combination
can't be beat utilizing a mix-and-match combination.
"Is my CMM as good with someone else's controller
as it is with mine?" asks Fetter. "No. The bottom
line is the customer wants to accomplish something. They
have a task to accomplish in a certain amount of time. We
try to supply a solution for doing that. We believe that
we have the most control over the quality of the user's
solutions when we offer the whole package."
The CMM manufacturers see it coming. The software companies
see it coming. For better or worse, plug-and-play CMMs are
on their way. Our culture views life through a 17-inch flat
screen, Microsoft-powered 2 Ghz Intel-driven computer, and
we expect our $125 printer and quarter-million dollar CMM
to connect easily to our IBM ThinkPad.
As the CMM manufacturers and software producers work hand
in hand to give the customers what they want, we have to
hope that the drive for plug-and-play won't result in highly
compatible but mediocre products.
Dirk Dusharme is Quality Digest's technology editor.
Letters to the editor regarding this article can be sent
to letters@qualitydigest.com.
|
