Contacte
Contactați-ne
Închis

Contacte

România, Cluj-Napoca – 400157
Str. Ploiești nr. 9

România, Vama – 447350
Str. Fermei Nr. 14

+40 774 463 429

info@inteliscience.net

AI pentru administrarea NX: 8 sarcini de admin pregătite de un asistent

AI pentru administrarea NX: versiunea scurtă

AI pentru administrarea NX înseamnă un asistent care răspunde la întrebările de administrare CAD din documentația NX și din propriile dumneavoastră standarde, pregătește artefacte de admin (un UDF, o intrare de material, o modificare de Customer Defaults, o customizare de ribbon, un schelet NXOpen) pentru revizuire și nu execută nimic partajat fără o poartă de confirmare (gate). inteliScience construiește acești asistenți pe NXOpen pentru echipele de inginerie din DACH; administratorul rămâne cel care aprobă.


Problema: fiecare cerere către administratorul CAD este un tichet

Administrarea CAD a unui constructor de mașini din DACH a strâns recent ce așteaptă utilizatorii săi de NX de la o “NX AI”. Opt dintre cereri nu erau întrebări de proiectare. Erau propriul backlog al administratorului, reformulat de oamenii care așteptau după el: construiți-ne o degajare DIN 509 parametrică, adăugați acest material, adăugați această gaură, puneți pe fila Home un buton care rulează programul nostru, explicați această eroare, setați această preferință, spuneți-mi care preferință ce face, ajutați-ne cu NXOpen.

Lista aceea este fișa postului unui administrator CAD și motivul pentru care una sau două persoane sunt gâtul de sticlă pentru un întreg departament: fiecare element este mic, fiecare are nevoie de cineva care știe unde ține NX lucrul respectiv și fiecare ajunge ca tichet în spatele celui anterior.

Angajarea unui al doilea administrator funcționează rareori: aproximativ 133.900 de posturi STEM au rămas neocupate în Germania în martie 2026 (Digital Skills and Jobs Platform), iar administratorii NX cu competențe NXOpen sunt o felie subțire din acel bazin.

Întrebarea utilă nu este “poate o AI să administreze NX” (nu poate și nici nu ar trebui), ci: per cerere, la ce poate răspunde direct un asistent, ce poate pregăti pentru ca administratorul să verifice și ce trebuie să rămână o acțiune umană cu poartă de confirmare. Siemens acoperă singur nivelul de răspuns: Designcenter 2606 (iunie 2026) livrează un Designcenter Copilot fundamentat pe documentație și bune practici, iar Siemens raportează peste 500.000 de utilizări lunare ale funcțiilor sale AI actuale (Blogul Siemens Designcenter, 23 iunie 2026). Nivelul de pregătire și poarta de confirmare sunt propria dumneavoastră configurare.


Opt cereri de admin, sortate după ce are voie să facă un asistent

Regula: întrebările read-only primesc răspuns cu sursa citată; orice produce un fișier, o setare sau cod este pregătit ca artefact pe care administratorul îl revizuiește; orice modifică o bibliotecă partajată, rolul altui utilizator sau un default la nivel de site rulează doar printr-o poartă de confirmare sau este făcut personal de administrator.

Cerere Unde se află în NX Răspuns Pregătire Execută (cu gate)
Degajare DIN 509 forma E după diametrul arboreluiUDF Wizard, bibliotecă UDF sau Reuse LibraryForma E, paginile wizarduluiUDF cu intrări denumite, listă de verificare pentru testePublicare în biblioteca partajată: admin
Adăugați materialul xyzBibliotecă MatML de site/utilizator (XML), setată în Customer DefaultsCe fișier încarcă acest NXIntrare într-o copie sau journal de exportScriere în biblioteca de site: admin
Adăugarea găurii xyz în tabelul de găuriTabele de date XML în folderul de standarde de modelareCe tabel și ce coloaneRând nou într-o copieÎnlocuirea tabelului partajat: admin
Buton pe fila Home în rolul “Standard”Dialogul Customize, user.mtx, roluri, MenuScriptCum se salvează comenzile și rolurileFișiere de rol sau MenuScript de testatRollout către toți utilizatorii: admin
“Programul raportează eroarea xyz”Syslog, fereastra de listare, excepție NXOpenCauze, linii din syslog citateJournal de reproducere, ciornă de tichetNimic
Setați valoarea x la yPreferințe vs. Customer Defaults (.dpv, trei niveluri)Care dintre cele două, care nivelCerere de modificare cu stare de blocareNivel site/grup: admin, în dialog
Care preferință oferă funcția xyz?Dialogul Customer Defaults, ajutorul NXRăspuns cu sursa citatăNimicNimic
Ajutor NXOpenReferința NXOpen, bibliotecile dumneavoastrăMembri API, exemplele dumneavoastrăSchelet, membri verificațiRulare pe date de producție: inginer

