Automatizare NX Open în aerospațial: pe scurt
Automatizarea NX Open în aerospațial înseamnă citirea definiției bazate pe model din Siemens NX cu ajutorul codului, astfel încât caracteristicile, baloanele și pachetele de inspecție să fie generate, nu transcrise. inteliScience construiește asta on-premise, pe licențele NX pe care le dețineți deja. Furnizorii care livrează o inspecție a primului articol per piesă văd efortul manual scăzând de la o zi de lucru la sub o oră.
| Inspecție condusă de desen | PMI citit de NX Open | |
|---|---|---|
| Lista de caracteristici | Tastată de pe desen | Interogată din model |
| Numerotarea baloanelor | Manuală, la fiecare revizie | Generată, stabilă între revizii |
| O modificare de toleranță | Model, desen, plan, FAIR | O singură editare, totul se regenerează |
Problema: zece ani de comenzi în portofoliu, o zi per prim articol
Portofoliul de comenzi nu este constrângerea. La finalul lunii aprilie 2026, Airbus avea 8.971 de aeronave în portofoliu — aproximativ 10,3 ani de producție față de ținta de 870 de livrări pentru acest an — iar Boeing 6.807, circa 10,1 ani la ritmurile actuale. Airbus se luptă în continuare cu aprovizionarea de motoare pentru a atinge Rate 75 la A320neo.
Tot ce urmează în aval este o chestiune de capacitate, iar la furnizori capacitatea care se epuizează prima nu este prelucrarea. Este documentația.
Gândiți-vă cât costă o inspecție a primului articol făcută manual. AS9102 cere ca fiecare caracteristică de proiectare să fie identificată, numerotată și raportată. Făcut manual, un singur FAIR poate absorbi o zi întreagă de lucru per piesă; echipele care folosesc software de ballooning ce leagă numerele baloanelor direct de Formularul 3 raportează aceeași muncă în aproximativ zece minute. Pentru un suport cu 95 de caracteristici, doar manopera a fost estimată la circa 800–1.000 $ — înainte de timpul pe CMM și înainte de orice reinspecție.
Înmulțiți acum cu o familie de piese, cu o creștere de ritm, cu fiecare revizie care resetează obligația de FAI. Transcrierea este costul. Iar transcrierea este singura activitate în care o mașină este net mai bună decât un inginer senior, pentru că mașina nu se plictisește la caracteristica șaizeci.
NX Open, pe scurt
NX Open este interfața de programare către Siemens NX — redenumit Designcenter odată cu versiunea din iunie 2026, disponibilă general din 23 iunie 2026. Numele s-a schimbat; API-ul nu. Există legături pentru C++, C# și VB.NET, Java și Python, iar tot ce puteți construi interactiv puteți construi, interoga și modifica din cod.
Trei capabilități fac cea mai mare parte a muncii într-un context aerospațial, iar una dintre ele nu este evidentă.
Journaling transformă o sesiune interactivă în cod sursă executabil. Un inginer de calcul sau de fabricație care nu scrie software poate produce un prim script funcțional făcând treaba o dată, cu înregistrarea pornită. Fiecare proiect al nostru începe aici, pentru că surprinde ce fac oamenii cu adevărat, nu ce spune documentul de proces — iar în aerospațial cele două au divergat de regulă.
Accesul de interogare la PMI și cote este cel neevident și motivul pentru care automatizarea se plătește în această industrie. NX păstrează informațiile de produs și fabricație ca obiecte structurate conform ASME Y14.41, nu ca text prins de o vedere. Toleranțele, referințele de bază, specificațiile de suprafață și notările geometrice au valori pe care un script le poate citi. Aceasta este diferența dintre automatizare și OCR.
Knowledge Fusion poartă regulile care nu au voie să fie încălcate și se reevaluează odată cu geometria. Pentru un furnizor care lucrează după standardul de proiectare al unui client, pe mai multe programe, așa încetează standardul să mai fie un PDF pe care oamenii ar trebui să-l fi citit.
Și o a patra, pentru adopție, nu pentru capabilitate: Block UI Styler construiește dialoguri NX native, astfel încât o automatizare apare ca buton în panglică, nu ca un script cu un nume de fișier pe care doar autorul îl ține minte. Tratăm dialogul ca parte a livrării. Uneltele fără dialog sunt folosite de o singură persoană și mor când acea persoană schimbă echipa.
MBD este precondiția, nu proiectul
Definiția bazată pe model este vândută ca inițiativă de reducere a desenelor. În practică este precondiția care face automatizabil tot ce urmează în aval, iar industria aerospațială știe asta de mult. Departamentul american al Apărării a codificat pachetele tehnice fără desene prin MIL-STD-31000A încă din 2013, ceea ce permite ca un model 3D singur să servească drept bază contractuală de fabricație și inspecție. AS9102 Rev C presupune că lucrați astfel.
Poziția noastră, la fel de mult din proiectele care au mers prost cât și din cele care au mers bine: nu automatizați peste un PMI inconsistent. Un generator alimentat cu definiție incompletă industrializează incompletitudinea, rapid, cu o urmă de audit care dovedește că ați făcut-o deliberat.
Așa că prima automatizare este o verificare, nu un generator. O poartă de eliberare care parcurge fiecare piesă și verifică lucrurile de care vor depinde uneltele din aval — fiecare cotă are o toleranță, fiecare feature trimite la un cadru de referință, atributele de material și de finisaj sunt completate, niciun PMI nu e desprins de geometrie. Se scrie într-o după-amiază și rulează în câteva secunde per piesă. Este totodată cel mai puțin spectaculos punct din orice foaie de parcurs și cel care decide dacă restul funcționează. Acesta este nucleul a ceea ce construim ca automatizare a conformității MBD și PMI.
Nu sunteți sigur cât de complet este de fapt PMI-ul dvs. pe un întreg program? Nimeni nu este, până când ceva le numără. Rularea verificării peste o familie de piese este un exercițiu de câteva zile, nu un proiect — iar rezultatul rearanjează de obicei foaia de parcurs.
Extragerea caracteristicilor din model
Odată ce definiția este de încredere, pachetul FAI încetează să mai fie muncă de transcriere. Scriptul de mai jos parcurge cotele din piesa de lucru, atribuie numere de caracteristică stabile și produce nucleul unui Formular 3 AS9102.
# NX Open (Python) - export dimensional characteristics as an AS9102 Form 3 seed.
# Run with the part open as work part (Developer tab > Journal > Play).
import csv
import NXOpen
def attr(obj, title, default=""):
try:
return obj.GetStringUserAttribute(title, -1)
except NXOpen.NXException:
return default
def characteristic_rows(part):
"""One row per dimension. PMI dimensions live in the same collection."""
rows = []
for index, dim in enumerate(part.Dimensions, start=1):
text = " ".join(dim.GetDimensionText()[0]) # main text lines; [1] is the dual text
rows.append({
"char_no": index, # stable while the model is stable
"type": dim.__class__.__name__, # LinearDimension, RadialDimension, ...
"value": text,
"key_char": attr(dim, "KEY_CHARACTERISTIC", "N"),
})
return rows
def main():
session = NXOpen.Session.GetSession()
part = session.Parts.Work
lw = session.ListingWindow
lw.Open()
rows = characteristic_rows(part)
if not rows:
lw.WriteLine("No dimensions found - is the PMI loaded?")
return
out = part.FullPath.replace(".prt", "_form3.csv")
with open(out, "w", newline="", encoding="utf-8") as fh:
writer = csv.DictWriter(fh, fieldnames=list(rows[0].keys()))
writer.writeheader()
writer.writerows(rows)
keys = sum(1 for r in rows if r["key_char"] == "Y")
lw.WriteLine("%d characteristics exported to %s" % (len(rows), out))
lw.WriteLine("%d flagged as key characteristics" % keys)
if __name__ == "__main__":
main()Două lucruri contează aici mai mult decât codul. În primul rând, poate rula headless prin run_journal, deci poate procesa o familie întreagă de piese peste noapte, în loc să aștepte ca cineva să apese un buton. În al doilea rând, numerotarea derivă din model, deci este reproductibilă: rulați-l din nou după o revizie și caracteristicile neschimbate își păstrează numerele. Ballooning-ul manual nu are această proprietate, iar re-ballooning-ul după fiecare revizie este locul unde dispare surprinzător de mult timp de inginerie de calitate.
De aici, pachetul se completează singur. Baloane scrise înapoi pe desen sau pe vederea PMI, Formularele 1 și 2 completate din atributele pieselor și structura ansamblului, valori măsurate reconciliate din ieșirea CMM. Munca noastră de inspecție automată a primului articol AS9102 pentru furnizori este exact această conductă, întărită.
Teamcenter și restul firului digital
O listă de caracteristici care stă ca CSV pe desktopul cuiva este o îmbunătățire față de tastare, dar nu cu mult mai mult.
Valoarea apare când aceeași automatizare scrie în PLM. NX Open cu integrarea Teamcenter poate împinge caracteristici, statusul inspecției și legături de revizie pe revizia de item, astfel încât înregistrarea inspecției este atașată configurației căreia îi aparține, nu unui folder. Când clientul întreabă ce revizie a cărei piese a fost inspectată față de ce set de caracteristici, aceea devine o interogare, nu un proiect de arheologie.
Același lucru se aplică în amonte. O singură definiție guvernată stă la baza tuturor capabilităților Siemens NX pe care le implementăm — alternativa, adică un model, un PDF de desen, un plan de inspecție și un FAIR care ar trebui să coincidă, înseamnă patru artefacte care într-o zi nu vor mai coincide. Într-un audit AS9100, neconcordanța este o constatare.
Unde își are locul AI-ul și unde nu
Versiunea Designcenter din iunie 2026 a adăugat Designcenter Copilot, un asistent în limbaj natural ancorat în documentația Siemens și în activitatea curentă a utilizatorului. Bun pentru “cum fac asta în NX”. Nu știe nimic despre standardul de proiectare al clientului dvs. sau despre specificațiile dvs. de proces aprobate.
Cazul cu valoare reală în aerospațial este asistentul de cunoștințe peste propriile documente guvernate — specificații de proces, standarde de client, dispoziții anterioare pentru neconformități, raționamentul din spatele deciziilor luate într-un program în 2017. Inginerii petrec ore căutându-le și adesea le re-deduc în loc să le găsească. Un sistem de regăsire peste acel corpus răspunde în câteva secunde.
Condiția nu este negociabilă și este motivul pentru care majoritatea piloților AI din aerospațial se blochează: fiecare răspuns trebuie să citeze documentul-sursă și revizia. Un asistent care produce un paragraf sigur pe sine, fără proveniență, este inutilizabil când întrebarea este “pe ce bază ați dispus asta”. Le construim cu urma de audit ca rezultat de prim rang, nu ca pe o jurnalizare adăugată ulterior — iar pentru programele cu control de export, pe hardware din propria dvs. rețea, folosind modele cu ponderi deschise precum Llama 3.3 70B.
Pentru generarea codului NX Open în sine, modelele de frontieră precum claude-opus-5-5 sunt cu adevărat puternice și le folosim zilnic. Tot ele inventează apeluri API cu deplină încredere — metode care nu există, argumente în ordine greșită, clase dintr-un namespace vecin. Fiecare script generat trece printr-o verificare de import și printr-o rulare pe o piesă de referință înainte ca un om să-l revizuiască. Bucla aceasta nu este opțională; fără ea ați relocat munca, nu ați eliminat-o.
Un prim trimestru rezonabil
| Weeks | Focus | Rezultat |
|---|---|---|
| 1–2 | Înregistrați fluxurile FAI și de eliberare; numărați orele per piesă și per revizie | Un caz de business în ore, nu în adjective |
| 3–5 | Construiți verificarea de completitudine PMI; rulați-o pe o familie de piese | O listă de defecte și o imagine realistă a datelor dvs. |
| 6–10 | Extragerea caracteristicilor plus generarea Formularului 3, cu un dialog Block UI Styler | Nucleul FAI produs din model, în batch |
| 11–13 | Scrieți rezultatele înapoi în Teamcenter sau extindeți la ballooning pe vederile PMI | Înregistrarea atașată configurației |
Am descuraja pornirea cu familia cea mai grea și cea mai critică pentru siguranță doar pentru că doare cel mai tare. Începeți cu familia pe care o livrați cel mai des. Date mai curate, dovadă mai rapidă și un departament de calitate care a văzut deja că funcționează, înainte să îndreptați asta spre ceva mai important.
Celălalt mod de eșec este mai subtil. Echipele automatizează uneori un proces care ar fi trebuit simplificat mai întâi — un flux de eliberare în unsprezece pași, cu două aprobări pe care nimeni nu le poate justifica. Automatizați zece dintre acei pași și ați făcut un proces prost rapid și permanent. Petreceți prima săptămână întrebând ce pași există dintr-o cerință și ce pași există dintr-o obișnuință.
Întrebări frecvente
Cât costă o automatizare FAI cu NX Open?
O primă implementare — verificări PMI, extragerea caracteristicilor, generarea Formularului 3, un dialog și predarea — se situează de obicei între 12.000 € și 35.000 €. Ce mișcă cifra este starea PMI-ului, nu codul: o familie cu definiție consistentă și completă e simplă, în timp ce un parc mixt de modele vechi are nevoie întâi de remediere. Dimensionăm după rularea verificării de completitudine, care este un exercițiu scurt în sine.
Avem nevoie de MBD complet ca să funcționeze ceva din toate astea?
Nu complet, dar consistent. Automatizarea citește ce este în model, așa că o familie cu PMI complet poate fi automatizată chiar dacă restul companiei încă emite desene. Ce nu funcționează este PMI parțial exact pe piesele pe care le automatizați — asta produce liste de caracteristici incomplete în tăcere, ceea ce e mai rău decât să le tastați.
NX Open sau o unealtă comercială de ballooning?
Dacă aveți nevoie de ballooning standard pe desene și datele sunt ordonate, o unealtă comercială este mai ieftină și mai rapid de implementat — o spunem des. NX Open își câștigă locul când logica este a dvs.: numerotare specifică clientului, reguli de caracteristici-cheie dintr-un standard de proiectare, scriere înapoi în Teamcenter sau reconciliere cu un format de ieșire CMM pe care nu-l suportă nimeni altcineva.
Va satisface asta un audit AS9100?
Automatizarea nu schimbă ce se cere; schimbă cât de consistent produceți acel lucru. Auditorii reacționează de obicei bine la dovezi generate, pentru că sunt reproductibile, iar logica de generare poate fi inspectată. Păstrați controalele obișnuite — scripturi sub control de versiune, modificări trecute prin review, nimic care scrie într-o linie de bază eliberată fără aprobare — și documentați fluxul de date ca parte a livrării.
Poate rula fără o licență NX pentru fiecare utilizator?
Automatizarea are nevoie de o licență NX ca să se execute, dar nu de una pentru fiecare persoană. Execuția batch prin run_journal pe un server folosește licențele pe care le dețineți deja, așa cum implementează majoritatea clienților noștri rulările de noapte. Uneltele interactive cu dialog consumă sesiunea utilizatorului, pentru că rulează în NX prin proiectare.
Pasul următor
Aduceți o familie de piese și ultimul pachet FAI pe care l-ați produs manual. O oră este suficientă ca să stabilim ce se poate automatiza, ce necesită mai întâi remedierea datelor și cât costă.
Discutați cu inginerii noștri despre automatizarea fluxului dvs. MBD și de inspecție