PMI generate de AI în NX: pe scurt
PMI generate de AI înseamnă că un LLM propune cote și toleranțe pe baza unui ghid scris, iar NXOpen le plasează pe model. inteliScience a rulat acest lucru pe o piesă demo cu propriul chatbot, propriul bridge NXOpen și ghidul nostru intern de PMI: PMI dimensionale au ieșit utilizabile, GD&T nu a fost în scop, iar un om a aprobat în continuare fiecare adnotare.
Problema: autorarea PMI este lentă pentru că regulile trăiesc în oameni
Plasarea unei cote în Siemens NX (Designcenter) înseamnă câteva clicuri. Partea lentă este decizia: ce feature primește o cotă, ce clasă de toleranță se aplică, în ce vedere de model intră și ce notă o însoțește. Decizia aceea stă într-un ghid pe care jumătate din echipă l-a răsfoit și în capul inginerului de metode care l-a scris.
Siemens descrie PMI în Designcenter ca adnotările și metadatele care definesc cum se fabrică o piesă: cote, toleranțe, cadre de control al caracteristicii, referințe (datum), rugozitate, note, organizate în vederi de model. Pagina oficială Designcenter pentru model-based definition acoperă și Convert to PMI pentru vederile de desen moștenite.
Dacă modelul sau desenul trebuie să fie master este o decizie pe care am tratat-o în MBD sau desenul ca master. Acest articol presupune că modelul câștigă și pune următoarea întrebare: cine scrie PMI și după ce reguli.
Ar putea un LLM să citească ghidul nostru și să facă prima trecere? Am încercat.
Ce am construit: un chatbot, un bridge NXOpen și un ghid la mijloc
Trei piese, toate ale noastre: un asistent bazat pe LLM (în spate un LLM găzduit actual, modelul este interschimbabil), un bridge NXOpen care rulează într-o sesiune NX live și ghidul nostru intern de PMI/MBD ca singur input de domeniu. Nu un produs Siemens, nu un plugin din marketplace. Ghidul (reguli de cotare per tip de feature, clase de toleranță pe intervale de dimensiuni, convenții de vederi și note) a intrat neschimbat, ceea ce s-a dovedit cea mai instructivă greșeală a experimentului.
Bucla: asistentul citește ghidul și propune PMI pentru piesa demonstrativă prin bridge (același tip de conexiune LLM–NX pe care am descris-o pentru MCP). Bridge-ul verifică fiecare propunere în raport cu modelul și ghidul, creează doar ce trece verificarea și predă rezultatul unui om în NX.
Regulă internă, de la care nu ne abatem: AI-ul propune, NXOpen execută, regulile și un om validează. LLM-ul nu apelează niciodată NX direct și nu ajunge niciodată să spună “pass”.
Și pentru că întrebarea vine mereu: Designcenter Copilot nu face asta. Pagina Siemens cu sfaturi pentru Copilot (12 mai 2026) descrie asistență ancorată în documentație, cu cuvinte evidențiate în răspuns care funcționează ca linkuri directe către comenzi. NX plus Copilot pentru “cum fac asta”, NX plus un bridge ca al nostru pentru “autorează PMI după regulile noastre”.
Ce a nimerit asistentul și unde a fost nevoie de o trecere umană
A funcționat pentru cazurile simple: găuri străpunse, grosimea plăcii, cote de gabarit, oriunde ghidul are o regulă per tip de feature și un rând de toleranță per interval de dimensiuni. A fost nevoie de o trecere umană oriunde ghidul necesită interpretare și oriunde ghidul tace.
Ce a mers bine: asistentul a citit corect structura ghidului, așa că tipul de feature plus intervalul de dimensiuni au dus la rândul de toleranță corect mai des decât ne așteptam de la un document scris pentru oameni. Cotele au ajuns pe feature-urile pe care le-a numit, cu măsurătorile bridge-ului ca valori nominale, în vederea prescrisă. Iar o citare din ghid la fiecare propunere a schimbat verificarea: în loc de “e corect?”, verificatorul întreabă “chiar spune asta paragraful 4.2?”.
Unde a fost nevoie de o trecere umană, genul de lucruri pe care le verificați de fiecare dată:
- Referință greșită la feature acolo unde două feature-uri arată la fel, dar au funcții diferite (o gaură de poziționare lângă o gaură de trecere de aceeași dimensiune).
- Clasă de toleranță din rândul vecin al tabelului acolo unde o dimensiune stă la granița dintre două intervale.
- PMI duplicate pe feature-uri simetrice acolo unde ghidul așteaptă o singură cotă cu o notă de repetare.
- PMI pe un plan care este permis, dar nu cel pe care l-ar citi un prelucrător.
- Umplerea golurilor cu încredere: acolo unde ghidul nu spunea nimic, asistentul a propus ceva plauzibil. Plauzibil este cuvântul periculos în tot acest subiect.
Timpul de verificare nu a ajuns la zero și nici nu am vrea asta. Verificatorul s-a transformat din autor în auditor, cu o citare de verificat pe fiecare rând.
De ce documentul de ghid contează mai mult decât modelul
Schimbați LLM-ul și rezultatul se mișcă puțin. Schimbați ghidul și rezultatul se schimbă complet. Aceasta este concluzia principală.
Ghidurile PMI ale companiilor stau în aval de două standarde. ASME Y14.41, Digital Product Definition Data Practices, stabilește cerințele pentru pregătirea și revizuirea seturilor de date de definire digitală a produsului. ISO 16792:2021 este echivalentul ISO și acoperă atât seturile de date doar cu model 3D, cât și pe cele model plus desen. Nu am furnizat asistentului niciunul dintre standarde. Ghidul nostru este stratul de companie de deasupra: tabele interne de toleranțe, convenții de vederi, excepții.
Acel ghid a fost scris pentru cititori care umplu golurile cu experiență. Un LLM umple golurile cu plauzibilitate. Așa că majoritatea modurilor de eșec de mai sus sunt eșecuri ale ghidului deghizate în AI: “vezi valorile tipice” în loc de un tabel, un “se aplică atunci când” care trăiește în capul autorului, două reguli care se contrazic în tăcere.
De ce are nevoie un ghid pregătit pentru LLM, din ce a trebuit să reparăm: fiecare regulă de toleranță ca rând explicit de tabel; o condiție “se aplică atunci când” per regulă, legată de un tip de feature pe care bridge-ul îl poate detecta; conflicte rezolvate pe hârtie; un glosar care mapează termenii din ghid la tipurile de feature și vederile din NX; și un număr de versiune, ca fiecare propunere să fie trasabilă.
Recomandarea noastră clară: înainte de a cheltui ceva pe alegerea modelului, investiți timpul în ghid. Supraviețuiește oricărei schimbări de model și se amortizează chiar dacă AI-ul nu ajunge niciodată.
Funcționează pe o piesă demo. Ce lipsește pentru producție: versionarea ghidului, reguli de validare care blochează în loc să avertizeze, eliberare (release) în Teamcenter, un audit trail per adnotare, GD&T și sisteme de referințe (datum) și un pas de aprobare umană care nu poate fi sărit. Închidem acest gol ca proiect cu scop definit: Asistent de autorare PMI pentru MBD în Siemens NX.
PMI generate de AI vs NXOpen bazat pe reguli vs autorare manuală
Trei moduri de a pune PMI pe un model, și nu sunt rivale. NXOpen bazat pe reguli este potrivit când regulile sunt complete și stabile. Autorarea asistată de LLM este potrivită când regulile sunt proză cu goluri. Manualul rămâne pentru tot ce poartă astăzi risc la eliberare (release).
| Criteriu | Autorare PMI manuală | Automatizare NXOpen bazată pe reguli | Asistat de LLM (PMI generate de AI) |
|---|---|---|---|
| Sursa regulilor | Capul proiectantului plus ghidul | Reguli codificate și verificate | Ghidul în context, bridge-ul impune |
| Gestionează ambiguitatea | Da, prin experiență | Nu, cazul nedefinit eșuează sau este sărit | Da, prin ghicire, de aici verificarea umană |
| Repetabilitate | Scăzută între proiectanți | Totală | Ridicată pentru cazurile acoperite, negarantată |
| Explicabilitate | “Pentru că știu” | ID-ul regulii în log | Citare din ghid per adnotare |
| Cine validează | Peer review, dacă există | Regulile, apoi verificarea la eliberare (release) | Mai întâi regulile, apoi un om, întotdeauna |
| GD&T și referințe (datum) astăzi | Da | Da, unde există reguli | Nu în rularea noastră |
| Cel mai potrivit pentru | Piese noi, volum mic | Familii stabile, volum mare | Ghiduri în proză, piese mixte, prima trecere |
Coloana bazată pe reguli nu este teorie. Iar studiul de caz despre automatizarea PMI în industria auto este exact asta: reguli codificate care creează PMI în NXOpen, fără niciun LLM în buclă. Dacă regulile dumneavoastră încap deja în cod, v-am sfătui să nu adăugați un LLM; adaugă o povară de validare de care nu aveți nevoie. LLM-ul își câștigă locul acolo unde ghidul este în mare parte reguli, în parte judecată, niciodată complet terminat.
Ce nu există încă: GD&T, referințe (datum), eliberare (release)
Fără cadre de control al caracteristicii, fără sisteme de referințe (datum), fără eliberare (release) în Teamcenter în această rulare. Acestea sunt pasul următor, și mai greu: o schemă de referințe este o decizie despre cum funcționează piesa și cum va fi fixată, nu o căutare într-un tabel.
GD&T vine după referințe (datum), deci ordinea este fixă. Vrem ca asistentul să propună o schemă de referințe cu o justificare funcțională, iar un om să o accepte sau să o rescrie înainte de a fi generat un singur cadru de control al caracteristicii.
Eliberarea (release) este celălalt gol. O versiune de producție are nevoie de un audit trail per adnotare: ce asistent și ce versiune de ghid au propus-o, ce reguli a trecut, cine a aprobat-o, când a intrat în starea de eliberare (release) din Teamcenter. AI-ul nu decide niciodată pass/fail pe un model eliberat.
Anunțul Siemens pentru lansarea Designcenter din iunie 2026 (cea care a redenumit NX în Designcenter) enumeră operații PMI multi-utilizator concurente în Live Share, iar Early Access Program pentru Designcenter 2612 s-a desfășurat în septembrie 2026. Un bridge care își fixează versiunea de ghid și versiunea de NX supraviețuiește acestei cadențe. Un demo nu.
Cum să încercați asta în propria echipă
Puteți reproduce partea utilă a acestui experiment fără bridge-ul nostru; primii patru pași nu au nevoie deloc de AI.
- Alegeți o piesă demo cu găuri, fețe și un feature simetric. Niciodată geometrie de client pentru prima rulare.
- Auditați ghidul: tabele, “se aplică atunci când”, conflicte rezolvate, glosar, număr de versiune.
- Scrieți contractul bridge-ului înainte de a scrie cod: ce conține o propunere, ce se respinge, ce se loghează.
- Definiți poarta de validare umană. Cine verifică, ce verifică și ce înseamnă “aprobat” în PLM-ul dumneavoastră.
- Începeți doar cu PMI dimensionale. GD&T și referințele (datum) sunt runda a doua.
- Sortați fiecare corecție în “problemă de ghid” sau “problemă de model”. Așteptați-vă ca prima grămadă să fie mai mare.
- Decideți traseul. Preponderent goluri de reguli: reparați ghidul, luați în calcul NXOpen bazat pe reguli. Preponderent decizii de judecată: LLM-ul rămâne, și la fel verificatorul.
Pasul 2 singur îmbunătățește deja autorarea manuală a PMI.
Întrebări frecvente
Ce sunt PMI generate de AI în Siemens NX?
PMI generate de AI sunt informații de produs și fabricație (cote și toleranțe, ulterior GD&T) pe care un LLM le propune pe baza unui ghid scris și pe care un program NXOpen le creează pe model. LLM-ul nu atinge niciodată NX direct: emite propuneri structurate, bridge-ul le validează, iar o persoană aprobă rezultatul.
Poate Designcenter Copilot să creeze PMI din ghidul meu?
Nu așa cum îl descrie Siemens. Designcenter Copilot răspunde la întrebări ancorate în documentația Siemens și vă trimite la comenzile potrivite. Autorarea PMI după regulile propriei companii este o altă sarcină, de aici asistentul nostru și bridge-ul NXOpen proprii.
PMI generate de AI vs automatizare PMI bazată pe reguli în NXOpen: cu care începem?
Bazat pe reguli, dacă ghidul dumneavoastră se citește deja ca un cod: tabele complete, fără decizii de judecată. Asistat de LLM, dacă este proză cu goluri și vreți o primă trecere pe care un verificator o poate audita. În ambele cazuri, curățarea ghidului vine prima, iar eliberarea (release) rămâne în responsabilitatea unui om.
Cât costă un pilot de autorare PMI cu AI?
Depinde mai mult de starea ghidului dumneavoastră decât de AI. Tabelele explicite țin contractul bridge-ului scurt; un ghid în proză înseamnă că pilotul începe cu muncă de metode. Îl dimensionăm ca proiect cu preț fix după ce citim ghidul dumneavoastră, nu dintr-o listă de prețuri.
Decide AI-ul dacă PMI sunt corecte?
Nu, și nici nu ar trebui. Bridge-ul respinge tot ce nu corespunde modelului sau tabelelor din ghid, iar o persoană aprobă fiecare adnotare înainte de eliberare (release). AI-ul propune, NXOpen execută, regulile și un om validează.
Pasul următor
Vreți să vedeți propriul ghid de PMI rulat pe o piesă demo? Rezervați o discuție de strategie gratuită și aduceți ghidul. Discutați cu inginerii noștri despre PMI generate de AI în NX