Computer-aided design (CAD) has transformed product definition and has been a catalyst for model-based definition (MBD), helping organizations end their reliance on legacy drawing-based processes. Even though CAD has been an enabler for MBD, many organizations are using CAD for both 2D and 3D definition.
CAD technology advancements have enabled engineers to increase the amount of detail and the accuracy of digital representations of products and requirements. The ability to digitalize product manufacturing information (PMI), in addition to part geometry, enables CAD files to contain a complete design data set in MBD.
As CAD files become more detailed, ensuring interoperability of the embedded data becomes more important. When CAD files are needed on a different device or in a different format, users often create a copy or derivative file to facilitate reuse of the natively authored source data. In cases where CAD data does not readily translate to derivative formats, the data is often manually recreated in the required format to enable cross-machine communication.
While CAD is used throughout the engineering process, for the purpose of this article we will consider its use case as being contained to the creation of digital product definition files like 3D models and/or 2D drawings of physical components.
Difficulties with CAD and Derivative Files
While CAD has been a change agent and has supported the industry in creating, importing, and validating derivative files, it still has gaps. The current state of translating data from one system to another and creating a derivative can be compared to the game of telephone. Without perfect communication at every step, the original message can become distorted along the journey.
Certain functional aspects of CAD software types drive inconsistencies in derivative files when the data is translated to a format outside of the authoring system. Below are five common obstacles faced when using CAD and derivative files.
1. No Two CAD Systems or File Formats Are the Same
There are a plethora of CAD systems and file formats on the market, often tailored to specific industry verticals. Every software provider has a unique CAD format that is designed to meet the needs of their user base. Because these CAD formats are tailored and nuanced, they are typically not inter-CAD compatible. The issues related to inter-CAD compatibility are important topics within the model-based community, since data continuity is a foundational element for the success of the model-based enterprise (MBE) as a whole. The software user base often navigates multi-CAD environments and needs solutions for gaps in data continuity.
To close the gap, software providers have created the ability to convert their native CAD format to International Organization for Standardization (ISO) compliant neutral formats, including the Standard for the Exchange of Product Data (STEP). STEP is a CAD-neutral format specifically designed to enable CAD interoperability across many software platforms.
Although STEP is one of the most widely accepted CAD-neutral formats, it is not a flawless solution. In order to support the widest number of use cases, STEP tends to exclude more nuanced features and approaches that are critical to specialized processes. Its inability to support specific features in some CAD software manifests in varying levels of translation inaccuracy. This can cast doubt on the amount of trust that should be placed in the exclusive use of a neutral format. In addition to STEP, Quality Information Framework (QIF) is another CAD-neutral format that is geared toward supporting digital thread and quality-based MBD workflows.
2. CAD and Derivative Files Are Not Exact Matches
In an ideal world, native CAD and derivative files would be an exact match of each other. In reality, CAD translation is never perfect. Functional features, mathematical shape methodology, and even individual software configuration settings can generate changes to the product definition when moving from one software to another. Translations require robust validation to ensure geometric measurements and engineering data falls within tolerable limits of the standards set by the authoring company, and that the new definition meets the original design intent.
3. Geometric Accuracy
Geometric accuracy is a common issue when it comes to CAD and derivative files. Some CAD systems are accurate to 11 decimal places, while others are accurate to eight or fewer. And while a derivative file may be written to the same resolution as the source software, the target software may still round to its default decimal resolution on import, changing the physical form of the model. In most cases this inconsistency can be tolerated, but there are scenarios where tolerance is extremely low and high accuracy is required. Exclusion of a decimal in these scenarios could have potentially serious adverse effects on the parts produced.
A CAD system may also create features that are not supported in the derivative format or the receiving target CAD system. It is common for these features to be written to the format as a “best fit,” which often creates overlap with an existing data type. This is a common occurrence with supplemental geometry like construction planes or lines/arcs which may be used to describe engineering requirements. These data types are generally classified as construction geometry and are often not visible upon import.
Another common geometric issue in CAD software relates to freeform shapes. CAD software generally has high levels of capability when creating prismatic shapes, and most software use the same mathematical modeling techniques to approximate prismatic shapes. However, there are several different mathematical approaches to produce non-prismatic freeform geometry which all result in slightly different part topology. This is another scenario where the differences need to be assessed to determine whether they can be tolerated without impacting part fit or function.
4. Non-Geometric Considerations
Impacts to non-geometric elements also need to be assessed during translation. One example is the quantity listed on a PMI annotation in MBD. If the CAD system does not explicitly provide a placeholder field for “quantity,” that value is assumed based on predictive logic during translation. Other attributes written as PMI text strings appended to a requirement can be misinterpreted or lost during translation. This can cause the derivative file to be disconnected from the source CAD file.
It can also be challenging for derivative formats to deliver maximum functionality for feature grouping. When designing a part, patterns of holes or other multi-instanced features require the explicit grouping of CAD objects to develop the requirement structure. Identifying and tracking each instance in the pattern is referred to as product characterization. Most CAD systems do not include the functionality necessary to adequately characterize requirements for use in quality management systems (QMS) or product lifecycle management (PLM) systems. This leaves a gap in traceability of the elements that constitute the feature grouping.
There are also instances where data does not translate well to the PLM system where the CAD files reside. PLM systems should support the management of CAD-based data assets to track product requirements. When the embedded data in a CAD file does not easily populate the data structure defined inside a PLM system, managing that data consistently is a challenge.
5. Designing vs. Interpreting Design
In a drawing-based environment, a human would review the drawing and make interpretation assumptions when intent was not clear. The obvious disadvantage is the potential for misinterpretation. However, the advantage is that an experienced consumer could often use technical judgement to correctly fill in definition/interpretation gaps.
As the industry transitions to digital, there are far fewer opportunities for human interpretation or override. Each software developer strives for consistent operational features or learned methods for producing a predictable result. However, when creating derivative file software logic, interpretation of someone else’s design can often rely on individual judgement. As in the drawing-based environment, experience helps to develop a strong sense of technical judgement, but there can always be variations between two individuals’ perceptions of design intent and the best way to express that intent in a new software environment. This puts an even greater priority on the need for validation of translated data as a cornerstone of a digital transformation.
Validating CAD Files is Essential
Geometric accuracy, explicit PMI requirements, and design intent are the most important reasons to ensure your digital transformation includes a plan for comparing and validating CAD files. The goal is to ensure robust interoperability solutions and reduce the need to recreate product definition artifacts. Gaps in product data quality between systems drive higher manufacturing cycle times, increase quality issues, and ultimately increase costs within the design-to-manufacturing lifecycle. Solving these challenges is complicated, but the benefits are worth pursuing.
Belcan offers solutions to complex MBD and interoperability challenges. Learn more about how Belcan can assist your organization with your digital efforts here.
Share This Article!
