PMI Authoring Automation at a European Automotive OEM – MBD Rules, NX Open Automation and a Method 300+ Designers Work To
PMI authoring automation replaced the manual part of model-based definition for more than 300 design engineers at a European automotive OEM. inteliScience SRL built the MBD rule set, the NX Open automation behind it and the PMI methodology the design organisation now works to — over 18 months, across two Siemens NX version changes.
More than 300 design engineers at a European automotive OEM author PMI to an automated rule set built by inteliScience SRL, and the client design methods organisation reports that PMI authoring previously took about 40 percent longer than it does today. The work covered three things that only pay off together: the MBD rules themselves, NX Open automation that applies them inside Siemens NX, and a written PMI methodology the organisation can maintain. The client describes the result as lower cost, more consistent models, and a concrete step toward full MBD.
LAST UPDATED AUGUST 18, 2026 · FIGURES RELEASED BY THE CLIENT FOR ANONYMOUS PUBLICATION
- Client
- European automotive OEMNOT NAMED
- Sector
- Automotive
- Users
- More than 300 design engineers
- Scope
- MBD rules, NX Open automation, PMI and MBD methodology
- Duration
- 18 months
- Environment
- Siemens NX, two NX version changes during the project
- Our role
- Rules, automation and methodology — inteliScience SRL
The situation: model-based definition moved the work, it did not remove it
The design organisation was moving toward model-based definition. That move deletes the drawing, but it does not delete the annotation work — it moves it into the model. Instead of dimensioning views, designers author PMI: dimensions, tolerances, datums, surface finishes and notes, each of which has to satisfy the works standard and the internal methodology before a model is released.
Done by hand, that work is both slow and inconsistent. It is slow because a designer authors the same recurring callouts on every part, one at a time. It is inconsistent because two experienced designers will annotate the same feature slightly differently, and both versions look correct on screen. For industry context: in a 2022 survey by parts data vendor CADENAS covering more than 100,000 engineers and designers, nearly half reported spending at least an hour every working day searching for parts alone — routine lookup is a large, well-documented share of a design engineer’s day, and PMI authoring is exactly that kind of routine.
Inconsistency is the expensive half. Downstream, PMI is not decoration: CAM, CMM programming and inspection read it. A callout that is not semantically bound to its feature is invisible to all of them, and the error surfaces late — in manufacturing, not at release.
What changed in the working day
- manualAuthor every recurring callout by hand, part after part
- manualLook up the applicable works standard rule while authoring
- by eyeCheck completeness and semantic binding visually before release
- variesTwo designers annotate the same feature two defensible ways
- lateErrors surface downstream in CAM, CMM or inspection
- by ruleRecurring callouts are generated from the MBD rule set
- encodedThe works standard lives in the rules, not in memory
- uniformThe same feature produces the same PMI, on every part
- judgementDesigners spend their time on functional tolerancing
- documentedMethodology is written down and maintained by the client
What the client reports
The figures below come from the client design methods organisation and were released for anonymous publication. They are what that organisation observes in its own work, not a controlled study — the stamps say so.
Released by the client design methods organisation for anonymous publication.
Effort to author PMI on a model
client-confirmed The client reports PMI authoring previously took about 40 percent longer than today, for the same tasks in the same design organisation. Shown as an index because 40 percent more time before corresponds to about 29 percent less time after.
Design engineers working to the automated rule set
client-confirmed Rollout across the design organisation, not a pilot group.
Consistency of PMI across parts
client-confirmed Qualitative statement, no metric attached — described by the client as better quality and a concrete step toward full MBD.
How does automating PMI authoring actually work?
Automating PMI authoring works in three layers, and skipping any one of them is why such projects usually stall. The rules have to be written down before they can be coded, the automation has to live on supported Siemens NX extension points so it survives upgrades, and the methodology has to belong to the client so it outlives the project.
The works standard becomes an explicit rule set
Before anything can be automated, the conventions have to exist as rules rather than as habits: which callout applies to which feature class, which default tolerance the works standard prescribes, how a note is phrased, what a released model must contain. Writing that down with the client method owners was the first half of the project and the part that made the rest possible.
OUTPUT — an MBD rule set the client owns and can extendNX Open applies the rules inside Siemens NX
The automation recognises the feature, selects the applicable rule and authors the PMI semantically bound to the geometry, in the right view, phrased to the works standard. It runs on the NX Open API — a supported Siemens extension point rather than a parallel island tool, which is why two NX version changes did not end the project.
OUTPUT — recurring callouts generated instead of typedA written method the organisation maintains itself
Automation without methodology decays: the rules drift, nobody knows why a callout looks the way it does, and the next standard revision breaks it quietly. The project therefore delivered the PMI and MBD methodology as documentation and training for the client method owners, so the rule set is maintained inside the organisation rather than by us.
OUTPUT — 300+ designers working to one documented methodWhat the solution is built on
Supported Siemens extension points and the client’s own standards. Nothing that dies with the next NX upgrade.
Related work on the same ground: MBD and PMI compliance automation for Siemens NX and NX Open custom tool development.
Two NX version changes in 18 months
Over the 18 months of the project the client moved through two Siemens NX version changes. For automation that touches PMI, that is the moment such tools normally die. This one did not, for one unglamorous reason: it is built on the NX Open API rather than on recorded interactions or undocumented internals, so a version change meant a regression run and a handful of adjustments instead of a rewrite. Any team evaluating NX automation should ask about this specifically — a tool that cannot survive an upgrade is a rental, not an asset.
What we would do differently
We would spend longer on the rule set before writing code. The first automation rounds encoded conventions that the method owners had described confidently but that turned out to have exceptions nobody had documented — a feature class where a different tolerance applies, a note phrased differently for one product line. Each exception surfaced as a bug report against the automation when it was really a gap in the rules. Running a short, deliberate rule review with two or three real part families first would have moved that discovery weeks earlier and made the automation phase calmer.
When does automating PMI authoring pay off?
Automating PMI authoring pays off when the same callouts are authored repeatedly against a written standard, by enough people that inconsistency has a cost. In our experience the case is strong when a design organisation runs model-based definition seriously rather than as a pilot, when recurring feature classes make up a large share of annotation work, and when downstream consumers — CAM, CMM, inspection, suppliers — actually read the PMI. It is a poor fit when the works standard exists mostly as tribal knowledge: the honest first project is then writing the rules down, and automation comes after.
MBD consulting and NX PMI training cover the two steps before automation: a written rule set and designers who apply it.
Frequently asked questions
Why is the client not named?
Does the automation replace the designer?
What happens at the next NX version change?
How long does a project like this take?
When would this not be worth it?
Your designers’ judgement is excellent. Stop spending it on repeat callouts.
Send us one part family and the section of your works standard that governs it — we will show you how much of that PMI is rule-governed, on your own models.
Talk to an MBD Automation Engineer