Coloana “răspuns” este o sarcină de cunoștințe pentru un asistent read-only precum propriul nostru Chatbot de cunoștințe NX, care își citează sursa și nu poate atinge un model. Coloana “pregătește” este acolo unde se duc orele administratorului și unde este economia. Coloana “execută” este scurtă intenționat.


Patru sarcini de admin parcurse în detaliu

Mecanica a fost verificată față de ajutorul NX și materialele Siemens Community la nivelul lunii septembrie 2026; tot ce depinde de versiunea dumneavoastră de NX sau de structura site-ului, asistentul trebuie să îl citească din mediul dumneavoastră, nu să îl afirme.

Sarcina 1: o degajare DIN 509 forma E parametrică, condusă de diametrul arborelui

Un asistent poate pregăti acest lucru; nu îl poate finaliza. DIN 509 definește patru forme de degajare (E, F, G, H) la umerii arborilor; forma E taie doar în suprafața cilindrică, forma F în ambele suprafețe adiacente (Engineers Edge, caneluri de degajare DIN 509). Adâncimea, lățimea și raza provin dintr-un tabel indexat după diametrul arborelui.

În NX, containerul este un User Defined Feature. UDF Wizard (definiție, features, expresii, referințe, rezumat) stochează rezultatul ca fișier de piesă special, inserat ca un singur feature; bibliotecile se configurează sub Tools, User Defined Feature, Configure Library, iar versiunile mai noi servesc UDF-urile și prin Reuse Library (Ajutor NX: configurarea bibliotecilor UDF).

Ce pregătește asistentul și ce verifică administratorul:

  1. Canelura ca set de features bazat pe schiță, cu expresii denumite (d1 diametrul arborelui; t1, f, r canelura), astfel încât wizardul expune d1 ca singura intrare.
  2. Corespondența diametru-canelură. Wizardul nu face căutări în tabele; logica aceea trăiește în expresii sau într-o căutare referențiată. Aici greșesc asistenții cel mai des, în mod subtil, așa că revizuiți-o mai întâi.
  3. Referințele de plasare (fața umărului, axa arborelui) pe pagina de referințe a wizardului.
  4. Plasări de test pe trei diametre din tabelul DIN, cu t1, f și r citite înapoi și comparate.
  5. Abia apoi: publicarea fișierului de piesă în biblioteca partajată, de către administrator, manual.

O rezervă: DIN 509 este un standard licențiat. Asistentul poate cita tabelele sale doar dacă exemplarul dumneavoastră licențiat se află în corpusul său; dimensiunile de canelură recitate din memorie sunt greșite până la verificare.

Sarcina 2: materiale și tabele de găuri, două editări de biblioteci partajate

Ambele sunt editări ale unor fișiere XML pe care le citește NX-ul tuturor, motiv pentru care stau în coada administratorului.

NX păstrează materialele personalizate într-o bibliotecă de site și o bibliotecă de utilizator, ambele fișiere XML în schema MatML, ale căror locații se setează în Customer Defaults (Gateway, Material Mass: un comutator “Site MatML Library” și un nume de fișier); fișierul livrat physicalmateriallibrary.xml este copia de pornire uzuală, iar materialele se întrețin prin Manage Materials și Manage Library Materials (Swoosh Technologies, biblioteca de materiale de site); NXOpen poate, de asemenea, exporta materialul unei piese într-un fișier de bibliotecă (NX Journaling, crearea unui material de bibliotecă).

