MBD/PMI Compliance Automation for Siemens NX

The drawing is gone. The work is not — it moved into the model, and it’s still done by hand.

Boeing and Airbus stopped sending drawings years ago. What suppliers receive — and must deliver back — is Model Based Definition: 3D models carrying PMI as the single source of truth. And this is not a preference, it is an audited requirement: Boeing’s D6-51991 defines how a supplier must handle Digital Product Definition data, and your DPD approval — the thing your aerospace revenue hangs on — is examined against it.

Inside the design office, MBD replaced one kind of manual labour with another. Instead of drawing views and dimension lines, your NX users now author hundreds of PMI objects per part — semantically correct, to works standard, to customer spec — and check all of it by eye before release. It is exactly the kind of structured, rule-governed routine that should never have been manual in the first place.

We build the toolset that automates it, natively in Siemens NX: rule-based PMI authoring for standard features, automated compliance checks against customer and works requirements, and an AI layer that turns spec documents into executable rules — and check findings into plain-language fixes.

// MBD by hand, in numbers

PMI objects on a typical machined part — each authored and eye-checked today

of design time spent on annotation and documentation instead of geometry

D6-51991

the Boeing spec every DPD supplier is approved — and re-audited — against

seconds

for rule-based authoring of standard-feature PMI that takes minutes each by hand

Semantic PMI is a data discipline — enforced by your customer’s auditors

The trap of MBD is that it looks like drafting but behaves like data. A dimension that is merely “drawn” onto the model — graphic, not semantic — reads fine to a human and is invisible to every downstream consumer: CAM, CMM programming, first article inspection, the customer’s automated intake checks. A datum reference that points nowhere, a tolerance missing its feature association, a note that contradicts the works standard — none of it looks wrong on screen, and all of it surfaces later: in the derivative, in the FAI, or in the customer audit that decides your DPD status.

So design offices compensate the way they always have: senior eyes, checklists, four-eyes reviews before every release. It works, mostly — at the price of your most experienced people spending their days verifying hole callouts. And it scales exactly as badly as every manual quality gate scales.

The fix is the same one that transformed software development: make the routine automatic and the checks executable. Author the recurring 80 percent of PMI by rule, validate every model against machine-readable requirements before release — and reserve human judgement for the part of GD&T that actually is judgement.

// Pre-release compliance check — example model, rev B

47 rules evaluated · customer MBD spec + works standard · run before Teamcenter release

PASS

CHK-012 · All hole callouts semantic and feature-associated — 34 of 34

PASS

CHK-019 · Datum features referenced by at least one FCF — A, B, C consistent

WARN

CHK-031 · General tolerance note cites works standard rev E — rev F released last month

FAIL

CHK-007 · Surface finish on functional face F12 is a graphic annotation — not machine-readable

In plain language: the Ra 0.8 symbol on the bearing seat is "painted on" — CAM and CMM won't see it, and the customer's automated intake check will reject the dataset. Prepared fix: replace with semantic surface-finish PMI bound to face F12 — one click to apply, then re-check.

One toolset, three layers — all native to NX

Everything runs inside your existing Siemens NX and Teamcenter landscape, built on supported extension points — the NXOpen PMI API and Check-Mate — so it survives NX upgrades instead of dying with them. The three layers build on each other, and each pays off on its own:

LAYER 1 — AUTHOR

Rule-based PMI authoring for standard features

Holes, threads, fits, chamfers, standard faces: the toolset recognizes the feature and authors the PMI — callout per works standard, default tolerance from your design guideline, semantically bound to the geometry, placed on the right view. Minutes of routine per feature become seconds, and every callout comes out identical, which is precisely what your customers' automated checks want to see.

NXOpen PMI APIFeature recognitionWorks-standard callouts

LAYER 2 — CHECK

Compliance checks before every release

Custom Check-Mate rules validate the model against customer MBD specs and works standards: PMI semantic and feature-associated, datums consistent, notes at current revision, completeness per part class. The result is the report your senior engineers currently produce by eye — generated on every save, attached to the Teamcenter release workflow as a gate.

Check-Mate custom checksTC release gatePer-customer rule sets

LAYER 3 — AI

Specs become rules. Findings become fixes.

The historic bottleneck of check systems was never the checking — it was authoring and maintaining the rules. This is where the LLM earns its place: it drafts executable check rules from customer MBD spec documents and works standards (your engineers review and release them), keeps rule sets aligned when a spec revision changes, and translates every check finding into plain language with a prepared fix — so the youngest designer understands what the auditor would have flagged.

LLM rule authoringSpec-revision diffingPlain-language fix copilot

When does MBD automation pay off?

The case is strongest where customer MBD requirements meet real part volume. You are a candidate if most of these apply:

You hold — or need — a Boeing DPD approval (D6-51991) or deliver MBD datasets to Airbus and other OEMs with equivalent requirements.
Your NX users spend hours per part authoring and checking PMI that follows known patterns.
MBD findings surface late — in customer intake checks, FAI, or audits — instead of before release.
Senior engineers act as human release gates, eye-checking models their juniors annotate.
Customer MBD specs change revisions faster than your internal checklists follow.
You run Siemens NX with Teamcenter and want automation on supported extension points — not a parallel island tool.

What the toolset is built on

Supported Siemens extension points and open interfaces — plus integration with the validation tools your customers already trust.

NXOpen PMI API Semantic PMI Check-Mate custom checks Feature recognition Teamcenter release workflow JT / STEP AP242 pipeline Customer MBD spec rule sets LLM rule authoring (on-prem) CADIQ / Capvidia integration

