by Evan Yares, Senior Editor & Analyst, Software

CAD Interoperability Today. It’s still an issue, but it’s getting better all the time.

It’s possible that you don’t have any CAD interoperability concerns. If you use a single brand and version of CAD software, and don’t get CAD files from people using other systems, and don’t use the files you create in any other applications, then you’re gold. Just keep doing the same thing, and never upgrade your software, and you’ll be fine.

Most CAD users don’t live in a vacuum. They receive CAD files of various types and versions from others, and use the CAD files they create for a variety of downstream processes. For these people, interoperability problems are par for the course, and will continue to be, more or less, for the foreseeable future.

To understand why this is so, you need to dig in a bit, and understand how CAD systems store their data.

NURBS and B-reps
Modern 3D mechanical CAD systems, as a rule, all use similar data representations. At the top level are assemblies. Under those are parts, and separately, drawings. Parts are either parametrically or explicitly defined, but in either case, their topology is defined by a boundary representation (B-rep) solid model, made up of trimmed NURBS (non-uniform rational B-spine) surfaces. Think of a B-rep as being like a scuba diver’s wet suit, sewn together out of individual pieces. If the sewing is high quality, the suit will be water tight. If the sewing has too many gaps, the suit will leak.

Admittedly, this is a simplistic analogy, but it’s good enough. The biggest problem in CAD interoperability is that different systems, handle tolerances differently. All too often, when translating files from one system to another, the receiving system balks on some of the tolerances, and creates models with holes or gaps. The model will often come in as a whole bunch of individual surface patches, which you then need to fiddle with, to see if you can get the program to stitch them into a solid.

Why do CAD systems have these tolerance problems? The 64-bit mathematical precision of modern PCs is often not quite enough to calculate the shape of the NURBS curves as accurately as is necessary—particularly on models that are physically big, with fine details. (Engineers in the atomic industry often experience this problem.) But, to be fair, it’s just plain old difficult to create mathematical algorithms that are accurate enough to ensure perfect stitching. In most cases, the people who write the geometric modeling kernels (engines) used in CAD systems intentionally build a lot of forgiveness into their algorithms in the form of tolerances. If two surfaces on a model are within the tolerance range that the programmer has specified, then it’s good enough.

I’m copping out a little bit by saying that tolerance problems are the biggest problems in CAD interoperability. Most people in the industry say that it’s the biggest problem—but that doesn’t make it true. I was recently talking with Dr. Paul Stallings, a journeyman kernel developer who headed up ACIS development in the past, and who now works at Kubotek. He explained to me that tolerance problems are one of the easiest parts of the interoperability problem for him.

What keeps him on his toes is that native CAD formats are constantly changing. Standard file formats, such as IGES and STEP, create their own problems. With an open standard, anyone—competent or not—can attempt to write files in the format. The formats offer so many options that inexperienced developers make a lot of mistakes.

The other big part of the problem, according to Stallings, is that different CAD systems represent geometry and topology in radically different ways. He pointed out one of his favorite examples: that in ACIS a cylinder is a cone and in Pro/E a sphere is a torus. Larger differences include such things as how surfaces are parameterized. A more difficult problem is with advanced procedural surfaces such as blends and lofts. There can be many undocumented, cryptic, even unimplemented options in these.

With tolerances, Stallings says that the major problem is that some systems depend on trimming curves in three-dimensional space, and other systems depend on trimming curves in the different two-dimensional parameter space of the surfaces that they are on. The mismatch between parameter space and three-dimensional space is a big problem with ACIS and Parasolid using three-dimensional space and CATIA and Pro/E using parameter space. IGES and STEP include one or both of the formats. Stallings says that he sees far too many of these files which contains both 2D and 3D curves—and the curves that were not used natively by the writing system are bad. IGES tries to fix this problem by actually providing a flag for the writer to set that tells which curves to trust. Ironically, the existence of such a flag is a near admission of guilt, in that if both curves were always good, then it would not be needed.

If you’ve followed this conversation so far, congratulations are in order: You are a true CAD nerd.

Stallings, never one to shy away from speaking his mind, also pointed out that, when CAD files can be exported from expensive systems, people buy less seats of those systems, and just rely on the ability to translate the files to less expensive systems. So, there is a disincentive to making the process easy.

The translator business
Possibly because of disinterest by large CAD vendors, a rather healthy CAD interoperability industry has grown over the last few decades. There are a handful of companies, including Datakit, Spatial, and Tech Soft 3D, that provide low-level software toolkits to directly read and write the major CAD file formats. Most CAD developers license these toolkits, to add import and export capabilities to their products.