Pentru găuri, opțiunile comenzii Hole pentru dimensiunea burghiului, jocul pentru șuruburi și găurile filetate provin din tabele de date standard XML din folderul de standarde de modelare al instalării; numele coloanelor trebuie păstrate, folderul pentru găuri filetate poate fi redirecționat printr-o variabilă de mediu, iar syslog-ul arată ce fișier a încărcat NX de fapt (Eng-Tips, callout-uri personalizate pentru găuri filetate). Este posibil ca administratorul dumneavoastră să le fi mutat pe un share de rețea acum ani de zile; un asistent care editează copia locală nu a schimbat nimic.

Poziția noastră: asistentul pregătește ambele editări într-o copie, cu un diff și o notă privind calea pe care o rezolvă acest NX; administratorul aplică diff-ul. Fișierele partajate nu sunt ceva ce un agent atinge nesupravegheat.

Sarcina 3: un buton în ribbon, într-un rol, care rulează un program

Cererea a fost precisă: rolul “Standard”, aplicația Modeling, fila Home, un buton care rulează programul lor. Mecanica este documentată: în dialogul Customize alegeți New Button, trageți o nouă comandă de utilizator pe ribbon și îi editați numele, pictograma și acțiunea (tipul acțiunii poate fi un fișier journal); astfel de customizări ajung în fișierul utilizatorului user.mtx, iar pentru un rollout la nivel de organizație ajutorul NX trimite la MenuScript (NX Journaling, pornirea unui journal dintr-un buton personalizat). Rolurile se află pe fila Roles, se salvează cu Save Role și se partajează copiind fișierul de rol în folderul de roluri al altei mașini (NCmatic, roluri NX).

Așadar, asistentul pregătește fișierele MenuScript pentru buton, fișierul de rol care îl include și o notă de test de o pagină (aplicație, filă, ce rulează, ce se întâmplă când programul lipsește). Ar trebui să întrebe mai întâi: există “programul xyz” ca journal sau ca DLL NXOpen și rulează sub permisiunile apelantului? Un buton care rulează ceva este o mică implementare (deployment), iar implementările au proprietari.

Ce nu trebuie să facă este să copieze rolul în folderul startup de site sau de grup, astfel încât fiecare utilizator să îl primească la următoarea pornire. Administratorul face asta o singură dată, intenționat, după un test pe o singură mașină.

Sarcina 4: Customer Defaults și “care preferință îmi oferă X”

“Setați valoarea x la y în preferințe” ascunde o întrebare pe care asistentul ar trebui să o pună înapoi: preferință sau customer default? Preferințele se aplică sesiunii sau piesei din fața dumneavoastră. Customer Defaults setează valorile inițiale, se deschid prin File, Utilities, Customer Defaults și există pe trei niveluri, stocate în fișiere .dpv cu un subdirector startup pe care NX nu îl creează pentru dumneavoastră și cu o stare de blocare (lock) per default, odată ce nivelurile sunt configurate (Swoosh Technologies, nivelurile de defaults).

Nivel Setat prin File Cine îl poate modifica
SiteUGII_SITE_DIR, startup (subdirector)*_site.dpvDoar administratorul CAD, toți utilizatorii afectați
GrupUGII_GROUP_DIR, startup (subdirector)*_group.dpvAdministratorul CAD, un singur departament afectat
UtilizatorUGII_LOCAL_USER_DEFAULTS (director plus nume de fișier)*_user.dpvUtilizatorul, dacă nu este blocat la un nivel superior

