NXOpen vs. Knowledge Fusion: pe scurt
NXOpen vs. Knowledge Fusion este o alegere între două modele de actualizare, nu între două sintaxe. Regulile Knowledge Fusion trăiesc în mecanismul de actualizare al NX și se reevaluează singure când geometria se schimbă; codul NXOpen rulează doar când este apelat. inteliScience livrează ambele pe NX 2606 și alege în funcție de frecvența modificărilor, competențele echipei și cine întreține rezultatul peste cinci ani.
| Knowledge Fusion | NXOpen | |
|---|---|---|
| Rulează când | NX actualizează piesa | Îl apelați dumneavoastră |
| Trăiește în | fișierul piesei, ca reguli | un jurnal sau un add-in compilat, în afara piesei |
| Cel mai puternic la | Geometrie care trebuie să rămână consistentă prin modificări | Prelucrare în lot, integrare PLM, orice din afara modelării |
| Cea mai grea parte | Să găsiți oameni care îl mai pot citi în 2031 | Să îl rerulați după fiecare modificare de proiectare |
Problema: alegeți un model de actualizare, nu un limbaj
Majoritatea echipelor încep această comparație din locul greșit — de la sintaxă. Se uită la un fișier DFA de Knowledge Fusion, îl găsesc nefamiliar și aleg NXOpen pentru că Python este Python. Șase luni mai târziu automatizarea funcționează excelent și nimeni nu o rulează, pentru că rularea este un pas manual care concurează cu termenul limită al unui proiectant.
Întrebarea reală este când se execută automatizarea dumneavoastră.
Knowledge Fusion este un limbaj bazat pe reguli, legat direct de mecanismul de actualizare al NX. Siemens spune explicit că acest lucru îi permite lui KF să facă lucruri pe care NXOpen nu le poate face: o regulă KF face parte din piesă, iar când NX actualizează modelul, regula se reevaluează și geometria urmează. Nimeni nu apasă un buton.
NXOpen este API-ul programatic — C++, C#, VB.NET, Java și Python — și face ce îi spuneți, când îi spuneți. Poate ajunge în Teamcenter, poate parcurge un ansamblu, poate scrie un desen, poate procesa în lot o mie de piese peste noapte. Nu poate sta în interiorul piesei și să se trezească atunci când o față se mișcă.
Această distincție decide mai mult decât orice benchmark. Și merită luată deliberat: estimările pun până la 40 la sută din timpul de inginerie în muncă CAD repetitivă, echivalentul a peste 17.000 USD per inginer pe an în productivitate pierdută — genul de cifră care face automatizarea evidentă și alegerea modelului de automatizare scumpă dacă e greșită.
Ce face Knowledge Fusion și NXOpen nu poate
Knowledge Fusion păstrează intenția de proiectare ca relație vie, nu ca rezultat unic. Declarați că diametrul găurii de prindere depinde de lățimea plăcii, iar acea dependență supraviețuiește fiecărei revizii, fiecărui utilizator și fiecărei sesiuni. Un script NXOpen care calculează același diametru produce un număr, îl scrie o dată, iar apoi modelul și regula se despart în momentul în care cineva modifică placa.
Pentru proiectarea de variante, exact aici se joacă totul. Un transformator, o celulă de distribuție, o carcasă de reductor — geometria diferă de la o comandă la alta, relațiile nu. A codifica relațiile o singură dată și a lăsa NX să le impună este structural altceva decât a rerula un script și a spera că cineva și-a amintit.
KF este de asemenea distribuit mai larg decât cred majoritatea echipelor. Executarea aplicațiilor Knowledge Fusion este inclusă în toate soluțiile NX Mach Series ca licență runtime; doar capacitatea de creare, Knowledge Fusion Author, este un modul suplimentar NX Mach Seriesseparat. Practic, asta înseamnă că o companie poate scrie reguli cu doi sau trei specialiști instruiți și poate distribui rezultatul pe fiecare post de lucru fără să cumpere nimic în plus pentru utilizatori.
Poziția noastră, pe șleau: dacă sarcina automatizării este să păstreze geometria corectă prin modificări, KF este unealta potrivită, iar NXOpen este un compromis.
Unde vă costă Knowledge Fusion
Knowledge Fusion este lent, fragil în privința referințelor la fișiere și tot mai greu de acoperit cu personal — trei costuri care nu apar într-un proof of concept și domină în anul trei.
Problema de performanță este structurală, nu un detaliu de implementare. KF este determinat de cerere: înainte să creeze vreo geometrie, trebuie să rezolve ordinea cererii obiectelor copil — exact de aceea clasele KF poartă specificații demandOrder . Pe o piesă mică nimeni nu observă. Pe un ansamblu mare, cu lanțuri adânci de reguli, inginerii observă la fiecare actualizare.
Fragilitatea apare la întreținere. Regulile care referențiază nume de fișiere de piese trebuie editate ori de câte ori un fișier este redenumit — redenumiți a.prt to b.prt și regula care arăta spre el este acum greșită. Într-un pilot este o mică bătaie de cap, într-un mediu administrat prin PLM, unde redenumirea și revizuirea sunt rutină, este o problemă reală.
Și mai este partea pe care nimeni nu a planificat-o. Sintaxa DFA a lui KF este un limbaj specific Siemens, cu o comunitate mică de practicieni, fără ecosistem de pachete și aproape fără prezență în datele de antrenare ale asistenților moderni de cod. Cereți-i lui claude-opus-5 să scrie un jurnal NXOpen în Python și veți primi ceva aproape rulabil; cereți-i o clasă DFA non-trivială și veți primi mai ales absurdități spuse cu încredere. În 2026 această diferență este un factor real de cost, pentru că schimbă cât de repede devine productiv un membru nou al echipei.
Vreți să vedeți asta aplicat pe muncă reală de variante? Articolul nostru despre automatizarea proiectării de variante de transformatoare în NX arată cum arată în practică o linie de la comandă la model, condusă de reguli.
NXOpen vs. Knowledge Fusion: opt criterii care chiar diferă
| Criteriu | Knowledge Fusion | NXOpen |
|---|---|---|
| Declanșator al execuției | Automat, la actualizarea NX | Manual, programat sau declanșat de evenimente |
| Domeniu | În interiorul piesei și al geometriei ei | Întreaga sesiune NX, Teamcenter, sistem de fișiere, rețea |
| Limbi străine | Doar KF / DFA | C++, C#, VB.NET, Java, Python |
| Licență pentru dezvoltare | Modulul suplimentar KF Author | Jurnalele Python și .NET nu au nevoie de licență de dezvoltator; C/C++ și Java au |
| Licență pentru rulare | Runtime inclus în NX Mach Series | Jurnalul rulează pe orice post; add-in-urile trebuie semnate |
| Profil de performanță | Determinat de cerere, încetinește pe lanțuri adânci de reguli | Rulează cu viteza cu care îl scrieți |
| Depanare | Verificare de sintaxă în DFA Manager, unelte limitate | IDE-uri obișnuite, breakpoint-uri, teste unitare, control al versiunilor |
| Personal și suport AI | Bazin mic de specialiști, acoperire slabă în LLM-uri | Bazin mare, acoperire puternică în LLM-uri |
Două rânduri merită subliniate, pentru că ele decid majoritatea proiectelor reale. Domeniu: dacă automatizarea trebuie să vorbească cu Teamcenter, să citească o comandă din ERP sau să producă un pachet de desene, KF nu ajunge atât de departe și întrebarea este rezolvată. Depanare: codul NXOpen stă în Git, rulează sub un debugger și poate fi testat unitar; KF primește o verificare de sintaxă. Pe un orizont de întreținere de cinci ani, diferența se acumulează.
Aceeași regulă, scrisă în ambele feluri
Iată diferența în zece rânduri. Ambele exemple sunt scurtate pentru articol și ambele exprimă aceeași intenție: diametrul găurii depinde de lățimea plăcii.
Knowledge Fusion declară relația și lasă NX să o întrețină:
#! 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 calculează aceeași valoare, o dată, și apoi nu îi mai pasă:
# 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()Citiți cele două blocuri alăturat și argumentele privind licențierea, performanța și personalul devin secundare. Unul dintre ele este o relație. Celălalt este un eveniment.
Licențiere, distribuire și hibridul care câștigă de obicei
La distribuire, acoperirea înclină spre NXOpen, iar răspândirea spre Knowledge Fusion — iar majoritatea instalărilor mature ajung să le folosească pe amândouă.
De partea NXOpen, codul Python și .NET rulează ca jurnal fără licență de dezvoltator, deci o automatizare poate ajunge la postul unui inginer ca un singur fișier. C/C++ și Java au nevoie de licență de dezvoltator pentru compilare și rulare, ceea ce limitează real cine poate livra. Am tratat compromisul în detaliu în comparația noastră între Python și C# pentru automatizarea NX — acel articol răspunde la întrebarea care limbaj NXOpen; acesta răspunde la întrebarea dacă NXOpen este în general modelul potrivit.
De partea KF, runtime-ul este deja pe fiecare post Mach Series. Costul stă în add-on-ul Author și în specialiștii care îl folosesc.
Hibridul spre care converg majoritatea clienților noștri arată așa:
- Knowledge Fusion deține regulile de geometrie — relațiile care trebuie să rămână valabile indiferent cine deschide piesa.
- NXOpen deține tot ce este în jurul lor — citirea comenzii, controlul Teamcenter, generarea setului de desene, rularea în lot a familiei, scrierea pachetului de eliberare.
- O interfață subțire și documentată între ele — de regulă expresii NX pe care KF le consumă și NXOpen le scrie, astfel încât nicio parte nu trebuie să înțeleagă interiorul celeilalte.
Această împărțire rezistă la schimbare. Se potrivește și cu felul în care sunt structurate de fapt organizațiile de inginerie: specialiștii de metode dețin regulile, inginerii software dețin linia de procesare. Dacă construiți de la zero o capabilitate de proiectare de variante și vreți o singură recomandare, aceasta este — și este arhitectura din spatele majorității proiectelor noastre de automatizare NX Open.
Migrarea între cele două este asimetrică și merită să știți care direcție este ieftină. Un drum în jurul KF este simplu: regulile rămân pe loc, iar NXOpen se așază în jurul lor pentru orchestrare și integrare. Un drum departe de KF nu este, pentru că regulile codifică decizii pe care nimeni nu le-a scris în altă parte; aceasta este o reproiectare, nu o portare, și am sfătui împotriva începerii ei fără un motiv mai bun decât “nu ne place sintaxa”.
Ce să verificați înainte de a vă decide
Cinci întrebări rezolvă asta mai repede decât orice matrice de funcții:
- Trebuie automatizarea să ruleze fără ca cineva să i-o ceară? Da → Knowledge Fusion. Nu → NXOpen.
- Trebuie să ajungă în afara NX — Teamcenter, ERP, un share de fișiere, un pachet de desene? Da → NXOpen, fără discuție.
- Cine întreține asta peste cinci ani? Numărați oamenii din organizația dumneavoastră care pot citi DFA astăzi. Dacă răspunsul este unu, acesta este un risc, nu o resursă.
- Cât de adânci sunt lanțurile de reguli? Ierarhiile KF adânci pe ansambluri mari plătesc un cost de rezolvare a cererii la fiecare actualizare.
- Ce versiune de NX și ce ritm de upgrade aveți? Siemens livrează de aproximativ două ori pe an — NX 2512 în decembrie 2025, NX 2606 în iunie 2026 — iar atât clasele KF, cât și codul NXOpen au nevoie de un plan de regresie față de acest ritm.
Dacă patru din cinci arată în aceeași direcție, opriți analiza și construiți. Dacă se împart, vă uitați la hibrid.
Încă un lucru merită pus pe masă: uneltele din jur se mișcă. NX 2606 a adăugat o opțiune de AI generativă în funcția AI Machining Suggestion, iar raportul SimScale State of Engineering AI 2026 — sondaj realizat în februarie 2026 — a constatat că echipele care folosesc fluxuri asistate de AI evaluează de aproape patru ori mai multe opțiuni de proiectare per program. Nimic din toate acestea nu schimbă întrebarea despre modelul de actualizare. Schimbă însă cât de repede poate fi scrisă partea NXOpen a unui hibrid, ceea ce înclină o decizie oricum strânsă și mai mult spre a păstra stratul programatic într-un limbaj răspândit.
Dacă doriți să captați sistematic reguli ca acestea, serviciul nostru de inginerie bazată pe cunoștințe pentru Siemens NX acoperă captarea regulilor, Knowledge Fusion, Logic Editor și NXOpen.
Întrebări frecvente
Knowledge Fusion este scos din uz de Siemens?
Nu. Knowledge Fusion este livrat cu versiunile NX actuale, iar runtime-ul rămâne parte din toate soluțiile NX Mach Series. S-a schimbat ecosistemul din jur: NXOpen primește cea mai mare parte a suprafeței noi de API, a materialelor de comunitate și a atenției pentru unelte, așa că KF pare mai tăcut decât este. Tratați-l ca stabil și specializat, nu ca depreciat.
Cât costă startul cu fiecare dintre ele?
Pragul de licențiere diferă considerabil. NXOpen cu Python sau .NET nu costă nimic în plus nici pentru dezvoltare, nici pentru distribuire ca jurnal, deci o primă automatizare înseamnă doar timp de inginerie. Knowledge Fusion are nevoie de modulul suplimentar KF Author pentru oricine scrie reguli, deși runtime-ul este deja inclus pe fiecare post de lucru Mach Series. Bugetați suma mai mare pentru specialiștii KF, nu pentru licențele KF.
NXOpen vs. Knowledge Fusion în proiectarea de variante — care câștigă?
Knowledge Fusion câștigă la geometrie, NXOpen câștigă la flux de lucru. Dacă o variantă de transformator sau de celulă de distribuție este definită prin relații care trebuie să rămână valabile de la o revizie la alta, KF impune aceste relații fără ca cineva să reruleze ceva. Însă preluarea unei comenzi din ERP, generarea pachetului de desene și înregistrarea lui în Teamcenter sunt muncă pentru NXOpen. Aproape fiecare sistem de proiectare de variante pe care îl construim folosește ambele.
Putem apela NXOpen din Knowledge Fusion sau invers?
Da, iar în practică modelul curat este cuplarea slabă, nu imbricarea strânsă. Cele mai robuste instalări schimbă stare prin expresii și atribute NX: KF le citește și conduce geometria, NXOpen le scrie din datele comenzii și citește rezultatul. Apelul direct este posibil, dar face ambele părți mai greu de testat izolat.
Cât durează până devii productiv cu fiecare?
O dezvoltatoare Python cu experiență și cunoștințe de NX scrie jurnale NXOpen utile în câteva zile. Knowledge Fusion îi ia mai mult aceleiași persoane — limbajul este declarativ, modelul demand-order este nefamiliar, comunitatea este mică, iar asistenții de cod ajută prea puțin. Planificați săptămâni, nu zile, și planificați un mentor, nu doar documentație.
Pasul următor
Dacă sunteți la această răscruce cu un volum real de proiectare de variante în spate, o revizuire de 60 de minute a pieselor, regulilor și frecvenței modificărilor va lămuri lucrurile mai repede decât încă o rundă de evaluare.
Discutați cu inginerii noștri NX despre modelul dumneavoastră de automatizare