Issue: Volume: 23 Issue: 8 (August 2000)

CAD Workers of the world unite

By Caren D. Potter

Right now, if you need to translate your CAD file into another pro gram's format, there are several ways to do it. You'd think at least one of them would work. And more than likely, you'd be disappointed. Even if you did manage to transfer your geometry accurately to the other system, that would be it. Any parametrics, constraints, embedded knowledge, or other representations of design intent would be lost.

Frustrating? You bet. And costly too. A March 1999 report from the National Institute of Standards & Technology ("Interoperability Cost Analysis of the U.S. Automotive Supply Chain") put the cost of imperfect interoperability at a minimum of $1 billion per year for the auto industry alone. "By far, the greatest component of these costs is the resources devoted to re pairing or re-entering data files that are not usable for downstream applications," the report stated.

Interoperability-defined as the ability to re-use one system's CAD data in other applications-has been a problem since "the second CAD system was developed," according to industry analyst David Weisberg. And ever since then, "it's been a back-burner type of issue," says Evan Yares, president of the CAD Society. That's not the case any longer. Having endured the costs and frustration of poor interoperability long enough, users are heeding the advice of Howard Beale, the aging news anchor in the 1976 movie, Network: "Go to the window, open it, stick your head out and yell: 'I'm mad as hell, and I'm not going to take this anymore!'"

Perhaps that's an overly dramatic way to characterize the interoperability initiatives that have come forth recently. But there's no question that users are fed up with what they see as intentional efforts on the part of CAD vendors to keep them from using their data as they see fit, even if that includes transferring it to another vendor's CAD system, or using it in complementary applications such as FEA or CNC programs that come from other suppliers.

The most recent interoperability initiative, called the "CAD Society Inter op erability Guidelines," was generated this spring. The CAD Society's initiative "puts a stake in the ground," says Yares. "The guidelines clearly state that CAD data belongs to the customer, not to the vendor of the software used to create it. Further, the guidelines specify that vendors should do nothing to prevent their customers from using that data in any fashion they desire. It may seem obvious that customers own the data they create," Yares adds. "But even obvious things sometimes need to be stated clearly."

"There are five basic approaches to data exchange," says Ken Versprille, program manager for design creation and validation at D.H. Brown Associates. (Port Chester, NY). "That's not counting everyone buying the same CAD program. But that's not realistic," he says. "Look at Ford. After telling all their suppliers they had to use I-deas [Ford's CAD system], Ford said, 'There, we don't have an interoperability problem.' Then they bought Volvo, which uses Catia, and they were right back into the fray."

Method One: The first data exchange technique is to use a standard vehicle such as IGES (Initial Graphics Exchange Specification) or STEP (Stand ard for the Exchange of Product Model Data), says Versprille. In this approach, the original CAD file is translated into the IGES or STEP neutral file format. The translated file is then read into the second application and converted to the receiving application's format. Unfortunately, both IGES and STEP handle geometry only. Features, history, and parametrically defined variables are not included in the exchange, though there is some hope that STEP will eventually convey some of this additional information.

In the meantime, the standards approach has garnered some strong support. One proponent is Don Hemmelgarn, senior vice president and general manager of the product data interoperability business at International TechneGroup Inc. (ITI), a company that has been in the interoperability business for 17 years. "We've seen a lot of success with these standards," he says. "They don't always work out of the box, but we're able to make them work by applying some additional tools."

Nonetheless, everyone's concern with STEP is that it is "moving at extremely slow speed," as Versprille tactfully puts it. And that is always likely to be the case for STEP or any neutral file format, since its development will always lag behind the advances made to the CAD programs themselves.

Indeed, here's a telling comment about the time factor from a white paper, "Passing the Torch in Data Exchange," available on ITI's Web site: "If it is true that good things come to those who wait, then it also stands to reason that there are countless engineers and designers out there who fully expect the new product data exchange standard, STEP, to be nothing short of miraculous. To say that it has been a long time in coming would, to say the least, be an understatement."
After the model (top) was converted to an IGES file and transferred from one program to another, several geometry problems arose, including duplicate edges, shown in red (middle). In this case, ITI's CADfix was used to repair the model and display it as a

