NX Open Aerospace Automation: The Short Version
NX Open aerospace automation means reading model-based definition out of Siemens NX with code, so characteristics, balloons and inspection packages are generated instead of transcribed. inteliScience builds these on the NX licences you already hold, on-premise. Suppliers who ship a first article inspection per part see the manual effort drop from a working day to under an hour.
| Drawing-driven inspection | PMI read by NX Open | |
|---|---|---|
| Characteristic list | Typed from the drawing | Queried from the model |
| Balloon numbering | Manual, per revision | Generated, stable across revisions |
| A tolerance change | Model, drawing, plan, FAIR | One edit, everything regenerates |
The Problem: Ten Years of Backlog, One Day per First Article
The order book is not the constraint. At the end of April 2026 Airbus held 8,971 aircraft in backlog — roughly 10.3 years of production against its 870-delivery target for the year — and Boeing held 6,807, about 10.1 years at current rates. Airbus is still fighting engine supply to reach Rate 75 on the A320neo.
Everything downstream of that is a capacity question, and for suppliers the capacity that runs out first is not machining. It is documentation.
Consider what a first article inspection costs when it is done by hand. AS9102 requires every design characteristic to be identified, numbered and reported. Completed manually, a single FAIR can absorb a full working day per part; teams using ballooning software that links balloon numbers directly to Form 3 report the same job taking closer to ten minutes. On a 95-characteristic bracket, the labour alone has been costed at roughly $800 to $1,000 — before CMM time, and before any re-inspection.
Now multiply by a part family, by a rate increase, by every revision that resets the FAI obligation. The transcription is the cost. And transcription is the one activity where a machine is strictly better than a senior engineer, because the machine does not get bored at characteristic sixty.
NX Open, Briefly
NX Open is the programming interface to Siemens NX — rebranded to Designcenter with the June 2026 release, generally available 23 June 2026. The name changed; the API did not. Bindings exist for C++, C# and VB.NET, Java and Python, and anything you can build interactively you can build, query and modify from code.
Three capabilities do most of the work in an aerospace context, and one of them is not obvious.
Journaling turns an interactive session into executable source. A stress or manufacturing engineer who does not write software can produce a working first script by doing the job once with recording on. Every project we run starts here, because it captures what people actually do rather than what the process document says they do — and in aerospace those two things have usually drifted.
Query access to PMI and dimensions is the non-obvious one, and it is the reason automation pays in this industry at all. NX holds product and manufacturing information as structured objects under ASME Y14.41, not as text pinned to a view. Tolerances, datum references, surface specifications and geometric callouts have values a script can read. That is the difference between automation and OCR.
Knowledge Fusion carries the rules that must not be violated and re-evaluate with the geometry. For a supplier working to a customer’s design standard across multiple programmes, this is how the standard stops being a PDF that people are supposed to have read.
And a fourth, for adoption rather than capability: Block UI Styler builds native NX dialogs, so an automation shows up as a ribbon button instead of a script with a filename only its author remembers. We treat the dialog as part of the deliverable. Tools without one get used by one person and die when that person moves team.
MBD Is the Precondition, Not the Project
Model-based definition gets sold as a drawing-reduction initiative. In practice it is the prerequisite that makes everything downstream automatable, and the aerospace industry has known this for a long time. The US DoD codified drawingless technical data packages with MIL-STD-31000A back in 2013, which is what allows a 3D model alone to serve as the contractual manufacturing and inspection basis. AS9102 Rev C assumes you are working this way.
Our position, from the projects that went badly as much as the ones that went well: do not automate on top of inconsistent PMI. A generator fed by incomplete definition industrialises the incompleteness, at speed, with an audit trail proving you did it deliberately.
So the first automation is a check, not a generator. A release gate that walks every part and verifies the things your downstream tooling will depend on — every dimension carries a tolerance, every feature references a datum frame, material and finish attributes are populated, no PMI is orphaned from geometry. It takes an afternoon to write and runs in seconds per part. It is also the least glamorous item on any roadmap and the one that determines whether the rest works. That is the core of what we build as MBD and PMI compliance automation.
Not sure how complete your PMI actually is across a programme? Nobody is, until something counts it. Running the check across a part family is a days-long exercise, not a project — and the result usually reorders the roadmap.
Reading Characteristics Out of the Model
Once the definition is trustworthy, the FAI package stops being a transcription job. The script below walks the dimensions in the work part, assigns stable characteristic numbers and emits the seed of an AS9102 Form 3.
# NX Open (Python) - export dimensional characteristics as an AS9102 Form 3 seed.
# Batch: nxbatch -journal=fai_characteristics.py -part=<part.prt>
import csv
import NXOpen
def attr(obj, title, default=""):
try:
return obj.GetStringUserAttribute(title, -1)
except NXOpen.NXException:
return default
def characteristic_rows(part):
"""One row per dimension. PMI dimensions live in the same collection."""
rows = []
for index, dim in enumerate(part.Dimensions, start=1):
text = " ".join(dim.GetDimensionText()) # main text + appended text
rows.append({
"char_no": index, # stable while the model is stable
"type": dim.__class__.__name__, # LinearDimension, RadialDimension, ...
"value": text,
"view": dim.OwningView.Name if dim.OwningView else "MODEL",
"key_char": attr(dim, "KEY_CHARACTERISTIC", "N"),
})
return rows
def main():
session = NXOpen.Session.GetSession()
part = session.Parts.Work
lw = session.ListingWindow
lw.Open()
rows = characteristic_rows(part)
if not rows:
lw.WriteLine("No dimensions found - is the PMI loaded?")
return
out = part.FullPath.replace(".prt", "_form3.csv")
with open(out, "w", newline="", encoding="utf-8") as fh:
writer = csv.DictWriter(fh, fieldnames=list(rows[0].keys()))
writer.writeheader()
writer.writerows(rows)
keys = sum(1 for r in rows if r["key_char"] == "Y")
lw.WriteLine("%d characteristics exported to %s" % (len(rows), out))
lw.WriteLine("%d flagged as key characteristics" % keys)
if __name__ == "__main__":
main()Two things about this that matter more than the code. First, it runs headless through nxbatch, so it can process a whole part family overnight rather than waiting for someone to click. Second, the numbering is derived from the model, which means it is reproducible: run it again after a revision and the characteristics that did not change keep their numbers. Manual ballooning does not have that property, and re-ballooning after every revision is where a surprising amount of quality-engineering time disappears.
From here the package builds itself out. Balloons written back onto the drawing or the PMI view, Form 1 and Form 2 populated from part attributes and the assembly structure, measured values reconciled from the CMM output. The automated AS9102 first article inspection work we do for suppliers is this pipeline, hardened.
Teamcenter and the Rest of the Thread
A characteristic list living in a CSV on someone’s desktop is an improvement over typing, and not much more.
The value shows up when the same automation writes into PLM. NX Open with the Teamcenter integration can push characteristics, inspection status and revision links onto the item revision, so the inspection record is attached to the configuration it belongs to rather than to a folder. When the customer asks which revision of which part was inspected against which characteristic set, that is a query rather than an archaeology project.
The same applies upstream: the Siemens NX capabilities we implement all assume one governed definition, because the alternative — a model, a drawing PDF, an inspection plan and a FAIR that are supposed to agree — is four artefacts that will eventually disagree. In an AS9100 audit, disagreement is a finding.
Where AI Fits, and Where It Does Not
The June 2026 Designcenter release added Designcenter Copilot, a natural-language assistant grounded in Siemens documentation and the user’s current activity. Good for “how do I do this in NX”. It knows nothing about your customer’s design standard or your approved process specifications.
The case with real value in aerospace is the knowledge assistant over your own controlled documents — process specifications, customer standards, prior nonconformance dispositions, the reasoning behind decisions taken on a programme in 2017. Engineers spend hours finding this and often re-derive it instead. A retrieval system over that corpus answers in seconds.
The condition is non-negotiable, and it is the reason most aerospace AI pilots stall: every answer must cite the source document and revision. An assistant that produces a confident paragraph with no provenance is unusable when the question is “on what basis did you disposition this”. We build these with the audit trail as a first-class output, not as a logging afterthought — and, for export-controlled programmes, on hardware inside your own network using open-weight models such as Llama 3.3 70B.
For generating NX Open code itself, frontier models like claude-opus-5 are genuinely strong, and we use them daily. They also invent API calls with complete confidence — methods that do not exist, arguments in the wrong order, classes from a neighbouring namespace. Every generated script goes through an import check and a run against a reference part before a human reviews it. That loop is not optional; without it you have relocated the work rather than removed it.
A Sensible First Quarter
| Weeks | Focus | Result |
|---|---|---|
| 1–2 | Journal the FAI and release workflows; count hours per part and per revision | A business case in hours, not adjectives |
| 3–5 | Build the PMI completeness check; run it across one part family | A defect list, and a realistic view of your data |
| 6–10 | Characteristic extraction plus Form 3 generation, with a Block UI Styler dialog | FAI seed produced from the model, in batch |
| 11–13 | Write results back to Teamcenter, or extend to ballooning on the PMI views | The record attached to the configuration |
We would advise against starting with the hardest, most safety-critical family on the grounds that it hurts most. Start with the family you ship most often. Cleaner data, faster proof, and a quality department that has seen it work before you point it at something that matters more.
The other failure mode is subtler. Teams sometimes automate a process that should have been simplified first — an eleven-step release flow with two approvals nobody can justify. Automate ten of those steps and you have made a bad process fast and permanent. Spend the first week asking which steps exist because of a requirement and which exist because of a habit.
Frequently Asked Questions
How much does an NX Open FAI automation cost?
A first implementation — PMI checks, characteristic extraction, Form 3 generation, a dialog and handover — usually falls between €12,000 and €35,000. What moves the number is the state of the PMI, not the code: a family with consistent, complete definition is straightforward, while a mixed estate of legacy models needs remediation first. We size it after running the completeness check, which is a short exercise on its own.
Do we need full MBD before any of this works?
Not full, but consistent. The automation reads what is in the model, so a family where PMI is complete can be automated even if the rest of the business still issues drawings. What does not work is partial PMI on the same parts you are automating — that produces silently incomplete characteristic lists, which is worse than typing them.
NX Open or a commercial ballooning tool?
If your need is standard ballooning on drawings and your data is tidy, a commercial tool is cheaper and faster to deploy — we say so regularly. NX Open earns its place when the logic is yours: customer-specific numbering, key-characteristic rules from a design standard, writing back into Teamcenter, or reconciling against a CMM output format nobody else supports.
Will this satisfy an AS9100 audit?
The automation does not change what is required; it changes how consistently you produce it. Auditors tend to respond well to generated evidence because it is reproducible and the generation logic is inspectable. Keep the ordinary controls — scripts under source control, changes reviewed, nothing writing to a released baseline without approval — and document the data flow as part of the delivery.
Can it run without an NX seat per user?
The automation needs an NX licence to execute, but not one per person. Batch execution through nxbatch on a server runs against the licences you already hold, which is how most of our customers deploy the overnight jobs. Interactive tools with a dialog do consume the user’s session, since they run inside NX by design.
Next Step
Bring one part family and the last FAI package you produced by hand. An hour is enough to work out what is automatable, what needs data remediation first, and what it costs.
Talk to our engineers about automating your MBD and inspection workflow