“Care preferință îmi oferă funcția X” este teren sigur: o întrebare de documentație, cu răspuns din ajutorul NX și cu calea dialogului citată. Acel corpus se mișcă de două ori pe an: Siemens a prezentat în avanpremieră următoarea versiune, Designcenter 2612, la Early Access Program din Mason, Ohio, săptămânile VIP 14 până la 25 septembrie 2026 (Siemens EAP), așa că indexul de ajutor are nevoie de o reîmprospătare la fiecare versiune. “Setați x la y” primește în schimb o cerere de modificare: numele default-ului, nivelul, valoarea, starea de blocare, cine este afectat. O modificare la nivel de utilizator o aplică utilizatorul; o modificare la nivel de site o aplică administratorul în dialog. Am sfătui împotriva conectării oricărui agent astfel încât să scrie fișiere .dpv direct; dialogul este pista de audit.

Acesta rulează ca un POC. Ce lipsește pentru producție: Conformitate GDPR, SSO/Entra, scalare, monitorizare, operare și o poartă de confirmare de tip previzualizare-și-confirmare în fața fiecărui fișier partajat. Închidem decalajul de la “rulează pe mașina administratorului” la “rulează în departamentul de inginerie” cu NX Action Assistant: previzualizare, confirmare, undo, log.


Triajul erorilor: “Programul raportează eroarea XY, ce fac?”

Aceasta este cererea pe care un asistent o gestionează cel mai bine, pentru că tot ce îi trebuie este text. NX scrie un jurnal de sistem (syslog) per sesiune, înregistrând pornirea, variabilele de mediu și fișierele de configurare folosite, apoi evenimentele sesiunii; îl deschideți prin Help, Log File, ajunge în directorul setat de UGII_TMP_DIR, și UGII_KEEP_SYSTEM_LOG setată pe YES îl păstrează după ieșire (Swoosh Technologies, jurnalizarea în NX, Siemens Community, locația syslog-ului NX). Adăugați ieșirea din fereastra de listare și textul excepției NXOpen, iar asistentul are tot ce ar cere un inginer de suport.

Triajul pe care îl propune, în ordine: ce fișier de configurare a încărcat acest NX, dacă programul care eșuează a fost construit pentru această versiune, dacă piesa este o revizie Teamcenter eliberată, dacă rolul și permisiunile se potrivesc cu mașina care funcționează și dacă mesajul se află în propria dumneavoastră listă de probleme cunoscute. Ultimul punct este motivul pentru care istoricul tichetelor aparține corpusului de retrieval. Utilizatorii numesc asta “antrenarea AI-ului pe tichetele noastre”; în practică este retrieval peste tichete plus syslog, nu antrenarea modelului, și este suficient.

Un mic journal NXOpen este adesea primul lucru pe care îl pregătește asistentul, astfel încât tichetul să conțină fapte în loc de capturi de ecran. Acesta afișează mediul pe care îl rezolvă această sesiune, calea syslog-ului și expresiile piesei de lucru. Nu schimbă nimic.

# NX journal (Python): environment and expression inventory for an error-triage ticket.
# Read-only: writes to the listing window, changes nothing in the part.
import NXOpen

session = NXOpen.Session.GetSession()
lw = session.ListingWindow
lw.Open()

# Which directories does THIS NX resolve? (site/group config often differs per machine)
for var in ("UGII_BASE_DIR", "UGII_SITE_DIR", "UGII_GROUP_DIR", "UGII_TMP_DIR"):
    lw.WriteLine(f"{var} = {session.GetEnvironmentVariableValue(var)}")

# The syslog that belongs to this session, for the ticket
lw.WriteLine(f"syslog = {session.LogFile.FileName}")

# Expressions in the work part: name, type and formula (no values are touched)
work_part = session.Parts.Work
for expr in work_part.Expressions:
    lw.WriteLine(f"{expr.Name} [{expr.Type}] = {expr.RightHandSide}")

GetEnvironmentVariableValue, LogFile și ListingWindow sunt membri ai NXOpen.Session; RightHandSide și Tip sunt membri ai NXOpen.Expression (Referința NX Open, clasa Session). Acesta este standardul pentru un asistent care scrie NXOpen: fiecare membru verificat în referință, nu reprodus din memorie, indiferent de modelul din spatele lui (găzduit sau un model open-weight pe propriul dumneavoastră hardware). Cum aduceți în mod fiabil un model la acest nivel explică ghidul nostru despre Generarea de cod cu AI pentru NX Open; peisajul API este acoperit în Programare API Siemens NX.


