PAVIATH INTEGRATED SOLUTION
PAVIATH INTEGRATED SOLUTION
Paviath
MECH ENGG CAD CONVERSION

CAD data exchange

CAD data exchange is a modality of data exchange used to translate data between different Computer-aided design (CAD) authoring systems or between CAD and other downstream CAx systems.

Many companies use different CAD systems internally and exchange CAD data with suppliers, customers and subcontractors.[1] Transfer of data is necessary so that, for example, one organization can be developing a CAD model, while another performs analysis work on the same model; at the same time a third organization is responsible for manufacturing the product.[2] The CAD systems currently available in the market differ not only in their application aims, user interfaces and performance levels, but also in data structures and data formats[3] therefore accuracy in the data exchange process is of paramount importance and robust exchange mechanisms are needed.[2]

The exchange process targets primarily the geometric information of the CAD data but it can also target other aspects such as metadata, knowledge, manufacturing information, tolerances and assembly structure.

There are three options available for CAD data exchange: direct model translation, neutral file exchange and third-party translators.

CAD data content

  • Metadata – non-graphical attributes
  • Design intent data – e.g. history trees, formulas, rules, guidelines
  • Application data – e.g. Numerical Control tool paths, Geometric dimensioning and tolerancing (GD&T), process planning and assembly structure

Although initially targeted for the geometric information (wire frame, surfaces, solids and drawings) of a product, nowadays there are other pieces of information that can be retrieved from a CAD file:[2]

The different types of product information targeted by the exchange process may vary throughout the life cycle of the product. At earlier stages of the design process, more emphasis is given to the geometric and design intent aspects of the data exchange while metadata and application data are more important at later stages of the product and process development.[2]

Data exchange options - Direct model translation - Neutral file exchange - Neutral formats

  • IGES (Initial Graphics Exchange Specification) – originated around the late 1970s and initially published by the American National Standards Institute (ANSI) in 1980 preceding the large-scale deployment of the CAD technology in the industry.[7] This file format considers the product definition as a file of entities, with each entity being represented in an application-independent format.[2] After the initial release of STEP (ISO 10303) in 1994, interest in further development of IGES declined, and Version 5.3 (1996) was the last published standard.[4]
  • DXF (Drawing eXchange Format) – developed by Autodesk in 1982 as their data interoperability solution between AutoCAD and other CAD systems. The DXF is primarily 2D-based and its format is a tagged data representation of all the information contained in an AutoCAD drawing file, which means that each data element in the file is preceded by an integer number that is called a group code indicating the type of following data element. As most commercial application software developers have chosen to support Autodesk's native DWG as the format for AutoCAD data interoperability, DXF has become less useful.[2]
  • VDA-FS (Verband der Automobilindustrie â€“ Flächenschnittstelle) – created by the German Association of the Automotive Industry in 1982 as an interoperability method for free-form surfaces.[8] This format differs from other formats in that it only supports the communication of free-form curve and surface data with associated comments, but no other geometric or non-geometric entities. Therefore, it is limited to representations by parametric polynomials, but this covers the great majority of free-form CAD systems. It includes Bézier, B-Spline and Coons tensor product types of surfaces and corresponding curves.[1] The VDA-FS specification is released in the German Industrial Standard DIN 66301.[9]
  • PDES (Product Data Exchange Specification) – originated in 1988 under the Product Definition Data Interface (PDDI) study done by McDonnell Aircraft Corporation on behalf of the U.S. Air Force. PDES was designed to completely define a product for all applications over its expected life cycle, including geometry, topology, tolerances, relationships, attributes, and features necessary to completely define a part or assembly of parts. PDES can be viewed as an expansion of IGES where organizational and technological data have been added. In fact, the later PDES contained IGES. The development of PDES under the guidance of the IGES organization and in close collaboration with the International Organization for Standardization (ISO) led to the birth of STEP.[2]
  • STEP (ISO 10303 â€“ STandard for the Exchange of Product model data) – the work with the ISO 10303 standard was initiated in 1984 and initially published in 1994, with the objective to standardize the exchange of product data between PLM systems. It is a very comprehensive set of specifications covering many different product types and many life cycle phases. STEP uses the neutral ISO 10303-11 format, also known as an EXPRESS schema. The EXPRESS schema defines not only the data types but also relations and rules applying to them.[4] STEP supports data exchange, data sharing and data archiving. For data exchange, STEP defines the transitory form of the product data that is to be transferred between a pair of applications. It supports data sharing by providing access to and operation on a single copy of the same product data by more than one application, potentially simultaneously. STEP may also be used to support the development of the archive product data itself.[2] STEP consists of several hundred documents called parts. Every year new parts are added or new revisions of older parts are released. This makes STEP the biggest standard within ISO. The 200-series parts STEP are called Application Protocols (AP),[4] with the specific parts directly related to CAD systems:
  • 203 (Configuration controlled 3D designs of mechanical parts and assemblies) – Mainly used for 3D design and product structure. A subset of AP214 but most widely used.
  • 210 (Electronic assembly, interconnect and packaging design) – CAD systems for printed circuit board.
  • 212 (Electrotechnical design and installation) – CAD systems for electrical installation and cable harness.
  • 238 (STEP-NC Application interpreted model for computerized numerical controllers) – CAD, CAM, and CNC machining process information.
  • 242 (Managed model based 3D engineering) – the merging of the two leading STEP application protocols, AP 203 and AP 214.
  • Parasolid XT – part of the Parasolid geometric modeling kernel originally developed by Shape Data and currently owned by Siemens PLM Software.[10] Parasolid can represent wireframe, surface, solid, cellular and general non-manifold models. It stores topological and geometric information defining the shape of models in transmitting files. These files have a published format so that applications can have access to Parasolid models without necessarily using the Parasolid kernel.[11] Parasolid is capable of accepting data from other modeler formats. Its unique tolerant modeling functionality can accommodate and compensate for less accurate data.[12]
