NXOpen vs. Knowledge Fusion: Die Kurzfassung
NXOpen vs. Knowledge Fusion ist eine Entscheidung zwischen zwei Aktualisierungsmodellen, nicht zwischen zwei Syntaxen. Knowledge-Fusion-Regeln leben im Aktualisierungsmechanismus von NX und werten sich neu aus, wenn sich die Geometrie ändert; NXOpen-Code läuft nur, wenn er aufgerufen wird. inteliScience liefert beides auf NX 2606 und wählt nach Änderungshäufigkeit, Team-Kompetenz und der Frage, wer das Ergebnis in fünf Jahren pflegt.
| Knowledge Fusion | NXOpen | |
|---|---|---|
| Läuft, wenn | NX das Teil aktualisiert | Sie es aufrufen |
| Lebt in | der Teiledatei, als Regeln | einem Journal oder kompilierten Add-in, außerhalb des Teils |
| Am stärksten bei | Geometrie, die über Änderungen hinweg konsistent bleiben muss | Batch-Läufen, PLM-Integration, allem außerhalb der Modellierung |
| Schwerster Teil | Menschen zu finden, die es 2031 noch lesen können | Es nach jeder Konstruktionsänderung erneut auszuführen |
Das Problem: Sie wählen ein Aktualisierungsmodell, keine Sprache
Die meisten Teams beginnen diesen Vergleich an der falschen Stelle — bei der Syntax. Sie schauen sich eine Knowledge-Fusion-DFA-Datei an, finden sie fremd und greifen zu NXOpen, weil Python nun einmal Python ist. Sechs Monate später funktioniert die Automatisierung hervorragend, und niemand führt sie aus, weil das Ausführen ein manueller Schritt ist, der mit dem Termindruck der Konstruktion konkurriert.
Die eigentliche Frage lautet, wann Ihre Automatisierung ausgeführt wird.
Knowledge Fusion ist eine regelbasierte Sprache, die direkt im Aktualisierungsmechanismus von NX hängt. Siemens sagt ausdrücklich, dass KF dadurch Dinge kann, die NXOpen nicht kann: Eine KF-Regel ist Teil des Teils, und wenn NX das Modell aktualisiert, wertet sich die Regel neu aus und die Geometrie folgt. Niemand drückt einen Knopf.
NXOpen ist die programmatische API — C++, C#, VB.NET, Java und Python — und sie tut, was Sie sagen, wenn Sie es sagen. Sie erreicht Teamcenter, läuft durch eine Baugruppe, schreibt eine Zeichnung, verarbeitet über Nacht tausend Teile im Batch. Sie kann nicht im Teil sitzen und aufwachen, wenn sich eine Fläche bewegt.
Diese Unterscheidung entscheidet mehr als jeder Benchmark. Und sie ist es wert, bewusst getroffen zu werden: Schätzungen setzen bis zu 40 Prozent der Ingenieurszeit in wiederkehrende CAD-Arbeit an, was mehr als 17.000 USD je Ingenieur und Jahr an verlorener Produktivität entspricht — die Art Zahl, die Automatisierung offensichtlich macht und die Wahl des Automatisierungsmodells teuer, wenn sie falsch ausfällt.
Was Knowledge Fusion kann und NXOpen nicht
Knowledge Fusion hält die Konstruktionsabsicht als lebende Beziehung fest statt als einmaliges Ergebnis. Deklarieren Sie, dass der Durchmesser der Befestigungsbohrung von der Plattenbreite abhängt, und diese Abhängigkeit überlebt jede Revision, jeden Nutzer und jede Sitzung. Ein NXOpen-Skript, das denselben Durchmesser berechnet, erzeugt eine Zahl, schreibt sie einmal — und dann driften Modell und Regel auseinander, sobald jemand die Platte ändert.
Für die Variantenkonstruktion ist genau das der Kern. Ein Transformator, ein Schaltschrank, ein Getriebegehäuse — die Geometrie unterscheidet sich je Auftrag, die Beziehungen nicht. Beziehungen einmal zu kodieren und NX durchsetzen zu lassen, ist strukturell etwas anderes, als ein Skript erneut auszuführen und zu hoffen, dass jemand daran gedacht hat.
KF wird außerdem breiter ausgerollt, als die meisten Teams annehmen. Die Ausführung von Knowledge-Fusion-Anwendungen ist in allen NX-Mach-Series-Lösungen als Runtime-Lizenz enthalten; nur die Autorenfunktion, Knowledge Fusion Author, ist ein separates NX-Mach-Series-Add-on-Modul. Praktisch heißt das: Ein Unternehmen kann Regeln mit zwei oder drei geschulten Spezialisten schreiben und das Ergebnis auf jeden Arbeitsplatz ausrollen, ohne für die Anwender etwas zusätzlich zu kaufen.
Unsere Position, unumwunden: Wenn die Aufgabe der Automatisierung darin besteht, Geometrie über Änderungen hinweg korrekt zu halten, ist KF das richtige Werkzeug und NXOpen ein Behelf.
Wo Knowledge Fusion Sie etwas kostet
Knowledge Fusion ist langsam, anfällig bei Dateireferenzen und zunehmend schwer zu besetzen — drei Kosten, die im Proof of Concept nicht auftauchen und im dritten Jahr dominieren.
Das Performance-Thema ist strukturell, kein Implementierungsdetail. KF ist bedarfsgesteuert: Bevor es überhaupt Geometrie erzeugt, muss es die Bedarfsreihenfolge der Kindobjekte auflösen — genau deshalb tragen KF-Klassen überhaupt demandOrder -Angaben. An einem kleinen Teil merkt das niemand. An einer großen Baugruppe mit tiefen Regelketten merken es die Konstrukteure bei jeder Aktualisierung.
Die Anfälligkeit zeigt sich in der Wartung. Regeln, die Namen von Teiledateien referenzieren, müssen bei jeder Umbenennung angepasst werden — benennen Sie a.prt to b.prt um, und die Regel, die darauf zeigte, ist falsch. Im Pilotprojekt ist das eine kleine Nervigkeit, in einer PLM-verwalteten Landschaft, in der Umbenennen und Revisionieren Routine sind, ein echtes Problem.
Und dann ist da der Teil, den niemand eingeplant hat. Die DFA-Syntax von KF ist eine Siemens-spezifische Sprache mit kleiner Anwender-Community, ohne Paket-Ökosystem und mit fast keiner Präsenz in den Trainingsdaten moderner Coding-Assistenten. Bitten Sie claude-opus-5 , ein NXOpen-Python-Journal zu schreiben, und Sie bekommen etwas nahezu Lauffähiges; bitten Sie es um eine nicht-triviale DFA-Klasse, und Sie bekommen meist selbstbewussten Unsinn. 2026 ist diese Lücke ein echter Kostenfaktor, weil sie darüber entscheidet, wie schnell ein neues Teammitglied produktiv wird.
Sehen, wie das in echter Variantenarbeit aussieht? Unser Beitrag zur Automatisierung der Transformator-Variantenkonstruktion in NX zeigt, wie eine regelgetriebene Pipeline vom Auftrag zum Modell in der Praxis aussieht.
NXOpen vs. Knowledge Fusion: Acht Kriterien, die wirklich unterscheiden
| Kriterium | Knowledge Fusion | NXOpen |
|---|---|---|
| Auslöser der Ausführung | Automatisch, bei NX-Aktualisierung | Manuell, geplant oder ereignisgesteuert |
| Umfang | Im Teil und seiner Geometrie | Ganze NX-Sitzung, Teamcenter, Dateisystem, Netzwerk |
| Sprachen | Nur KF / DFA | C++, C#, VB.NET, Java, Python |
| Lizenz zum Entwickeln | Add-on-Modul KF Author | Python- und .NET-Journals brauchen keine Entwicklerlizenz; C/C++ und Java schon |
| Lizenz zum Ausführen | Runtime in NX Mach Series enthalten | Journal läuft auf jedem Arbeitsplatz; Add-ins müssen signiert werden |
| Performance-Profil | Bedarfsgesteuert, langsamer bei tiefen Regelketten | Läuft so schnell, wie Sie es schreiben |
| Debugging | DFA-Manager-Syntaxprüfung, wenig Werkzeuge | Übliche IDEs, Breakpoints, Unit-Tests, Versionskontrolle |
| Personal und KI-Unterstützung | Kleiner Spezialistenpool, schwache LLM-Abdeckung | Großer Pool, starke LLM-Abdeckung |
Zwei Zeilen verdienen Hervorhebung, weil sie die meisten realen Projekte entscheiden. Umfang: Wenn die Automatisierung mit Teamcenter sprechen, einen Auftrag aus dem ERP lesen oder ein Zeichnungspaket erzeugen muss, reicht KF nicht so weit und die Frage ist entschieden. Debugging: NXOpen-Code liegt in Git, läuft unter einem Debugger und lässt sich unit-testen; KF bekommt eine Syntaxprüfung. Über einen Wartungshorizont von fünf Jahren summiert sich dieser Unterschied.
Dieselbe Regel, zweimal geschrieben
Hier ist der Unterschied in zehn Zeilen. Beide Beispiele sind für den Artikel gekürzt, und beide drücken dieselbe Absicht aus: Der Bohrungsdurchmesser hängt von der Plattenbreite ab.
Knowledge Fusion deklariert die Beziehung und lässt NX sie pflegen:
#! 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 berechnet denselben Wert einmal — und kümmert sich danach nicht mehr darum:
# 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()Lesen Sie diese beiden Blöcke nebeneinander, und die Argumente zu Lizenzen, Performance und Personal werden zweitrangig. Der eine ist eine Beziehung. Der andere ist ein Ereignis.
Lizenzen, Verteilung und der Hybrid, der meistens gewinnt
Bei der Verteilung spricht die Reichweite für NXOpen und die Breite für Knowledge Fusion — und die meisten ausgereiften Installationen nutzen am Ende beides.
Auf der NXOpen-Seite laufen Python- und .NET-Code als Journal ohne Entwicklerlizenz, eine Automatisierung erreicht den Arbeitsplatz eines Konstrukteurs also als einzelne Datei. C/C++ und Java brauchen zum Kompilieren und Ausführen eine Entwicklerlizenz, was real begrenzt, wer ausliefern kann. Diesen Kompromiss haben wir ausführlich behandelt in unserem Vergleich von Python und C# für die NX-Automatisierung — jener Artikel beantwortet die Frage nach der richtigen NXOpen-Sprache; dieser beantwortet die Frage, ob NXOpen überhaupt das richtige Modell ist.
Auf der KF-Seite ist die Runtime bereits auf jedem Mach-Series-Arbeitsplatz. Die Kosten liegen beim Author-Add-on und bei den Spezialisten, die es benutzen.
Der Hybrid, auf den die meisten unserer Kunden zulaufen, sieht so aus:
- Knowledge Fusion besitzt die Geometrieregeln — die Beziehungen, die gelten müssen, egal wer das Teil öffnet.
- NXOpen besitzt alles drumherum — den Auftrag lesen, Teamcenter steuern, den Zeichnungssatz erzeugen, die Teilefamilie im Batch durchlaufen, das Freigabepaket schreiben.
- Eine schlanke, dokumentierte Schnittstelle dazwischen — meist NX-Expressions, die KF konsumiert und NXOpen schreibt, sodass keine Seite die Interna der anderen verstehen muss.
Diese Aufteilung hält Änderungen stand. Sie passt außerdem dazu, wie Engineering-Organisationen tatsächlich aufgebaut sind: Methodenspezialisten besitzen die Regeln, Software-Engineers die Pipeline. Wenn Sie eine Variantenkonstruktions-Fähigkeit von Grund auf aufbauen und eine einzige Empfehlung wollen, dann diese — und sie ist die Architektur hinter dem Großteil unserer NX-Open-Automatisierungsprojekte.
Die Migration zwischen beiden ist asymmetrisch, und es lohnt sich zu wissen, welche Richtung günstig ist. Ein Weg um KF herum ist unkompliziert: Die Regeln bleiben stehen, NXOpen legt sich für Orchestrierung und Integration darum. Ein Weg weg von KF ist es nicht, denn die Regeln kodieren Entscheidungen, die niemand anderswo aufgeschrieben hat; das ist ein Re-Engineering-Projekt, keine Portierung, und wir würden davon abraten, es ohne einen besseren Grund als “uns gefällt die Syntax nicht” zu beginnen.
Was Sie prüfen sollten, bevor Sie sich festlegen
Fünf Fragen klären das schneller als jede Feature-Matrix:
- Muss die Automatisierung laufen, ohne dass jemand sie anstößt? Ja → Knowledge Fusion. Nein → NXOpen.
- Muss sie über NX hinausreichen — Teamcenter, ERP, ein File-Share, ein Zeichnungspaket? Ja → NXOpen, keine Diskussion.
- Wer pflegt das in fünf Jahren? Zählen Sie die Menschen in Ihrer Organisation, die heute DFA lesen können. Ist die Antwort eins, ist das ein Risiko und keine Ressource.
- Wie tief sind die Regelketten? Tiefe KF-Hierarchien auf großen Baugruppen zahlen bei jeder Aktualisierung einen Preis für die Bedarfsauflösung.
- Welche NX-Version und welchen Upgrade-Takt haben Sie? Siemens liefert etwa zweimal im Jahr — NX 2512 im Dezember 2025, NX 2606 im Juni 2026 — und sowohl KF-Klassen als auch NXOpen-Code brauchen einen Regressionsplan gegen diesen Rhythmus.
Zeigen vier der fünf in dieselbe Richtung, hören Sie auf zu analysieren und bauen Sie. Teilen sie sich, schauen Sie auf den Hybrid.
Noch etwas gehört auf den Tisch: Das Umfeld bewegt sich. NX 2606 hat eine generative KI-Option innerhalb der Funktion AI Machining Suggestion ergänzt, und der Report SimScale State of Engineering AI 2026 — Befragung im Februar 2026 — fand, dass Teams mit KI-gestützten Arbeitsabläufen fast viermal so viele Konstruktionsoptionen je Programm bewerten. Nichts davon ändert die Frage nach dem Aktualisierungsmodell. Es ändert, wie schnell sich die NXOpen-Seite eines Hybrids schreiben lässt, was eine ohnehin knappe Entscheidung weiter dahin kippt, die programmatische Schicht in einer verbreiteten Sprache zu halten.
Häufig gestellte Fragen
Wird Knowledge Fusion von Siemens eingestellt?
Nein. Knowledge Fusion wird mit den aktuellen NX-Releases ausgeliefert, und die Runtime bleibt Bestandteil aller NX-Mach-Series-Lösungen. Verändert hat sich das Umfeld: NXOpen bekommt den Großteil der neuen API-Fläche, des Community-Materials und der Werkzeug-Aufmerksamkeit, deshalb wirkt KF stiller, als es ist. Behandeln Sie es als stabil und spezialisiert, nicht als abgekündigt.
Was kostet der Einstieg jeweils?
Die Lizenz-Untergrenze unterscheidet sich deutlich. NXOpen mit Python oder .NET kostet weder für die Entwicklung noch für die Verteilung als Journal etwas zusätzlich, eine erste Automatisierung ist also reine Entwicklungszeit. Knowledge Fusion braucht das Add-on-Modul KF Author für jeden, der Regeln schreibt, während die Runtime auf jedem Mach-Series-Arbeitsplatz bereits enthalten ist. Kalkulieren Sie den größeren Posten für KF-Spezialisten ein, nicht für KF-Lizenzen.
NXOpen vs. Knowledge Fusion in der Variantenkonstruktion — was gewinnt?
Knowledge Fusion gewinnt bei der Geometrie, NXOpen beim Arbeitsablauf. Wenn eine Transformator- oder Schaltschrankvariante über Beziehungen definiert ist, die über Revisionen hinweg gelten müssen, setzt KF diese Beziehungen durch, ohne dass jemand etwas erneut ausführt. Einen Auftrag aus dem ERP zu übernehmen, das Zeichnungspaket zu erzeugen und es in Teamcenter einzuchecken, ist dagegen NXOpen-Arbeit. Nahezu jedes produktive Variantenkonstruktions-System, das wir bauen, nutzt beides.
Lässt sich NXOpen aus Knowledge Fusion aufrufen oder umgekehrt?
Ja, und in der Praxis ist das saubere Muster eine lose Kopplung statt einer engen Verschachtelung. Die robustesten Installationen tauschen Zustand über NX-Expressions und Attribute aus: KF liest sie und treibt die Geometrie, NXOpen schreibt sie aus den Auftragsdaten und liest das Ergebnis. Ein direkter Aufruf ist möglich, macht aber beide Seiten schwerer isoliert testbar.
Wie lange dauert es, jeweils produktiv zu werden?
Eine erfahrene Python-Entwicklerin mit NX-Domänenwissen schreibt in Tagen brauchbare NXOpen-Journals. Knowledge Fusion dauert für dieselbe Person länger — die Sprache ist deklarativ, das Demand-Order-Modell ungewohnt, die Community klein, und Coding-Assistenten helfen kaum. Planen Sie Wochen statt Tage, und planen Sie eine Mentorin ein statt nur Dokumentation.
Nächster Schritt
Wenn Sie an dieser Weggabelung stehen und einen echten Rückstand in der Variantenkonstruktion hinter sich haben, klärt eine 60-minütige Durchsicht Ihrer Teile, Regeln und Änderungshäufigkeit das schneller als eine weitere Evaluierungsrunde.
Sprechen Sie mit unseren NX-Engineers über Ihr Automatisierungsmodell
