NXOpen vs Knowledge Fusion: The Short Version
NXOpen vs Knowledge Fusion is a choice between two update models, not two syntaxes. Knowledge Fusion rules live inside the NX update mechanism and re-evaluate themselves when geometry changes; NXOpen code runs only when called. inteliScience ships both on NX 2606 and picks by change frequency, team skills and who maintains the result in five years.
| Knowledge Fusion | NXOpen | |
|---|---|---|
| Runs when | NX updates the part | You call it |
| Lives in | The part file, as rules | A journal or compiled add-in, outside the part |
| Strongest at | Geometry that must stay consistent through change | Batch work, PLM integration, anything outside modelling |
| Hardest part | Finding people who can read it in 2031 | Re-running it after every design change |
The Problem: You Are Choosing an Update Model, Not a Language
Most teams start this comparison in the wrong place — at syntax. They look at a Knowledge Fusion DFA file, decide it looks unfamiliar, and reach for NXOpen because Python is Python. Six months later the automation works beautifully and nobody runs it, because running it is a manual step that competes with a designer’s deadline.
The actual question is when your automation executes.
Knowledge Fusion is a rule-based language that hooks directly into the NX update mechanism. Siemens is explicit that this lets KF do things NXOpen cannot: a KF rule is part of the part, and when NX updates the model, the rule re-evaluates and the geometry follows. Nobody presses a button.
NXOpen is the programmatic API — C++, C#, VB.NET, Java and Python — and it does what you tell it, when you tell it. It can reach Teamcenter, walk an assembly, write a drawing, batch-process a thousand parts overnight. It cannot sit inside the part and wake up when a face moves.
That distinction decides more than any benchmark. And it is worth deciding deliberately: estimates put up to 40 percent of engineering time into repetitive CAD work, worth more than 17,000 USD per engineer per year in lost productivity — the kind of number that makes automation obvious and the choice of automation model expensive to get wrong.
What Knowledge Fusion Does That NXOpen Cannot
Knowledge Fusion holds design intent as a live relationship instead of a one-time result. Declare that the mounting hole diameter depends on plate width, and that dependency survives every revision, every user and every session. An NXOpen script that computes the same diameter produces a number, writes it once, and then the model and the rule drift apart the moment someone edits the plate.
For variant design this is the whole game. A transformer, a switchgear cubicle, a gearbox housing — the geometry differs per order, but the relationships do not. Encoding relationships once and letting NX enforce them is structurally different from re-running a script and hoping someone remembered.
KF also gets deployed more widely than most teams realise. Executing Knowledge Fusion applications is included with all NX Mach Series solutions as a runtime licence; only the authoring capability, Knowledge Fusion Author, is a separate NX Mach Series add-on module. Practically, that means a company can write rules with two or three trained specialists and roll the result out to every seat without buying anything extra for the consumers.
Our position, plainly: if the automation’s job is to keep geometry correct through change, KF is the right tool and NXOpen is a workaround.
Where Knowledge Fusion Costs You
Knowledge Fusion is slow, brittle around file references, and increasingly hard to staff — three costs that do not show up in a proof of concept and dominate year three.
The performance issue is structural, not an implementation detail. KF is demand-driven: before it creates any geometry it has to resolve the demand order of child objects, which is why KF classes carry demandOrder specifications at all. On a small part nobody notices. On a large assembly with deep rule chains, engineers notice every update.
The brittleness shows up in maintenance. Rules that reference part file names have to be edited whenever a file is renamed — rename a.prt to b.prt and the rule that pointed at it is now wrong. That is a small annoyance in a pilot and a real problem in a PLM-managed estate where renaming and revising are routine.
Then there is the part nobody planned for. KF’s DFA syntax is a Siemens-specific language with a small practitioner community, no package ecosystem and almost no presence in the training data of modern coding assistants. Ask claude-opus-5 to write an NXOpen Python journal and you get something close to runnable; ask it for a non-trivial DFA class and you mostly get confident nonsense. In 2026 that gap is a genuine cost factor, because it changes how fast a new team member becomes productive.
Ready to see it applied to real variant work? Our write-up on automating transformer variant design in NX walks through what a rule-driven order-to-model pipeline looks like in practice.
NXOpen vs Knowledge Fusion: Eight Criteria That Actually Differ
| Criterion | Knowledge Fusion | NXOpen |
|---|---|---|
| Execution trigger | Automatic, on NX update | Manual, scheduled or event-driven |
| Scope | Inside the part and its geometry | Whole NX session, Teamcenter, filesystem, network |
| Languages | KF / DFA only | C++, C#, VB.NET, Java, Python |
| Licence to author | KF Author add-on module | Python and .NET journals need no developer licence; C/C++ and Java do |
| Licence to run | Runtime included in NX Mach Series | Journal runs on any seat; add-ins need signing |
| Performance profile | Demand-driven, slows on deep rule chains | Runs at the speed you write it |
| Debugging | DFA Manager syntax check, limited tooling | Standard IDEs, breakpoints, unit tests, version control |
| Hiring and AI support | Small specialist pool, weak LLM coverage | Large pool, strong LLM coverage |
Two rows deserve emphasis because they decide most real projects. Scope: if the automation has to talk to Teamcenter, read an order from ERP or produce a drawing package, KF cannot reach that far and the question is settled. Debugging: NXOpen code sits in Git, runs under a debugger and can be unit-tested; KF gets a syntax check. Over a five-year maintenance horizon that difference compounds.
The Same Rule, Written Both Ways
Here is the difference in ten lines. Both examples are trimmed for the article, and both express the same intent: hole diameter depends on plate width.
Knowledge Fusion declares the relationship and lets NX maintain it:
#! NX/KF 12
DefClass: mounting_plate (ug_base_part);
(Number Parameter) plate_width : 250;
(Number Parameter) plate_height : 180;
# The dependency IS the rule. NX re-evaluates it on every update.
(Number) hole_dia : if (plate_width > 200) then 12 else 8;
(Child) plate@ : {
Class, ug_block;
Length, plate_width;
Width, plate_height;
Height, 10;
};NXOpen computes the same value, once, and then stops caring:
# NXOpen Python journal, tested on NX 2606
import NXOpen
def main():
session = NXOpen.Session.GetSession()
work_part = session.Parts.Work
plate_width = work_part.Expressions.FindObject("plate_width").Value
hole_dia = 12.0 if plate_width > 200.0 else 8.0
# Writes the value now. If plate_width changes tomorrow,
# nothing re-runs this - someone has to.
work_part.Expressions.Edit(
work_part.Expressions.FindObject("hole_dia"), str(hole_dia)
)
if __name__ == "__main__":
main()Read those two blocks side by side and the licensing, performance and hiring arguments become secondary. One of them is a relationship. The other is an event.
Licensing, Deployment and the Hybrid That Usually Wins
The deployment story favours NXOpen for reach and Knowledge Fusion for spread, and most mature installations end up using both.
On the NXOpen side, Python and .NET code runs as a journal with no developer licence required, so an automation can travel to an engineer’s seat as a single file. C/C++ and Java need a developer licence to compile and run, which is a real gate on who can ship. We covered that trade-off in detail in our comparison of Python and C# for NX automation — that article answers which NXOpen language; this one answers whether NXOpen is the right model at all.
On the KF side, the runtime is already on every Mach Series seat. The cost sits with the Author add-on and the specialists who use it.
The hybrid most of our clients converge on looks like this:
- Knowledge Fusion owns the geometry rules — the relationships that must hold no matter who opens the part.
- NXOpen owns everything around them — reading the order, driving Teamcenter, generating the drawing set, batch-running the family, writing the release package.
- A thin, documented interface between them — usually NX expressions that KF consumes and NXOpen writes, so neither side has to understand the other’s internals.
That split holds up under change. It also matches how engineering organisations are actually structured: methods specialists own the rules, software engineers own the pipeline. If you are building a variant design capability from scratch and you want one recommendation, this is it — and it is the architecture behind most of our NX Open automation work.
Migration between the two is asymmetric, and it is worth knowing which direction is cheap. Moving around KF is straightforward: leave the rules in place, wrap them in NXOpen for orchestration and integration. Moving off KF is not, because the rules encode decisions nobody wrote down elsewhere; that is a re-engineering project, not a port, and we would advise against starting it without a reason stronger than “we do not like the syntax”.
What to Check Before You Commit
Five questions settle this faster than any feature matrix:
- Does the automation need to run without anyone asking it to? Yes → Knowledge Fusion. No → NXOpen.
- Does it need to reach outside NX — Teamcenter, ERP, a file share, a drawing package? Yes → NXOpen, no discussion.
- Who maintains this in five years? Count the people in your organisation who can read DFA today. If the answer is one, that is a risk, not a resource.
- How deep are the rule chains? Deep KF hierarchies on large assemblies pay a demand-resolution cost on every update.
- What is your NX version and upgrade cadence? Siemens ships roughly twice a year — NX 2512 in December 2025, NX 2606 in June 2026 — and both KF classes and NXOpen code need a regression plan against that rhythm.
If four of the five point one way, stop analysing and build. If they split, you are looking at the hybrid.
One more thing worth putting on the table: the surrounding tooling is moving. NX 2606 added a generative AI option inside the AI Machining Suggestion feature, and the SimScale State of Engineering AI 2026 report — surveyed in February 2026 — found teams using AI-supported workflows evaluating close to four times as many design options per programme. None of that changes the update-model question. It does change how quickly the NXOpen side of a hybrid can be written, which tilts an already-close call further toward keeping the programmatic layer in a mainstream language.
If you want rules like these captured systematically, our knowledge-based engineering service for Siemens NX covers rule capture, Knowledge Fusion, the Logic Editor and NXOpen.
Frequently Asked Questions
Is Knowledge Fusion being discontinued by Siemens?
No. Knowledge Fusion ships with current NX releases, and the runtime remains part of all NX Mach Series solutions. What has changed is the surrounding ecosystem: NXOpen gets the bulk of new API surface, community material and tooling attention, so KF feels quieter than it is. Treat it as stable and specialised rather than deprecated.
How much does it cost to get started with each?
The licensing floor is very different. NXOpen with Python or .NET costs nothing extra to author or deploy as journals, so a first automation is purely engineering time. Knowledge Fusion needs the KF Author add-on module for anyone writing rules, though the runtime is already included on every Mach Series seat. Budget the bigger number for KF specialists, not for KF licences.
NXOpen vs Knowledge Fusion for variant design — which one wins?
Knowledge Fusion wins the geometry, NXOpen wins the workflow. If a transformer or cubicle variant is defined by relationships that must hold across revisions, KF enforces those relationships without anyone re-running anything. But taking an order from ERP, generating the drawing package and checking it into Teamcenter is NXOpen work. Nearly every production variant design system we build uses both.
Can we call NXOpen from Knowledge Fusion, or the other way round?
Yes, and in practice the clean pattern is to keep them loosely coupled rather than tightly nested. Most robust installations exchange state through NX expressions and attributes: KF reads them and drives geometry, NXOpen writes them from the order data and reads the result. Direct invocation is possible but makes both sides harder to test in isolation.
How long does it take to become productive in each?
An experienced Python developer with NX domain knowledge writes useful NXOpen journals in days. Knowledge Fusion takes longer for the same person — the language is declarative, the demand-order model is unfamiliar, the community is small, and coding assistants are little help. Plan weeks, not days, and plan for a mentor rather than documentation alone.
Next Step
If you are standing at this fork with a real variant design backlog behind you, a 60-minute review of your parts, rules and change frequency will settle it faster than another evaluation round.