In fact, the preamble of the CAD Society's Interoperability Guidelines makes clear that users have lost confidence in STEP and IGES. "In the past, various organizations have tried to promote interoperability by drafting data frameworks and standards, which could be used to translate data from system to system," the document states. "This approach, now 20 years old, has been an abject failure."

Method Two: The second data exchange approach is to use proprietary converters, also called direct translators. These are programs, written by the CAD vendors themselves or by third parties, that bypass the use of a neutral file format and perform the data conversion directly. According to Versprille, the advantage of this approach is that you can have highly tuned mapping between one product's objects and another's. The down side, he warns, is that it requires an N2 set of tools-that is, a converter for every combination of applications.

Method Three: Geometry kernels such as ACIS and Parasolid offer a third approach to data exchange. Two programs built on the same kernel should be able to exchange data in their native file formats without difficulty. "This technique does transfer geometry accurately," says Versprille. "But the drawback is that it's unintelligent geometry. There are no features, parameters, or history."

Method Four: Another option is to perform data exchange through the CAD program's application programming interface (API). This approach requires a programmer and a different solution for each CAD system, but it seems to be gaining momentum, says Versprille.

Here's how it works. CAD vendors license their APIs, for a price, to software developers. (APIs come with names like UG/Open API, Open I-deas, Pro/Engineer Ap plication Programming Toolkit, and so on.) Through an API, a developer gets some access to the data created by the CAD system.

By writing a data exchange program using an API, in theory at least, you'll have a better exchange of data. This is the way some of the complementary applications, such as analysis and toolpath programming, are now interfacing with CAD programs. Soft ware developers in the Solid Works Gold Partner program, for instance, are given access to the SolidWorks API. By integrating their programs with Solid Works data via the API, they generally en sure good transfer.

The API approach is what Yares of the CAD Society sees as the right direction as well. "The ideal we have is an actual feature-based translation to carry design intent," he says, "and the only way to do that, absent STEP being more powerful, is to build translators in the APIs of the various programs to do direct translation."
Models can be inspected for integrity before being transferred. The Pro/E model below appears valid, But a closer look at one hole (right) using ITI's CAD IQ Viewer software reveals geometry imperfections, highlighted in red (lower right), that would

One note of caution is that "the level of access, in terms of which types of the model's elements you can read and write, varies from vendor to vendor," says Hemmelgarn. "What you can get at is the fully evaluated mod el, which is the geometry and topology that re sults after certain parameters or con straints are ap plied to the model. But in most cases, they will not allow you to get at the actual parametric definitions or the design intent-type information."

Moreover, Hemmelgarn adds, "each vendor has its own API that it uses internally. That API is complete, with functions for accessing every possible bit and byte and for performing operations on the database." Even if two vendors did happen to give complete access to their data via their APIs, it would still be difficult to write a data translator that conveyed all the design intent between their two programs, he explains. "The task of building a complete bi-directional translation that supports all of the design intent would be difficult, because of the fundamentally different ap proach taken to building and representing models in the different programs."

Method Five: The last technique for data exchange is to use what Versprille refers to as visualization technology. This is the approach vendors such as Engineering Animation Inc. (EAI) use to deliver CAD-neutral visualization tools that import data from different systems, display it on a screen, and let users manipulate the model, mark it up, and so on.

This approach is based on tessellation, which represents entities such as lines and surfaces in a CAD system with tiny triangles. Data formats such as XML and VRML are good examples of tessellated data. What Versprille likes about this approach is that it's a neutral format, and although the data is approximate, "you can approximate to a very fine level," he explains.

There aren't many applications built on these formats yet, but Versprille has seen progress in the past year and a half and expects that to continue. "We know of a number of CAE companies that are looking to rehost their finite-element modeling applications on top of tessellated data," he says. "I wouldn't be surprised if we see some NC programming applications built on this, too."

Today most NC programs, although they read the CAD model's exact geometry, tessellate for performance reasons before they create the toolpath." Toolpath generation is an application that requires a lot of accuracy," Versprille continues. "If working with tessellated data is good enough for these vendors, that sends a message to me that tessellated data, or approximate data, if done fine enough, is a viable data exchange option."

