NX Open pentru apărare: pe scurt
NX Open pentru apărare înseamnă să conduci Siemens NX din cod — Python, C#, C++ sau Java — astfel încât proiectarea de variante, înregistrările de configurație și datele de inspecție să fie generate, nu tastate. inteliScience construiește aceste automatizări ca să ruleze on-premise sau complet izolate, în rețele cu control de export. În proiectele noastre, orele manuale per modificare de configurație scad cu 50–70%.
| Flux de lucru interactiv în NX | Automatizare NX Open | |
|---|---|---|
| Variantă a unui ansamblu existent | Ore de editare manuală | Minute, conduse de un fișier de specificație |
| Dovada configurației | Compilată ulterior, manual | Scrisă la salvare, pentru fiecare piesă |
| Unde rulează AI-ul | Cloud-ul furnizorului, dacă e cazul | Pe hardware-ul dvs., fără trafic spre exterior |
Problema: o rampă de producție prinsă în 30 de ani de control al configurației
Europa cumpără într-un ritm pentru care departamentele sale de inginerie nu au fost niciodată dimensionate. Summitul NATO de la Haga a înlocuit ținta de 2% cu 5% din PIB până în 2035 — 3,5% apărare de bază plus 1,5% cheltuieli conexe — iar pentru 2026 aliații europeni și Canada bugetează aproximativ 634 de miliarde USD, circa 2,53% din PIB-ul cumulat. Planul UE Readiness 2030 pune până la 800 de miliarde € în spatele aceleiași curbe, iar pe 3 iulie 2026 Comisia Europeană a propus cinci Defence Projects of Common Interest de mare anvergură, ca să atace direct partea de capacitate.
Latura fizică a acestei rampe se vede: producția de muniție din UE a crescut de la circa 300.000 de proiectile pe an în 2022 la aproximativ două milioane până la finalul lui 2025. Partea de inginerie nu a ținut nici pe departe pasul, iar plângerea recurentă din birourile de program nu se referă la mașini-unelte. Se referă la ingineri calificați, manageri de program și la hârtiile pe care le târăște după sine o comandă de modificare în apărare.
Aceasta e partea pe care nimeni nu o bugetează. O singură modificare de toleranță la un ansamblu aflat în exploatare atinge modelul, desenul, planul de inspecție, declarația de interschimbabilitate, linia de bază a configurației și pachetul de dovezi datorat clientului. Înmulțiți cu un arbore de variante care trebuie să rămână auditabil treizeci de ani și veți vedea că blocajul nu este munca de proiectare. Este transcrierea.
Exact pentru asta există un API.
Ce este de fapt NX Open
NX Open este interfața de programare Siemens către NX — aceeași platformă pe care Siemens a redenumit-o Designcenter odată cu versiunea din iunie 2026, disponibilă general din 23 iunie 2026. Redenumirea a schimbat eticheta, nu suprafața API, iar capabilitățile Siemens NX pe care le livrăm se sprijină pe aceeași interfață ca întotdeauna. Orice entitate pe care o puteți crea manual — un corp, o expresie, o adnotare PMI, o componentă de ansamblu, o operație CAM — o puteți crea, citi și modifica din cod.
Pentru munca din apărare contează în mod special patru lucruri:
Acoperirea limbajelor. NX Open oferă legături pentru C++, C# și VB.NET, Java și Python. Python este calea cea mai rapidă către o automatizare funcțională și nu are nevoie de compilator pe mașina țintă — ceea ce contează când mașina țintă se află într-o enclavă acreditată, unde nu instalezi o toolchain în trecere. C++ rămâne relevant pentru geometrie intensivă computațional și pentru cod pe care vreți să-l distribuiți ca artefact compilat, nu ca sursă lizibilă.
Journaling. NX vă înregistrează sesiunea interactivă sub formă de cod sursă. Faceți operația o dată manual, cu journaling pornit, și obțineți un script funcțional care o reproduce. Este cea mai subestimată funcție din întreaga platformă: transformă un expert de domeniu care nu scrie software în cineva care produce prima versiune a unei automatizări în zece minute. Inginerii noștri încep aproape orice proiect NX Open așa — înregistrează, apoi refactorizează înregistrarea în ceva parametrizat și solid.
Block UI Styler. O automatizare care rulează doar din linia de comandă e folosită de trei oameni. Block UI Styler construiește dialoguri NX native — aceleași widget-uri, același aspect — astfel încât automatizarea apare ca buton în panglică, nu ca un script pe care cineva trebuie să și-l amintească. Dacă vreți adopție într-un birou de proiectare, bugetați dialogul.
Knowledge Fusion. Inginerie bazată pe reguli, încorporată chiar în piesă. În timp ce NX Open este cod procedural pe care îl execuți, Knowledge Fusion înseamnă reguli declarative care trăiesc lângă geometrie și se reevaluează când se schimbă intrările. Pentru apărare, așa codificați un standard de proiectare astfel încât să nu poată fi încălcat pe tăcute: regula călătorește cu modelul în următorul program, la următorul contractor, în următorul deceniu.
Poziția noastră clară: începeți cu journaling și Python, nu cu un document de arhitectură. Proiectele care se împotmolesc sunt cele care petrec șase săptămâni alegând un limbaj înainte să automatizeze ceva.
Configurație și trasabilitate: generați dovada, nu o tastați
Prima automatizare cu cea mai mare valoare într-un birou de inginerie din apărare nu este aproape niciodată un generator de geometrie. Este lucrul care consemnează ce s-a construit.
Cadrele STANAG și DEF STAN, împreună cu practica de management al configurației aliniată NATO din jurul lor, cer același lucru: în orice moment al unei vieți de treizeci de ani să puteți dovedi ce revizie a cărei piese a intrat în ce ansamblu cu număr de serie și de ce. Majoritatea organizațiilor rezolvă asta cu un tabel ținut în paralel cu CAD-ul. Din acel tabel vin constatările de audit.
Un script NX Open care parcurge ansamblul și emite înregistrarea direct din model elimină complet copia paralelă:
# NX Open (Python) - emit a configuration record for the open assembly.
# Batch: run_journal.exe config_record.py
# nxbatch -journal=config_record.py -part=<assembly.prt>
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()Două detalii fac asta util, nu decorativ. Rulează headless — nxbatch înseamnă că poate fi o rulare de noapte peste tot directorul programului, nu ceva pe care un inginer trebuie să-și amintească să-l apese. Și raportează golurile în loc să scrie tăcut câmpuri goale, astfel încât clasificările de export lipsă apar ca o cifră pe un dashboard, nu ca o constatare în timpul unui audit.
Împingeți aceeași înregistrare în Teamcenter și CSV-ul devine inutil: NX Open și integrarea cu Teamcenter permit automatizării să scrie atributele înapoi pe revizia de item, astfel încât sistemul PLM ține linia de bază, iar modelul rămâne sursa unică. Aceasta este versiunea pe care o construim pentru clienții care rulează deja Teamcenter; varianta pe fișiere e pentru programele care nu au ajuns încă acolo.
Stați pe un arbore de variante pe care nimeni nu-l poate justifica pe deplin? Acesta este punctul normal de plecare, nu o mărturisire. Îl cartografiem și automatizăm mai întâi stratul de dovezi — mai multe despre configurația și trasabilitatea pentru programele STANAG.
MBD și PMI: definiție citibilă de mașini sub control de export
Definiția bazată pe model nu este un proiect de reducere a desenelor în apărare. Este mecanismul care permite automatizării să citească intenția de proiectare.
PMI în NX este definiție de produs structurată conform ASME Y14.41, nu adnotare prinsă de o vedere. Cotele, toleranțele și referințele de bază sunt obiecte cu valori pe care un script le poate interoga. Departamentul american al Apărării a codificat pachetele tehnice fără desene prin MIL-STD-31000A în 2013, iar consecința practică este că un model 3D singur poate constitui baza contractuală de fabricație și inspecție — cu condiția ca PMI-ul să fie complet și consistent.
Complet și consistent — acolo își câștigă automatizarea banii. O regulă care verifică fiecare piesă eliberată pentru un sistem de referință, o specificație de rugozitate și un atribut de material se scrie într-o după-amiază cu NX Open și rulează în câteva secunde per piesă. Impusă la eliberare, înseamnă că automatizările din aval — planificarea inspecției, CAM, înregistrarea de configurație de mai sus — nu trebuie să ghicească niciodată.
Mai există un motiv nespectaculos pentru care MBD contează în apărare: controlul distribuției. Un PDF de desen părăsește sistemul și încetează să mai fie guvernat. Un model în Teamcenter, cu PMI și un atribut de clasificare la export, își poartă propriile reguli de manipulare. Când obligația dvs. este să dovediți că o definiție controlată ITAR sau dual-use UE nu a ajuns niciodată în rețeaua greșită, un singur artefact guvernat bate patru copii.
Rularea AI în interiorul perimetrului
Versiunea Designcenter din iunie 2026 a adăugat Designcenter Copilot, un asistent în limbaj natural ancorat în documentația Siemens, în practicile recomandate și în activitatea curentă a utilizatorului. Este cu adevărat util pentru întrebarea “cum fac X în NX”, care îl costă acum pe un inginer senior douăzeci de întreruperi pe săptămână.
Pentru un program de apărare, ridică și singura întrebare care contează: unde ajunge promptul?
Poziția noastră aici este fermă și este aceeași pe care o dăm fiecărui client din apărare. Copiloții furnizorului sunt în regulă pentru cunoștințe despre platformă. Nu acolo este locul geometriei pieselor, al liniilor de bază de configurație sau al documentației de program. Orice atinge date tehnice controlate rulează pe hardware pe care îl dețineți, într-o rețea pe care o controlați, fără trafic spre exterior — iar dacă acreditarea spune air-gapped, air-gapped înseamnă că ponderile modelului sunt pe mașină, nu în spatele unui VPN.
Se poate construi azi, iar forma este plictisitoare în sensul bun:
- Modele cu ponderi deschise rulate on-premise — Llama 3.3 70B pentru regăsire și redactare, Qwen2.5-Coder-32B acolo unde treaba este generarea de cod NX Open — servite pe un nod GPU din interiorul enclavei.
- Un index de regăsire peste materialul care chiar conține răspunsurile: standarde de proiectare, specificații de program, decizii de configurație anterioare, justificări istorice ale modificărilor.
- Fiecare răspuns citează documentul-sursă și revizia, pentru că un asistent care nu-și poate arăta dovezile este inutilizabil într-un mediu reglementat.
- Un om aprobă orice scrie în model sau în sistemul PLM. AI-ul propune scriptul NX Open; un inginer îl citește și îl rulează.
Unde cloud-ul este permis — material de instruire, unelte interne necontrolate, cod care nu vede niciodată date de program — modele de frontieră precum claude-opus-5 scriu NX Open mai bun decât orice puteți rula pe un singur nod, și exact pentru asta le folosim. Linia se trage la date, nu la tehnologie.
O avertizare din experiență: LLM-urile halucinează apeluri API NX Open cu deplină încredere. Metode care nu există, argumente în ordine greșită, clase dintr-un alt namespace. Orice automatizare generată trece printr-o verificare de compilare sau import și printr-o rulare pe o piesă de referință înainte ca un om să o revizuiască logic. Fără această buclă nu economisiți timp, ci îl mutați.
Obsolescența și problema datelor de treizeci de ani
Programele cu ciclu de viață lung au un al doilea caz de automatizare, mai discret: arhiva.
DMSMS — surse de fabricație în declin și penurii de materiale — este tratat în mentenanța din apărare ca inevitabil, nu ca excepție, iar actualizarea DoDI 4245.15 (Change 1, septembrie 2025) l-a împins mai departe de la “găsește un înlocuitor când se strică” către managementul proactiv al riscului pe ciclu de viață. OEM-urile europene sub STANAG și DEF STAN au obligații echivalente de continuitate a aprovizionării.
Managementul proactiv are nevoie de o imagine interogabilă a ceea ce aveți de fapt. În majoritatea programelor navale și terestre, acea imagine înseamnă treizeci de ani de desene scanate, o schemă de numerotare a pieselor schimbată de două ori și trei ingineri care țin minte restul.
Automatizarea de aici este o conductă în două etape, nu un script. Modelele de viziune citesc desenele vechi și extrag numere de piesă, materiale, specificații și standarde referite; NX Open reconciliază acea extragere cu datele curente din NX și Teamcenter și semnalează neconcordanțele. Rezultă o listă — componente al căror material specificat nu se mai produce, piese care trimit la standarde retrase, ansambluri unde modelul și desenul arhivat nu coincid. Lista aceea este intrarea pentru planificarea obsolescenței și nu exista înainte, pentru că nimeni nu-și putea permite să o producă manual. Exact așa este construit procesul nostru de extragere a desenelor și a obsolescenței pe care îl rulăm pentru programe navale.
Primele 90 de zile, realist
Am descuraja un program de platformă. Automatizarea în ingineria de apărare reușește livrând un lucru îngust în producție și lăsând următorul caz să fie tras de oamenii care l-au folosit.
| Weeks | Ce se întâmplă | Ce există la final |
|---|---|---|
| 1–2 | Înregistrați journal-uri peste cele trei fluxuri cele mai repetate; măsurați orele manuale | O listă ierarhizată cu ore atașate, nu opinii |
| 3–6 | Construiți automatizarea cu cea mai mare valoare ca o comandă Block UI Styler; rulați-o batch, noaptea | O unealtă în panglică, o rulare de noapte |
| 7–10 | Adăugați verificările PMI și de atribute la eliberare; conectați rezultatele în Teamcenter | Datele proaste nu mai intră în linia de bază |
| 11–13 | Ridicați indexul de regăsire on-premise peste standarde și documentele de program | Un asistent cu citări, în interiorul perimetrului |
Ordinea este deliberată. Verificări înaintea generatoarelor, pentru că generarea de variante din date-sursă inconsistente industrializează inconsistența. Iar stratul de AI la final, pentru că un index de regăsire peste documente în care nimeni nu are încredere returnează răspunsuri în care nimeni nu are încredere.
Două lucruri omoară constant astfel de proiecte. Primul este un script scris de un singur inginer care apoi schimbă echipa — de aici Block UI Styler, control de versiune și o a doua persoană care poate citi codul. Al doilea este automatizarea unui proces care ar fi trebuit simplificat mai întâi. Dacă un flux are unsprezece pași din cauza unei aprobări pe care nimeni nu-și amintește să o fi introdus, automatizați zece dintre ei și ați făcut procesul greșit mai rapid.
Întrebări frecvente
Poate rula NX Open într-o rețea izolată (air-gapped)?
Da. NX Open se execută local în procesul NX sau prin nxbatch pe aceeași mașină — niciun serviciu extern nu este implicat, așa că o enclavă acreditată nu schimbă nimic din modul în care rulează automatizarea. Singura componentă care necesită planificare este stratul de AI, pentru că el cere ponderi de model și un nod GPU în interiorul perimetrului, nu un endpoint API.
Cât costă un proiect de automatizare NX Open?
O automatizare unică, bine delimitată — un flux de lucru, un dialog Block UI Styler, capacitate de rulare batch și documentație de predare — se situează de regulă între 8.000 € și 25.000 €, în funcție de cât din datele sursă trebuie curățat mai întâi. Programele cu o arhivă veche mare costă mai mult în faza de descoperire decât în cea de programare. Dimensionăm după exercițiul de journaling, nu înainte.
NX Open sau Knowledge Fusion — ce ar trebui să folosim?
Sarcini diferite. Knowledge Fusion păstrează reguli care călătoresc cu piesa și se reevaluează când se schimbă intrările, exact ce vă trebuie pentru standarde de proiectare impuse de-a lungul unui lanț de furnizori. NX Open este pentru munca procedurală: procesare batch, generare de documente, dialog cu Teamcenter sau un sistem extern. Majoritatea automatizărilor de apărare pe care le construim folosesc ambele, cu Knowledge Fusion purtând constrângerile și NX Open orchestrând.
Va scrie pur și simplu un LLM scripturile noastre NX Open?
Parțial, și nu nesupravegheat. Modelele actuale produc o primă versiune solidă a unui script NX Open și apoi inventează apeluri API care nu există în namespace-ul invocat. Tiparul care funcționează este: generezi, verifici importul față de API-ul real, rulezi pe o piesă de referință, apoi review uman. Tot e mult mai rapid decât scrisul de la zero — doar că nu merge fără mâini pe volan.
Automatizarea NX ne afectează poziția privind controlul exporturilor sau acreditarea?
De obicei o îmbunătățește, pentru că dovezile generate sunt mai consistente decât cele întreținute manual. Controalele care rămân sunt cele obișnuite: automatizări sub control de versiune, modificări trecute prin review, nimic care scrie într-o linie de bază eliberată fără aprobare și nicio componentă a lanțului de unelte care apelează în afara rețelei. Documentăm fluxurile de date ca parte a livrării, ca discuția de acreditare să aibă un punct de reper.
Pasul următor
Nu aveți nevoie de o strategie ca să aflați dacă asta vi se aplică. Aveți nevoie de o oră cu cele trei fluxuri pe care inginerii dvs. le repetă cel mai des.
Discutați cu inginerii noștri despre automatizarea NX Open pentru programul dvs.