Third-party translators[edit]

Direct data translators provide a direct solution which entails translating the data stored in a product database directly from one CAD system format to another, usually in one step. There usually exists a neutral database in a direct data translator. The structure of the neutral database must be general, governed by the minimum required definitions of any of the modelling data types, and be independent of any vendor format.[2] Major CAD systems, such as SolidWorks, PTC Creo, Siemens NX and CATIA can directly read and/or write other CAD formats, simply by using File Open and File Save As options.[4] This option is limited by the fact that most CAD formats are proprietary therefore direct translators are typically unidirectional, partially functional and not standardized.[5]

Neutral file exchange uses an intermediary neutral format to translate data between CAD systems. This method starts from a pre-processor embedded in the original CAD system, which generates the neutral file from the originating CAD format. The target CAD system post-processes the neutral file and converts it into the target native format.[6] Some neutral formats are defined by standards organisations such as IGES and STEP while others are proprietary but still widely used and are regarded as quasi industry standards.[4]

Several companies specialize in CAD data translation software that can read from one CAD system and write the information in another CAD system format. There are a handful of companies 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.[13] These systems have their own proprietary intermediate format some of which will allow reviewing the data during translation. Some of these translators work stand-alone while others require one or both of the CAD packages installed on the translation machine as they use code (APIs) from these systems to read/write the data.

Data exchange quality

Data quality can be addressed intrinsically and extrinsically. Intrinsic problems are those related to the CAD model’s structure before any translation process begins, while extrinsic problems relate to those issues appearing during translation. The development of STEP is the best solution to solve the extrinsic problems, extending its current capabilities to support 2-D parametric sections, 3-D parametric assemblies, and history-based modeling. Product data quality is a key issue to avoid intrinsic data exchange problems and simplify the integration of downstream applications in the design chain. The development of commercial quality checkers and product data quality standards, such as VDA 4955 and SASIG–PDQ 1.0, shows the growing interest and importance of this topic.[14]

As each CAD system has its own method of describing geometry, both mathematically and structurally, there is always some loss of information when translating data from one CAD data format to another. One example is when the translation occurs between CAD systems using different geometric modeling kernels, in which the translation inconsistencies can lead to anomalies in the data.[2] The intermediate file formats are also limited in what they can describe, and they can be interpreted differently by both the sending and receiving systems. It is, therefore, important when transferring data between systems to identify what needs to be translated. If only the 3D model is required for the downstream process, then only the model description needs to be transferred. However, there are levels of detail. For example: is the data wireframe, surface, or solid; is the topology (BREP) information required; must the face and edge identifications be preserved on subsequent modification; must the feature information and history be preserved between systems; and is PMIannotation to be transferred. With product models, retaining the assembly structure may be required.[4] If drawings need to be translated, the wireframe geometry is normally not an issue; however text, dimensions and other annotation can be an issue, particularly fonts and formats. No matter what data is to be translated, there is also a need to preserve attributes (such as color and layer of graphical objects) and metadata stored within the files.

Some translation methods are more successful than others at translating data between CAD systems. Native formats offer the simple translation of 3D solids, but even so there are few pitfalls to watch out for. If two CAD systems use different representations for one type of geometry at some point the representation must be converted or even discarded, regardless of the type of translation. Neutral formats are designed partly to solve this problem, but no format can completely eliminate all translation issues.[15]

The most common CAD data exchange problems via neutral formats are:

  • loss of the architectural structure
  • change the names of parts with numbers or names assigned to the directories where they are stored
  • loss of bodies from the assemblies
  • displace of details of their correct position relative to the original model
  • loss of the original color of the parts
  • visualization of details of their correct position relative to the original model
  • displaying the construction lines that are hidden in the original product
  • modification in the graphic information
  • modification on hollow bodies into solid bodies.[15]

Some CAD systems has a functionality to compare geometry of two models.[16][17] So, user can compare the model before and after translation from one CAD to another one to estimate quality of the translation, and to fix found defects. But often such functionalities can compare only tesselations of two models. It is really hard algorithmic problem to compare topological elements of two 3D models and restore their associativity to show groups of modified faces, because there are very different representation of geometry data in different CAD systems, but sometimes it is possible. For instance, the component LEDAS Geometry Comparison based on C3D kernel can be integrated in CAD system (like Autodesk Inventor, [18]) to compare 3D models and pinpoint all of the differences between them.[19]

https://en.wikipedia.org/wiki/CAD_data_exchange

CADEXCHANGER
info@paviathintegratedsolution.com www.paviathintegratedsolution.com