The five methods listed above are technological solutions to the data exchange problem. But an underlying theme in the CAD Society's Inter-operability Guidelines is that technology alone will not suffice. The preamble states: "A technological solution to CAD interoperability seems to be evasive. So as a pragmatic manner, [a] non- technological solution may move the issue into the open."

The CAD Society's non-technological approach was to draft a set of five simple statements to the CAD vendors (see "The CAD Society Interoperability Guidelines," below). Each statement consists of a simple sentence, but the overall effect is a message to the vendors to stop interfering with users' attempts at data exchange. How do vendors interfere? One way is by refusing to completely open their APIs. Some also encrypt the CAD data. And most control the distribution of their software licenses when the software is going to be used for developing data exchange solutions. "Just because you want a software license, doesn't mean you can always get one," says Versprille. In some cases, the vendor will sell the license as long as the recipient is a member of its "partner" program. Direct competitors don't qualify for those programs; third parties do, but as members they submit to a certain level of control from the vendor.

Points three and four of the CAD Society's guidelines address the licensing issue specifically. An earlier version of the guidelines wanted vendors to agree to license their software at prevailing rates for the express purpose of developing interoperability solutions. Point four went so far as to say that the license should also include "all development tools generally made available to third-party companies, including specifically any tools used for data access." In other words, it would not be necessary to be part of vendor parter programs to get the best shot at effective data exchange. The new guidelines seem to have backed off on this point.

Can the initiative succeed? Adherence to the CAD Society's Interoperability Guidelines "requires no commitment of development resources on the part of the vendors," according to the preamble. "In fact, it requires the vendors to do little or nothing, other than not interfering with or preventing reasonable attempts to make their CAD software work with other CAD products on the market."

The incentive for vendors who accept the guidelines and make a commitment to that effect is that they will have the right to use the CAD Society Interoperability Guidelines logo, making their position clear to users. By extension, lack of the logo will symbolize a lack of commitment to interoperability. "There are CAD vendors who compete based on trying to hamstring their customers," the preamble notes. "This will always be true. With the CAD Society's Interoperability Guidelines, this form of behavior is placed in the open, for all to see."

The next logical question, then, is what effect will public awareness of each vendor's interoperability stance have on the market? In Versprille's opinion, not much. "I don't believe the big four CAD vendors will sign it, and why should they?" he asks. "Their business doesn't demand it. No one can point to a client who hasn't bought CAD software-or one who has thrown it out-because the vendor didn't cooperate on data exchange. Until vendors lose sales specifically because of this issue, nothing will change."

Yares counters that some vendors have already indicated they will commit to the CAD Society's guidelines, but until the guidelines are formalized (a revised version is currently being reviewed by CAD Society members), it is premature to name them. Versprille guesses they will be "second tier" CAD companies, such as SolidWorks, Solid Edge, and Autodesk. "It is to the advantage of these vendors to do data exchange because they're trying to cut into the market of the big four [Catia, Pro/Engineer, SDRC, Unigraphics]," Versprille says. "They're going to stand up and say, 'Sure, we'll do data exchange.' The big four will only move when they have to."

The best advice right now seems to be to minimize the need to convert data from one CAD format to another. If you must do it, and wish to use IGES or STEP, consider looking for additional tools or services that can tailor the exchange format to your needs. Versprille recommends that before selecting any data exchange method, stop and think why you are exchanging CAD data. If all you need to do is view it, using a tessellated data format may be sufficient. "I can cite examples where OEMs demanded that their suppliers give them data in their CAD system's native format, but they never changed the data," he says. "They made the suppliers go through that agony for no reason." He also suggests patience if the reason for data exchange is downstream use of the CAD data in a complementary application. "If you are moving data from one CAD system to another ap plication, that application may soon exist on top of tessellated data, if it doesn't already."

Finally, we can all hope that the combined voices of users saying "We're not going to take it any more!" are heard and heeded.

Caren Potter is a contributing editor of Computer Graphics World. She can be reached at


  1. The data created by a customer using a software tool belongs to the customer.
  2. The customer has the right to understand their data, and the vendor will do nothing to prevent this.
  3. The vendor agrees to sell their software to any customer allowed by law.
  4. The vendor agrees that their software may be used on server computers for the purpose of translating data files to and from other formats.
  5. If agreed to by a vendor, these guidelines supercede any other licensing terms or policies established by that vendor.