NX Open for Defence: The Short Version
NX Open for defence means driving Siemens NX from code — Python, C#, C++ or Java — so variant design, configuration records and inspection data are generated rather than typed. inteliScience builds those automations to run on-premise or fully air-gapped, inside export-controlled networks. In our projects the manual hours per configuration change fall by 50–70%.
| Interactive NX workflow | NX Open automation | |
|---|---|---|
| Variant of an existing assembly | Hours of manual editing | Minutes, driven by a spec file |
| Configuration evidence | Assembled afterwards by hand | Written at save time, per part |
| Where the AI runs | Vendor cloud, if at all | On your hardware, no egress |
The Problem: A Production Ramp Bolted to 30-Year Configuration Control
Europe is buying at a pace its engineering departments were never sized for. NATO’s Hague summit replaced the 2% target with 5% of GDP by 2035 — 3.5% core defence plus 1.5% defence-related — and for 2026 the European Allies and Canada are budgeting roughly USD 634 billion, about 2.53% of combined GDP. The EU’s Readiness 2030 plan puts up to €800 billion behind the same curve, and on 3 July 2026 the European Commission proposed five large-scale Defence Projects of Common Interest to attack the capacity side directly.
The physical side of that ramp is visible: EU ammunition output went from roughly 300,000 rounds a year in 2022 to an estimated two million by the end of 2025. The engineering side has not moved nearly as fast, and the recurring complaint from programme offices is not machine tools. It is qualified engineers, programme managers and the paperwork that a defence change order drags behind it.
That is the part nobody budgets for. A single tolerance change on a fielded assembly touches the model, the drawing, the inspection plan, the interchangeability statement, the configuration baseline and the evidence package owed to the customer. Multiply that by a variant tree that has to stay auditable for thirty years, and the bottleneck is not design work. It is transcription.
Transcription is exactly what an API is for.
What NX Open Actually Is
NX Open is Siemens’ programming interface to NX — the same platform that Siemens rebranded to Designcenter with the June 2026 release, generally available 23 June 2026. The rename changed the badge, not the API surface, and the Siemens NX capabilities we deliver sit on the same interface they always did. Every entity you can create by hand — a body, an expression, a PMI annotation, an assembly component, a CAM operation — you can create, read and modify from code.
Four things matter for defence work specifically:
Language coverage. NX Open ships bindings for C++, C# and VB.NET, Java and Python. Python is the fastest route to a working automation and needs no compiler on the target machine — which matters when the target machine sits inside an accredited enclave where you cannot casually install a toolchain. C++ stays relevant for compute-heavy geometry work and for code you want distributed as a compiled artefact rather than readable source.
Journaling. NX records your interactive session as source code. Do the operation once by hand with journaling on, and you get a working script that reproduces it. This is the single most underrated feature in the whole platform: it turns a domain expert who does not write software into someone who can produce a first draft of an automation in ten minutes. Our engineers start almost every NX Open project this way — record, then refactor the recording into something parameterised and defensible.
Block UI Styler. Automation that only runs from a command line gets used by three people. Block UI Styler builds native NX dialogs — the same widgets, the same look — so the automation appears as a button in the ribbon instead of a script someone has to remember. If you want adoption inside a design office, budget for the dialog.
Knowledge Fusion. Rule-based engineering embedded in the part itself. Where NX Open is procedural code you execute, Knowledge Fusion is declarative rules that live with the geometry and re-evaluate when inputs change. For defence, that is how you encode a design standard so it cannot be quietly violated: the rule travels with the model into the next programme, the next contractor, the next decade.
Our clear position: start with journaling and Python, not with an architecture document. The projects that stall are the ones that spend six weeks choosing a language before automating anything.
Configuration and Traceability: Generate the Evidence, Don’t Type It
The highest-value first automation in a defence engineering office is almost never a geometry generator. It is the thing that writes down what was built.
STANAG and DEF STAN frameworks, and the NATO-aligned configuration management practice around them, all demand the same thing: at any point in a thirty-year life, you can prove which revision of which part went into which serial-numbered assembly, and why. Most organisations satisfy this with a spreadsheet maintained in parallel to the CAD. The spreadsheet is where the audit findings come from.
An NX Open script walking the assembly and emitting the record directly from the model removes the parallel copy entirely:
# NX Open (Python) - emit a configuration record for the open assembly.
# Run with the assembly open as work part (Developer tab > Journal > Play).
# For nightly runs, open each assembly first and start the journal with run_journal.
import csv
import NXOpen
ATTRS = ["DB_PART_NO", "DB_PART_REV", "MATERIAL", "NATO_STOCK_NUMBER", "EXPORT_CLASS"]
def attr(obj, title):
"""Return a user attribute as text, or an explicit gap marker."""
try:
return obj.GetStringUserAttribute(title, -1)
except NXOpen.NXException:
return "<missing>"
def walk(component, level, rows):
for child in component.GetChildren():
proto = child.Prototype # the Part behind the occurrence
rows.append([level, child.DisplayName] + [attr(proto, a) for a in ATTRS])
walk(child, level + 1, rows)
def main():
session = NXOpen.Session.GetSession()
work_part = session.Parts.Work
root = work_part.ComponentAssembly.RootComponent
if root is None:
session.ListingWindow.Open()
session.ListingWindow.WriteLine("Not an assembly - nothing to record.")
return
rows = []
walk(root, 0, rows)
out = work_part.FullPath.replace(".prt", "_config.csv")
with open(out, "w", newline="", encoding="utf-8") as fh:
writer = csv.writer(fh)
writer.writerow(["level", "component"] + ATTRS)
writer.writerows(rows)
gaps = sum(r.count("<missing>") for r in rows)
session.ListingWindow.Open()
session.ListingWindow.WriteLine("%d components written to %s" % (len(rows), out))
session.ListingWindow.WriteLine("%d attribute gaps flagged for review" % gaps)
if __name__ == "__main__":
main()Two details make this useful rather than decorative. It can run headless: started with run_journal once the assembly is open, it can be a nightly job over the whole programme directory, not something an engineer remembers to click. And it reports gaps instead of silently writing blanks, so missing export classifications surface as a number on a dashboard rather than as a finding during an audit.
Push the same record into Teamcenter and the CSV becomes unnecessary: NX Open and the Teamcenter integration let the automation write the attributes back to the item revision, so the PLM system holds the baseline and the model stays the single source. That is the version we build for customers already running Teamcenter; the file-based version is for programmes that are not there yet.
Sitting on a variant tree nobody can fully account for? That is the normal starting point, not a confession. We map it and automate the evidence layer first — see how we handle configuration and traceability for STANAG programmes.
MBD and PMI: Machine-Readable Definition Under Export Control
Model-based definition is not a drawing-reduction project in defence. It is the mechanism that lets automation read the design intent at all.
PMI in NX is structured product definition under ASME Y14.41, not annotation pinned to a view. Dimensions, tolerances and datum references are objects with values a script can query. The US DoD codified drawingless technical data packages with MIL-STD-31000A in 2013, and the practical consequence is that a 3D model alone can be the contractual manufacturing and inspection basis — provided the PMI is complete and consistent.
Complete and consistent is where the automation earns its money. A rule that checks every released part for a datum reference frame, a surface finish specification and a material attribute takes an afternoon to write with NX Open and runs in seconds per part. Enforced at release, it means the downstream automations — inspection planning, CAM, the configuration record above — never have to guess.
There is also an unglamorous reason MBD matters for defence: distribution control. A drawing PDF leaves the system and stops being governed. A model in Teamcenter with PMI and an export classification attribute carries its own handling rules. When your obligation is to prove that ITAR- or EU-dual-use-controlled definition never reached the wrong network, one governed artefact beats four copies.
Running AI Inside the Fence
The June 2026 Designcenter release added Designcenter Copilot, a natural-language assistant grounded in Siemens documentation, recommended practice and the user’s current activity. It is genuinely useful for the “how do I do X in NX” question that currently costs a senior engineer twenty interruptions a week.
For a defence programme it also raises the only question that matters: where does the prompt go?
Our position here is firm, and it is the same one we give every defence customer. Vendor copilots are fine for platform know-how. They are not where your part geometry, your configuration baselines or your programme documentation belong. Anything touching controlled technical data runs on hardware you own, on a network you control, with no egress — and if the accreditation says air-gapped, air-gapped means the model weights are on the box, not behind a VPN.
That is buildable today, and the shape is boring in a good way:
- Open-weight models running on-premise — Llama 3.3 70B for retrieval and drafting, Qwen2.5-Coder-32B where the job is generating NX Open code — served on a GPU node inside the enclave.
- A retrieval index over the material that actually holds the answers: design standards, programme specifications, prior configuration decisions, historical change rationale.
- Every answer citing the source document and revision, because an assistant that cannot show its evidence is unusable in a regulated environment.
- A human approving anything that writes to the model or the PLM system. AI proposes the NX Open script; an engineer reads it and runs it.
Where cloud is permitted — training material, non-controlled internal tooling, code that never sees programme data — frontier models such as claude-opus-5-5 write better NX Open than anything you can run on a single node, and we use them for exactly that. The line is the data, not the technology.
One caution from experience: LLMs hallucinate NX Open API calls with total confidence. Methods that do not exist, arguments in the wrong order, classes from a different namespace. Any generated automation goes through a compile-or-import check and a run against a reference part before a human ever reviews it for logic. Without that loop you are not saving time, you are moving it.
Obsolescence and the Thirty-Year Data Problem
Long-lifecycle programmes have a second, quieter automation case: the archive.
DMSMS — diminishing manufacturing sources and material shortages — is treated as inevitable rather than exceptional in defence sustainment, and the updated DoDI 4245.15 (Change 1, September 2025) pushed it further from “find a replacement when it fails” toward proactive lifecycle risk management. European OEMs under STANAG and DEF STAN carry equivalent supply-continuity obligations.
Proactive management needs a queryable picture of what you actually have. In most naval and land programmes, that picture is thirty years of scanned drawings, a part-number scheme that changed twice, and three engineers who remember the rest.
The automation here is a two-stage pipeline rather than a script. Vision models read the legacy drawings and extract part numbers, materials, specifications and referenced standards; NX Open reconciles that extraction against the live NX and Teamcenter data and flags the mismatches. What comes out is a list — components whose specified material is no longer produced, parts referencing withdrawn standards, assemblies where the model and the archived drawing disagree. That list is the input to obsolescence planning, and it did not exist before because nobody could afford to produce it by hand. The drawing and obsolescence mining pipeline we run for naval programmes is built exactly this way.
A Realistic First 90 Days
We would advise against a platform programme. Automation in defence engineering succeeds by shipping one narrow thing into production and letting the next case be pulled by the people who used it.
| Weeks | What happens | What exists at the end |
|---|---|---|
| 1–2 | Record journals over the three most repeated workflows; measure the manual hours | A ranked list with hours attached, not opinions |
| 3–6 | Build the highest-value automation as a Block UI Styler command; run it in batch overnight | One tool in the ribbon, one nightly job |
| 7–10 | Add the release-time PMI and attribute checks; wire results into Teamcenter | Bad data stops entering the baseline |
| 11–13 | Stand up the on-premise retrieval index over standards and programme documents | An assistant with citations, inside the fence |
The order is deliberate. Checks before generators, because generating variants from inconsistent source data industrialises the inconsistency. And the AI layer last, because a retrieval index over documents nobody trusts returns answers nobody trusts.
Two things reliably kill these projects. The first is a script written by one engineer who then changes team — hence Block UI Styler, source control and a second person who can read the code. The second is automating a process that should have been simplified first. If a workflow takes eleven steps because of an approval nobody remembers introducing, automate ten of them and you have made the wrong process faster.
Frequently Asked Questions
Can NX Open run inside an air-gapped network?
Yes. NX Open executes locally in the NX process or through run_journal on the same machine — no external service is involved, so an accredited enclave changes nothing about how the automation runs. The only component that needs planning is the AI layer, because that requires model weights and a GPU node inside the boundary rather than an API endpoint.
How much does an NX Open automation project cost?
A single well-scoped automation — one workflow, a Block UI Styler dialog and batch capability — generally lands between €8,000 and €25,000 depending on how much of the source data has to be cleaned first. Programmes with a large legacy archive cost more in the discovery phase than in the coding. We size it after the journaling exercise, not before.
NX Open or Knowledge Fusion — which should we use?
Different jobs. Knowledge Fusion holds rules that must travel with the part and re-evaluate when inputs change, which is what you want for design standards enforced across a supply chain. NX Open is for procedural work: batch processing, generating documents, talking to Teamcenter or an external system. Most defence automations we build use both, with Knowledge Fusion carrying the constraints and NX Open orchestrating.
Will an LLM just write our NX Open scripts for us?
Partly, and not unsupervised. Current models produce a solid first draft of an NX Open script and then invent API calls that do not exist in the namespace they claim. The workable pattern is generate, import-check against the real API, run against a reference part, then human review. That is still much faster than writing from scratch — it just is not hands-off.
Does automating NX affect our export control or accreditation position?
It usually improves it, because generated evidence is more consistent than hand-maintained evidence. The controls to keep are the ordinary ones: automations under source control, changes reviewed, nothing writing to a released baseline without approval, and no component of the toolchain calling out of the network. We document the data flows as part of delivery so the accreditation conversation has something to reference.
Next Step
You do not need a strategy to find out whether this applies to you. You need one hour with the three workflows your engineers repeat most.
Talk to our engineers about NX Open automation for your programme