There are also a significant number of companies that use the low-level translation toolkits as the basis for building standalone end-user translation and validation applications. Among these companies are ITI TranscenData, Theorem Solutions, Elysium, Capvidia, TransMagic, and Core Technologie. You might wonder why such companies exist, if CAD programs generally include import and export translators. There are three reasons: First, not all CAD programs have the capability to read and write all CAD formats. Second, the standalone translators (at least, most of them) are often higher quality, and more reliable than the translators built into CAD programs. Third, the standalone translator companies offer products with more features and automation that are designed to handle the kind of problems that large aerospace and automotive firms might encounter.

What’s changed in interoperability?
Quite a bit has changed in interoperability over the years. Some years ago, it was considered a reasonable strategy to settle on just one supplier of CAD and related software. Now, it’s far more common for large companies to adopt a multi-CAD strategy. One large vendor of power generation equipment recently gave a presentation at an industry conference, where they pointed out that 11 different CAD programs were used by them and their suppliers to design their latest combined cycle gas turbine design.

It used to be believed that the different ways in which CAD systems handled their parametric features made a multi-CAD strategy inherently painful.

Some years back, investors poured over $40 million into Proficiency, a company trying to solve the feature-based CAD translation problem. They never did get it quite right, and were acquired by ITI TranscenData in 2009. ITI has told me that they can get up to 95% right on feature-based translation. That’s probably not good enough for prime time. These days, Proficiency is most commonly used when companies are doing major migrations from one CAD system to another.

The need for feature-based translation has been reduced by the advent of CAD programs with advanced direct editing capabilities, such as Solid Edge, Kubotek, SpaceClaim, IronCAD, and Creo Direct. These programs can work with essentially dumb CAD data, and edit it in a sensible way. They’re particularly popular for doing front-end conceptual modeling, or model preparation for CAE programs.

Another trend that has had an effect on CAD interoperability is the rise of product and manufacturing information (PMI), and model-based design (MBD). The basic premise of MBD is putting all the information necessary to build a part in its 3D CAD file, and entirely doing without 2D drawings. Some large aerospace firms have been pursuing this initiative for most of the last decade, but it’s been only in the last year or two that the concept has started to gain traction outside the aerospace industry.

MBD affects CAD interoperability because it adds another level of data to 3D CAD files. Now, rather than just translating the geometry in a CAD file, a translator program needs to properly handle all the annotation. PMI is variously known as GD&T and FT&A, depending on which CAD vendor you speak too. It is based on ANSI Y14.41, Digital Product Definition.

Yet, beyond just adding another level of data to 3D CAD files, MBD sometimes changes the way that users think about those files. In the ancient times of the 20th century, 2D drawings were considered the authoritative reference to a design. The 3D model was either just something used to generate the drawing, or it was a convenience, that you might pass along to someone doing downstream work. With MBD, the 3D model is the authoritative design reference.

Would you be surprised to learn that CAD translators often make mistakes? Even ostensibly good ones can create defective export files, or introduce errors when importing files. In the best of cases, import errors will be obvious to the naked eye, and will be easy to fix, with a little bit of surface modeling. Too often, though, import errors are not that obvious. In some cases, a file may seem to import just fine, but some time later, it will fail during a blend or similar editing operation.

It’s not uncommon to find that native CAD files from an earlier version will have problems when opened with the latest version of the program. This even happens with the most expensive CAD software.

You must validate
Whether or not you are using MBD, if you are using your 3D CAD models in downstream processes, it’s important to know that what you end up with is the same thing as what you started with. It is simply too expensive to find out that a translated CAD file is defective after you’ve been working on it for a week. And it’s far too expensive to find that out after you’ve cut a 400-pound injection mold based on the data in that file.

The solution to this problem is CAD data validation. A significant number of companies offer applications designed to validate CAD files by showing any differences between a reference authority file, the file resulting from a translation. Among other companies, ITI TranscenData, Theorem Software, Elysium, TransMagic and Kubotek offer software of this type. Capvidia is unique in offering a SolidWorks “Gold Partner” validation program, CompareWorks, that runs inside of SolidWorks.

CAD data validation is also important for archival storage of CAD data. While STEP is a good format for archiving CAD files, the only way to be certain that you’ve created a valid and accurate STEP file is to validate it against the source authority file.

Reprint Info >>

Capvidia
www.capvidia.com

Core Technologie
www.coretechnologie.com

Elysium
www.elysiuminc.com

ITI TranscenData
www.transcendata.com

Kubotek
www.kubotekusa.com

Theorem Solutions
www.theorem.co.uk

TransMagic
www.transmagic.com

---

Filed Under: 3D CAD, Design World articles, Software

 

---