Ce nu trebuie să facă asistentul niciodată nesupravegheat

Trei acțiuni rămân în spatele unei porți de confirmare în fiecare configurare pe care o construim, oricât de bună ar fi propunerea. Doctrina nu s-a schimbat: AI propune, NXOpen execută, regulile și un om validează.

Acțiune De ce are gate Cum arată poarta de confirmare
Editarea Customer Defaults la nivel de site sau de grupO singură scriere schimbă pornirea pentru fiecare post de lucru; o stare de blocare greșită nu este anulată de utilizatorCerere de modificare, aplicată de administrator în dialog, înregistrată în log
Modificarea unei biblioteci partajate (materiale, tabele de găuri, UDF sau Reuse Library)Fiecare sesiune o citește; un singur rând XML malformat strică o comandă la nivelul întregului siteDiff pe o copie, administratorul aplică, fișierul vechi este păstrat
Implementarea unei customizări de ribbon sau a unui rol pe care îl încarcă alți utilizatoriLivrează o cale executabilă unor oameni care nu au cerut-oTest pe o singură mașină, administratorul copiază în folderul de roluri startup

Mecanismul este cel pe care îl folosesc asistenții noștri de acțiune în model: previzualizare, confirmare explicită, marcaj de undo, linie de audit. Pentru munca de admin, “modelul” este un fișier sau o setare, dar bucla este identică și este ceea ce un Server MCP NX construit pentru producție adaugă peste un strat brut de instrumente (tools). Din experiența noastră, administratorii care adoptă cel mai rapid un asistent sunt cei care văd, din prima zi, că acesta nu poate scrie în directorul lor de site.

Read-only este o arhitectură, nu o setare de politică. Un asistent care “promite” să nu scrie în biblioteca partajată deține în continuare calea și permisiunea; unul care nu poate scrie nu are niciuna dintre ele.


Dacă preferați să predați munca de rutină, serviciile noastre de administrare NX se ocupă de customer defaults, șabloane, roluri și serverul de licențe.

Întrebări frecvente

Ce este AI pentru administrarea NX, într-o singură propoziție?

Un asistent care răspunde la întrebările de administrare CAD din documentația NX și din propriile dumneavoastră standarde, cu surse, pregătește artefacte (UDF-uri, intrări de materiale, cereri de modificare a Customer Defaults, customizări de ribbon, schelete NXOpen) pentru revizuire și nu execută nimic ce atinge fișiere partajate sau setările altor utilizatori fără o poartă de confirmare umană (gate).

NX Knowledge Chatbot vs. Action Assistant pentru sarcini de admin: de care avem nevoie?

Pentru șase dintre cele opt cereri, NX Knowledge Chatbot read-only este suficient: răspunde la “care preferință”, explică erorile din syslog și redactează artefacte ca text. Action Assistant își merită locul atunci când modificările pregătite trebuie aplicate printr-o poartă de tip previzualizare-și-confirmare, de exemplu un default la nivel de utilizator sau un rol per utilizator. Începeți cu nivelul de cunoștințe; adăugați nivelul de acțiune acolo unde administratorul este încă cel care dă click.

Cât costă o configurare de AI pentru administrarea NX?

Punctele noastre de intrare cu scop fix sunt listate pe paginile de servicii: un pilot Knowledge Chatbot cu corpusul dumneavoastră de bază indexat și un proof of concept Action Assistant pentru un singur workflow delimitat, fiecare de patru până la șase săptămâni. Cazurile de utilizare de admin încep de obicei cu pilotul de cunoștințe, pentru că majoritatea cererilor sunt de tip răspunde-și-pregătește.

Poate fi asistentul “antrenat pe datele noastre”, adică pe defaults, biblioteci, tichete și cod NXOpen?

