3D PMI Import Is the Most Critical Step for MBD - But it's not easy!

There's a conversation happening across manufacturing right now about the promise of the Model-Based Enterprise. Companies are investing in MBD workflows, retiring 2D drawings, and pushing 3D technical data packages out to their supply chains. It's exciting progress, but there's a foundational requirement that doesn't get nearly enough attention, and when it's missed, the entire downstream value of MBE collapses: The correct, high-fidelity import of 3D Product and Manufacturing Information (PMI) when preparing all downstream derivatives. 

I've spent a lot of time working with engineering and manufacturing organizations trying to get this right, and I'll tell you from experience that getting accurate geometry is the easy part. Getting the PMI right is much more difficult, and where stakes are highest!

PMI is the Design Intent

The 3D model communicates shape, whereas the PMI is comprised of GD&T callouts, datums, surface finish requirements, weld symbols, etc., and communicates the engineering intent behind that shape. It tells manufacturing exactly what must be true about the part for it to function correctly. When you move to a model-based workflow and eliminate the 2D drawing, the PMI in that 3D model is the authoritative document of record. Any derivative created from the 3D model for downstream access must be perfect.  The problem is that most people assume that if the geometry came through clean, the PMI did too. That assumption is wrong, and it's dangerous.

What bad PMI actually looks like

Software developers have two main options when building translators that read 3D CAD MBD data and map that data into their application data structures. They can license data access libraries offered by the CAD companies themselves, or they can use 3rd party libraries that work by cracking and decoding binary data structures in the native CAD formats. With this latter approach, the PMI doesn't get converted at its native fidelity and is approximated. These types of 3rd party libraries historically have done a good job on geometry and product structure, but 3D PMI has proven to be a much harder challenge for them. The problems that you end up with in practice are things like:  

• Fonts that don't match the original, leading to misinterpretation of GD&T symbology.

• Leader lines that are detached from the faces they reference, making it impossible to query the PMI to Face association.  

• Missing PMI elements entirely where callouts that were on the model in CATIA, NX or Creo simply didn't come through. 

• Missing significant digits on dimensional values or tolerance specs.  

That last one, missing significant digits, is perhaps the most insidious.  A dimension that was ±0.010" in the design becomes ±0.01" in the derivative document and neither the person who published it nor the machinist reading it may ever catch it. That part gets made to the wrong precision and it fails inspection. Or worse, it passes inspection and ends up in a performance-critical assembly.

Why Native APIs Are the Only Acceptable Approach for Production MBD

The fundamental difference between a reverse-engineered translator and a native CAD API-based approach is what each one has access to. 

Reverse-engineered tools work from the outside-in trying to decode an encrypted file format that wasn’t designed to be read. They're always playing catch-up as CAD vendors update their formats. And they don't have access to the CAD system's application logic, which means they struggle to correctly resolve things like parametrically defined parts, composite structures, family tables, or complex cross-section views. Those all benefit from what I'd call a runtime query of the native modeling kernel, the live geometric engine running inside of all major CAD systems that you can't replicate from a file alone. 

A native API-based approach works from the inside out. It initializes the CAD system itself as part of the import process, then extracts both the visual and the semantic representation of every PMI element directly from the source. The visual data is used to recreate a pixel-perfect replica of the PMI exactly as it appeared in the CAD system which can include the same fonts, leader lines attached to the correct faces, with every element present and every significant digit intact. The semantic data as the machine-readable intelligence behind each callout gets preserved as well, which is what makes downstream automation possible. 

The semantic PMI data is where the real MBE value gets created. When inspection planning teams attempt to use a 3D MBD model to build a bill of characteristics or generate an AS9102 First Article Inspection form, they need the PMI to be visually and semantically correct to enable structured data they can query, balloon, and reference. None of that works if the underlying PMI was approximated during import.

The Compounding Problem 

Here's what makes PMI fidelity so particularly important in a modern API-first MBE architecture.  The 3D TDP that engineering releases isn't the end of a single workflow as opposed to being the start of multiple downstream workflows. That same published document gets consumed by procurement for RFQs,  manufacturing for work instructions, and by quality for inspection planning. Every downstream service and workflow that connects to that data package depends on the PMI being correct. 

When you think about MBE as an interconnected set of microservices with each one consuming the published product definition via well-defined APIs and RESTful interfaces, bad PMI at the source propagates everywhere. A single truncated tolerance value affects every downstream process that reads and acts on that value. 

The Bottom Line 

Moving from 2D drawings to a full Model-Based Enterprise is absolutely the right direction for any manufacturing organization that wants to reduce cycle times, eliminate scrap and rework, and unlock the value of their 3D design data across the supply chain. But the returns on that investment are predicated entirely on the fidelity of the published product definition. 

Correct 3D PMI import isn't a nice-to-have. For production MBD workflows, it's the non-negotiable foundation everything else is built on. If you're evaluating solutions and you're not asking hard questions about how PMI is imported both visually and semantically through the use of native CAD APIs, you're not asking the right questions . 

Anark recognized early on that reading and importing 3D MBD/PMI data with repeatable confidence would require licensing the toolkit APIs provided by the CAD vendors themselves and integrating them into our product infrastructure. Today our native CAD API-based translators for Creo, NX, Catia, Inventor and SolidWorks are recognized as best-in-class and used by our customers to publish their 3D MBD data in mission critical workflows at scale.  

To learn more about how this all works , please see the Anark Workstation page or by all means, Contact Us as we welcome the opportunity to benchmark our solution!