Before and after: the same part, released twice

A machined structural part with 120 PMI objects, delivered as an MBD dataset to an OEM customer. Here is where the hours and the risk sit on each side of the change:

Before — authored & eye-checked

120 PMI objects authored one by one — 4–6 h
Senior four-eyes review against checklist — 1–2 h
Graphic-only annotation slips through — looks fine on screen
Customer intake check rejects the dataset — rework, delay, explaining
Audit season: nervous weeks of self-checking old releases

After — generated & gate-checked

Standard-feature PMI authored by rule — minutes
Engineer authors the functional GD&T — the part that is judgement
47 compliance rules run at release — findings with prepared fixes
Dataset passes customer intake first time — semantically clean
Audit season: the check reports are the preparation

Why inteliScience — and what we deliberately don’t promise

This toolset is NXOpen engineering plus executable rules plus an LLM layer — which is to say, it is exactly what we do all day. We build NX and Teamcenter customizations on Siemens’ supported extension points, so your automation survives the next NX release, and we have the AI engineering to make rule authoring cheap instead of the project-killer it used to be.

Three honest boundaries, because aerospace buyers deserve them. First: the toolset does not design your GD&T scheme. Which datums, which functional tolerances — that is engineering judgement, and it stays with your engineers; the automation covers the routine 80 percent and checks everything. Second: a DPD approval is a process approval, not a software feature — our toolset makes the tooling side audit-ready and your releases consistently clean, but the QMS work remains yours. Third: derivative validation (model vs. STEP/JT comparison) is established specialist territory — tools like CADIQ and Capvidia are what your customers already trust, so we integrate with them instead of rebuilding them badly.

What you get from us is the part nobody else offers: the works-specific automation layer inside NX that makes MBD cheap to author and hard to get wrong.

Many teams need the method before the automation: our MBD consulting starts with a readiness assessment, our NX PMI training gets designers productive, and MBD vs PMI explains where one ends and the other begins.

Fixed price — no day rates, no surprises

MBD Toolset Pilot

€20,500 fixed

One part family — PMI-authoring automation for your top 5 standard feature types
10 compliance checks derived from one customer MBD spec + your works standard
Measured on 3 real part models — authoring time and findings, your numbers
Plain-language finding reports — the AI fix copilot in action on your parts
Rollout blueprint: rule-set governance, Teamcenter release gate, more part families

Start the pilot conversation

6–8 weeks · built on your NX installation · rules and code are yours, whatever you decide afterwards.

For comparison

The cost of manual MBD

10 NX users × ~30% of their time on routine annotation and eye-checking
Rejected datasets and FAI findings — rework nobody budgets for
And the un-priced risk: a DPD audit finding that questions supplier status

Frequently asked questions

Does the toolset design our GD&T for us?

No — and we consider that a feature, not a gap. Choosing datums and functional tolerances is engineering judgement about how the part works; automating it badly is how you fail audits. The toolset authors the routine PMI (standard features, works-standard callouts, notes), checks everything against executable rules, and leaves the functional GD&T scheme to your engineers — who now have the time for it, because the routine is gone.

Will Boeing or Airbus accept rule-generated PMI?

Customers see released PMI in a released model, signed off by your engineer — how it was authored is invisible and irrelevant to them, exactly as it was when macros filled your drawing title blocks. What customers do see is the effect: semantically clean, uniform datasets that pass automated intake checks the first time. Consistency is precisely what generated PMI is better at than hand-authoring.

Does this get us the Boeing DPD approval?

No tool gets you a DPD approval — D6-51991 approval is granted for your processes, training and configuration control, and the QMS work is yours. What the toolset changes is the hardest technical part of that story: demonstrably consistent PMI authoring, executable compliance checks as a release gate, and check reports as audit evidence. Suppliers with that in place walk into DPD audits with documentation instead of nerves.

How do customer MBD specs become check rules — and who maintains them?

The LLM drafts rules from the spec document; your engineers review, correct and release them — the same human-in-the-loop split as everywhere in our work. When the customer publishes a new spec revision, the AI diffs it against the rule set and proposes updates. Rules live version-controlled and documented, and your team learns to maintain them; with LLM assistance that no longer requires a dedicated developer.

How does this relate to CADIQ or Capvidia — do we still need them?

If your customer mandates derivative validation (native model vs. STEP/JT comparison), those tools remain the right answer — they are the established, customer-trusted standard, and we integrate with them rather than imitating them. Our toolset works upstream of that: it makes sure the native NX model is right before anything is derived, which incidentally makes the validation runs boring — the best thing a validation run can be.

We still deliver drawings for some customers. Does the toolset help there too?

Yes. Semantic PMI is the master either way — NX derives drawing annotations from it, so rule-authored PMI feeds both worlds during the transition. Many suppliers use exactly this as their migration path: automate PMI now, keep serving drawing customers from the same source, and switch each program to model-only delivery when the customer does.

Your next DPD audit is already scheduled. Make the check reports your preparation.

Send us one part model and the customer MBD spec it must satisfy — we'll show you the authoring automation and the first ten checks running on your own data.

Talk to an MBD Automation Engineer

Always here to support you – reach out to us with your questions, and we’ll guide you every step of the way.

Phone: +40 774 463 429
Our Location: Str. Ploiești 9, 400157
Cluj-Napoca, Romania
Email: info@inteliscience.net
LinkedIn: inteliScience on LinkedIn
YouTube: inteliScience on YouTube