În practică este vorba de retrieval (regăsire de informații), nu de antrenare: exporturile de Customer Defaults, fișierele de bibliotecă, istoricul tichetelor și sursele NXOpen sunt indexate conform regulilor dumneavoastră de acces și citate în răspunsuri. Fine-tuning-ul pe datele clientului este excepția și nu îl pretindem decât dacă un proiect îl cere. Retrieval-ul vă permite, de asemenea, să actualizați corpusul mâine, fără reantrenare.

Înlocuiește asistentul instruirea de admin NX pentru echipa noastră?

Nu. Scurtează coada de așteptare, dar cine aprobă un default la nivel de site sau o bibliotecă partajată trebuie în continuare să îl înțeleagă. Din acest motiv combinăm implementările cu o Instruire Siemens NX focalizată: poarta de confirmare este doar atât de bună cât evaluatorul din spatele ei.


Pasul următor

Trimiteți-ne ultimele douăzeci de tichete ale administratorului dumneavoastră CAD. Le vom sorta în răspunde, pregătește și execută și vă vom arăta primele două categorii rulând pe propria dumneavoastră documentație și pe propriile standarde. Discutați cu inginerii noștri despre un asistent de admin NX



Referințe

  • Siemens Designcenter blog, “Designcenter is for everyone, June 2026 release” (23 iunie 2026): https://blogs.sw.siemens.com/designcenter/designcenter-is-for-everyone-june-2026-release/ (accesat la 2026-09-24)
  • Siemens, “Welcome to the September 2026 Early Access Program for Designcenter” (Designcenter 2612, săptămânile VIP 14 până la 25 septembrie 2026): https://resources.sw.siemens.com/en-US/presentation-welcome-to-designcenter-early-access-program/ (accesat la 2026-09-24)
  • NX help (mirror), “Configuring UDF Libraries from NX”: http://www2.me.rochester.edu/courses/ME204/nx_help/en_US/tdocExt/content/g/udf_udf_manlibs_ug.xml (accesat la 2026-09-24)
  • Swoosh Technologies, “Site Material Library in NX, getting started”: https://www.swooshtech.com/2020/10/08/site-material-library-in-nx-getting-started/ (accesat la 2026-09-24)
  • NX Journaling, “Create library material”: https://nxjournaling.com/content/create-library-material (accesat la 2026-09-24)
  • Eng-Tips, “Custom threaded hole callouts in NX 11”: https://www.eng-tips.com/threads/custom-threaded-hole-callouts-in-nx-11.464588/ (accesat la 2026-09-24)
  • NX Journaling, “Start journal from custom button”: https://www.nxjournaling.com/content/start-journal-custom-button (accesat la 2026-09-24)
  • NCmatic, “NX Roles, managing your custom interface layouts”: https://ncmatic.com/technical-tuesday/nx-roles/ (accesat la 2026-09-24)
  • Swoosh Technologies, “How to define the defaults level of Customer Defaults”: https://www.swooshtech.com/2023/04/06/how-to-define-the-defaults-level-of-customer-defaults/ (accesat la 2026-09-24)
  • Swoosh Technologies, “NX logging business”: https://www.swooshtech.com/2018/06/08/nx-logging-business/ (accesat la 2026-09-24)
  • Siemens Community, “NX Syslog location”: https://community.sw.siemens.com/s/question/0D54O000061wvKCSAY/nx-syslog-location (accesat la 2026-09-24)
  • NX Open C++ Reference Guide, NXOpen::Session și NXOpen::LogFile: https://www.ugapi.com/doc/NXOpen/a05085.html și https://www.ugapi.com/doc/NXOpen/a03979.html (accesat la 2026-09-24)
  • Engineers Edge, “Machined tool relief grooves, DIN 509”: https://www.engineersedge.com/mechanical,045tolerances/machined_tool_relief_grooves_15414.htm (accesat la 2026-09-24)
  • Digital Skills and Jobs Platform, “STEM skills shortage: Germany persists, over 130,000 vacancies remained vacant in March 2026”: https://digital-skills-jobs.europa.eu/en/latest/news/stem-skills-shortage-germany-persists-over-130000-vacancies-remained-vacant-march-2026 (accesat la 2026-09-24)