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 workflow-uri Teamcenter: antrenat pe customizarea dvs.

AI pentru workflow-uri Teamcenter: versiunea scurtă

AI pentru workflow-uri Teamcenter este un asistent fundamentat pe propria dvs. customizare Teamcenter: modelul de date BMIDE, șabloanele de workflow și argumentele handlerelor, stylesheet-urile XRT și codul SOA sau ITK. inteliScience îl construiește ca retrieval (regăsire de informații) plus acces prin instrumente pe un mediu de test, nu ca model fine-tuned. Redactează și explică; administratorul dvs. este în continuare cel care implementează.

Cerința utilizatorilor Ce face asistentul Ce rămâne la administrator
Crearea de workflow-uri și handlereExplică șabloanele dvs., redactează argumente pentru handlereSalvează șablonul în Workflow Designer
Construirea de stylesheet-uriRedactează modificări XRT pe baza stylesheet-urilor dvs. înregistrateImplementează dataset-ul, setează preferința
Programare SOAGenerează schelete de client, explică erorileCompilează, testează, integrează
Întrebări despre modelul de dateRăspunde din exportul șablonului dvs. BMIDEModifică modelul în BMIDE

Problema: fiecare Teamcenter este diferit, iar un Copilot generic nu cunoaște handlerele dvs.

Când administrarea CAD a unui constructor de mașini din DACH a strâns ce așteaptă utilizatorii săi de la un “NX AI”, blocul Teamcenter a fost partea cea mai sceptică a listei. Formularea exactă: Teamcenter este de obicei puternic customizat, deci poate fi AI-ul antrenat pe propriul nostru model de date, pe workflow-urile și procesele noastre? Apoi trei întrebări suplimentare: ajutor la crearea de workflow-uri și cunoașterea handlerelor, construirea de stylesheet-uri, programare SOA.

Scepticismul este justificat. O instalare veche de zece ani poartă un șablon custom cu propriile tipuri de item, șabloane de workflow pe care nimeni nu le-a mai documentat de când a plecat consultantul, stylesheet-uri editate direct pe loc și handlere ITK ale căror argumente trăiesc în capul unui singur administrator. Nimic din toate acestea nu este public, așa că niciun model al vreunui furnizor nu le-a văzut.

Asistentul propriu al Siemens ilustrează limita. Teamcenter 2606, lansat pe 12 iunie 2026, oferă “AI recommendations for workflow templates and task assignments based on past usage” și un prim agent Teamcenter pentru lucrul cu BOM [1]. Util, iar noi am analizat unde Siemens Copilot ajută și unde se oprește. Nu citește documentația handlerelor dvs., nu știe de ce isc_material este obligatoriu la eliberare și nu va redacta o modificare XRT pentru un stylesheet pe care l-ați înregistrat în 2019.

Platforma nu este problema; pe 22 septembrie 2026 Siemens a raportat că G2 a clasat Teamcenter pe locul unu între software-urile PLM pe baza recenziilor clienților [7]. Problema este stratul de deasupra, pe care nimeni din afara zidurilor dvs. nu l-a văzut.

Așadar, răspunsul sincer la această întrebare este: da, dar “antrenat” este modelul mental greșit. Restul acestui ghid explică cum arată cel corect.


Ce înseamnă cu adevărat “antrenat pe Teamcenter-ul nostru”

În practică înseamnă retrieval peste artefactele customizării dvs., plus acces prin instrumente la un mediu de test. Modelul rămâne unul general; ce se schimbă este ce poate citi și ce poate apela. Fine-tuning-ul pe un export BMIDE sună atrăgător și funcționează prost: modelul de date se schimbă la fiecare implementare de șablon, iar un model fine-tuned nu poate spune “nu am găsit acea proprietate”. Retrieval-ul poate.

Sursele, în ordinea în care le încărcăm:

Sursă Format Ce permite Frecvența de actualizare
Șablon BMIDE customXML-ul șablonului din output-ul de packaging, plus raportul modelului de date BMIDERăspunsuri despre tipuri de item, proprietăți, LOV-uri, relații, reguli de denumireLa fiecare implementare de șablon
Șabloane de workflowExport de șabloane din Workflow Designer“Ce handlere rulează pe acțiunea Start a sarcinii noastre de eliberare, cu ce argumente?”La fiecare modificare de șablon
Referința handlerelorDocumentația Siemens Workflow Designer pentru versiunea dvs., plus README-ul handlerelor dvs. customExplicarea argumentelor, propunerea de handlere EPM-* pentru o regulă nouăLa fiecare upgrade Teamcenter
Stylesheet-uri XRTXMLRenderingStylesheet dataset-uri exportate ca XML, împreună cu .REGISTEREDTO preferințeRedactarea de modificări la randările Summary, Create și FormLa modificare, verificat pe serverul de test
Surse SOA și ITKRepository-uri Git, scripturi de build, cataloage de eroriSchelete de client, explicarea erorilor de compilare și de runtimeLa fiecare commit pe branch-ul main
Documentația proprie a customizării dvs.Pagini wiki, fișiere Word, note de upgrade, istoricul tichetelor“De ce are șablonul nostru ECR un al doilea pas de revizuire?”Săptămânal sau la modificare

Tot ce este în acest tabel există deja în instalarea dvs.; nimic nu trebuie scris special pentru AI. Și fiecare rând are un declanșator de actualizare, ceea ce face diferența dintre un asistent care are dreptate în martie și unul care are dreptate și după upgrade-ul din decembrie.

Accesul prin instrumente este cealaltă jumătate. Asistentul primește o sesiune de citire pe un Teamcenter de test, prin SOA, sub un utilizator nominal cu permisiunile unui inginer obișnuit, astfel încât poate verifica o afirmație (“există acest stylesheet și la ce tip este înregistrat?”) în loc să ghicească. Este modelul de permisiuni pe care l-am folosit pentru asistentul AI privat de cunoștințe pe documente de inginerie: acces de citire, fără superuser de serviciu, fiecare interogare înregistrată în log.

Poziția noastră clară: un furnizor care spune “antrenat pe datele dvs.” și nu vă poate arăta lista surselor și declanșatorul de actualizare pentru fiecare rând vinde un model generic cu un prompt în față.


Crearea de workflow-uri și cunoașterea handlerelor

Aici un asistent fundamentat pe șabloanele dvs. își merită banii, pentru că munca de workflow în Teamcenter este în cea mai mare parte citire: un nou proces de eliberare înseamnă 20 la sută modelare în Workflow Designer și 80 la sută aflat care handler, pe care acțiune, cu care argument, face deja ceea ce aveți nevoie.

Mai întâi elementele de bază verificate. Handlerele de workflow Teamcenter sunt programe ITK mici atașate acțiunilor unei sarcini. Handlerele de regulă (rule handlers) blochează sau permit trecerea unei sarcini și returnează EPM_go sau EPM_nogo; handlerele de acțiune fac ceva, de exemplu atașează obiecte sau setează un status [2]. Siemens livrează un catalog amplu: EPM-check-condition, EPM-check-object-properties și EPM-hold pe partea de reguli; EPM-attach-related-objects, EPM-set-status, EPM-auto-assign și EPM-create-sub-process pe partea de acțiuni [2]. EPM-attach-related-objects, de exemplu, primește ca argumente o relație, un tip de atașament și un tip de obiect pentru a aduce obiectele asociate în proces [3]. Handlerele proprii se scriu în ITK și se înregistrează la motorul de workflow; anatomia unui rule handler propriu este în ghidul nostru despre ITK, SOA și automatizarea PLM.

Ce poate face asistentul cu toate acestea, când are încărcate exportul șabloanelor dvs. și referința Siemens a handlerelor:

  1. Explicarea unui șablon existent. “Listează fiecare handler de pe șablonul nostru ISC_Release_v4 per sarcină și acțiune și marchează-le pe cele custom.” O întrebare de retrieval, verificabilă linie cu linie.
  2. Redactarea unei configurații de handler. “Blochează sarcina de eliberare dacă isc_material este gol pe oricare dintre reviziile țintă.” Asistentul propune un handler de regulă cu argumente, spune dacă un handler standard acoperă cazul și semnalează când este necesar un handler ITK custom.
  3. Diagnosticarea unui proces blocat. Lipiți log-ul procesului; asistentul asociază eroarea cu handlerul și argumentul care au produs-o, folosind README-ul handlerelor dvs. în loc de o presupunere generică.
  4. Compararea a două șabloane înainte de un upgrade, când Siemens schimbă comportamentul handlerelor standard și nimeni nu-și mai amintește care dintre cele 40 de șabloane ale dvs. depind de el.

Ce nu face: nu salvează șablonul. Administratorul aplică propunerea în Workflow Designer pe serverul de test, trece un item real prin ea și abia apoi o promovează. Sintaxa argumentelor este, de asemenea, locul unde asistentul trebuie să fie onest: dacă referința pentru versiunea dvs. nu documentează un flag, răspunsul corect este “nedocumentat pentru 2606, verificați cu Siemens”, nu unul inventat.


Construirea de stylesheet-uri

Stylesheet-urile sunt configurare, nu cod, ceea ce le face cea mai ușoară dintre cele patru cerințe și cea în care un răspuns greșit este cel mai vizibil. O modificare XRT redactată fie se randează pe serverul de test, fie nu.

Faptele de la care pornim: stylesheet-urile Teamcenter sunt documente XML stocate în dataset-uri XMLRenderingStylesheet pe server, înregistrate la un obiect de business prin preferințe precum .SUMMARYRENDERING, .CREATERENDERING și .FORMRENDERING, cu o preferință .REGISTEREDTO per stylesheet înregistrat [4]. Active Workspace folosește același mecanism cu propriile stylesheet-uri (prefixul Awp0 este indiciul) și are un editor XRT care îi permite unui administrator să editeze un stylesheet și să implementeze modificarea în baza de date fără un build [5]. Teamcenter 2606 extinde administrarea self-service pe Teamcenter X la mai multe dintre aceste configurări [1].

Cu exporturile stylesheet-urilor dvs. încărcate, asistentul poate răspunde la “care stylesheet randează sumarul pentru revizia noastră de ISC_Assembly în Active Workspace și unde este afișat isc_material ?” și poate redacta editarea XML care adaugă o proprietate, mută o secțiune sau ascunde o coloană. Poate răspunde și la întrebarea care costă cel mai mult timp în lucrul cu stylesheet-uri: dacă proprietatea există măcar pe acel tip în șablonul dvs. BMIDE.

Poarta de confirmare (gate) rămâne aceeași. Administratorul importă dataset-ul pe serverul de test și verifică obiectul atât în Active Workspace, cât și în Rich Client, pentru că un stylesheet care se randează într-un client și nu în celălalt este un mod de eșec pe care încă îl vedem în instalările care rulează ambele.

Acesta rulează ca un POC. Ce lipsește pentru producție: acces la Teamcenter-ul dvs. care respectă permisiunile, SSO/Entra, un audit trail per acțiune, monitorizare, operare. Închidem decalajul de la “rulează pe mașina mea” la “rulează în întreprindere”: vedeți Teamcenter Action Assistant, asistentul nostru PLM care acționează sub permisiunile proprii ale utilizatorului.


Asistență la programarea SOA și ITK

Generarea de cod pentru Teamcenter funcționează, cu o regulă nenegociabilă: nimic din ce scrie asistentul nu contează până nu compilează și nu rulează pe serverul de test. Numim asta poarta de compilare și testare (compile-and-test gate) și există pentru că modelele de limbaj sunt încrezătoare în privința unor nume de API pe care nu le-au văzut niciodată. Măsurătorile noastre pe NXOpen au arătat că modelele frontier inventează 4 până la 6 la sută dintre membrii API, iar Teamcenter SOA este un corpus public mai mic decât NXOpen.

Ceea ce face asistența SOA fiabilă este că suprafața este documentată și tipizată. Binding-urile client Java expun câte o clasă de serviciu per domeniu, iar punctul de intrare a fost stabil ani de zile: o Connection din com.teamcenter.soa.client, un SessionService pentru login și un DataManagementService a cărui proprietate getProperties , operație care primește un array de obiecte model și un array de nume de proprietăți [6]. Un schelet pe care asistentul ar trebui să-l poată produce din referință și pe care îl verificăm pe biblioteca client strong-typed a versiunii dvs.:

// TcReadProps.java - Teamcenter SOA Java client skeleton (strong-typed bindings)
// Verify against the services reference of your release before use.
import com.teamcenter.soa.SoaConstants;
import com.teamcenter.soa.client.Connection;
import com.teamcenter.soa.client.model.ModelObject;
import com.teamcenter.services.strong.core.SessionService;
import com.teamcenter.services.strong.core.DataManagementService;

public class TcReadProps {
    public static void main(String[] args) throws Exception {
        // credentialManager implements com.teamcenter.soa.client.CredentialManager (app-specific)
        Connection connection = new Connection("https://plm-test.example.com/tc",
                credentialManager, SoaConstants.REST, SoaConstants.HTTP);

        SessionService session = SessionService.getService(connection);
        session.login("j.miller", "***", "Chassis", "Design Engineer", "en_US", "tc-read-props");

        // objects[] is resolved earlier, e.g. through a saved query or a loadObjects call
        ModelObject[] objects = resolveTargets(connection);
        DataManagementService dm = DataManagementService.getService(connection);
        dm.getProperties(objects, new String[] { "item_revision_id", "isc_material" });

        for (ModelObject obj : objects) {
            System.out.println(obj.getPropertyDisplayableValue("item_revision_id") + " "
                    + obj.getPropertyDisplayableValue("isc_material"));
        }
        session.logout();
    }
}

Cele două placeholder-e sunt intenționate. Credential manager-ul este partea pe care fiecare instalare o scrie diferit (SSO, Kerberos, un vault), iar rezolvarea obiectelor depinde de modelul dvs. de date. Un asistent cu repository-urile dvs. încărcate le completează pe ambele din codul dvs. existent, ceea ce este tocmai rostul fundamentării lui pe sursele dvs.

Pentru ITK poarta este mai strictă, pentru că ITK rulează în interiorul procesului server. Asistentul este bun la trei lucruri: explicarea unei erori ITK sau de handler din syslog pe baza catalogului dvs. de erori, redactarea unui schelet de handler cu include-urile și convenția de return EPM_go/EPM_nogo și revizuirea gestionării memoriei în codul existent. Nu atinge niciodată bibliotecile de producție; administratorul face build, implementează pe test, rulează setul de regresie de workflow-uri reale, apoi promovează, disciplina descrisă în practica noastră de customizare a serverului Teamcenter.

Nu recomandăm să lăsați vreun asistent să apeleze operații SOA care modifică date pe producție, chiar și cu un pas de confirmare, până când versiunea read-only nu a rulat câteva luni și administratorii PLM nu i-au revizuit audit trail-ul. Întâi citește, apoi acționează.


Guvernanță: mediu de test, principiul celor patru ochi, audit trail

Asistentul este exact atât de sigur cât este mediul spre care este îndreptat. Trei reguli acoperă cea mai mare parte din ce întreabă un administrator PLM la prima întâlnire.

  1. Doar mediul de test. Sesiunea Teamcenter a asistentului trăiește pe serverul de test, cu o copie a șablonului de producție. Producția este atinsă de oameni, prin pipeline-ul de implementare existent.
  2. Patru ochi pe fiecare modificare. O configurație de handler, un stylesheet sau o modificare de cod redactate sunt revizuite de un administrator înainte de a fi aplicate, iar revizuirea este înregistrată, regula pe care majoritatea organizațiilor din DACH o aplică deja implementărilor BMIDE.
  3. Două audit trail-uri. Asistentul înregistrează cine ce a întrebat și ce surse a folosit; Teamcenter înregistrează ce a făcut utilizatorul nominal în sesiune. Împreună, răspund un an mai târziu la “de ce arată acest șablon așa”.

Unde rulează? Pe infrastructura dvs. sau într-un cloud din UE, pentru că exportul BMIDE și sursele ITK sunt printre cele mai sensibile documente pe care le deține o organizație de inginerie. inteliScience livrează acest lucru din România, cu o oră înaintea DACH, cu inginerii Teamcenter care scriu și handlerele, ceea ce contează când un răspuns trebuie verificat de cineva care poate citi ITK.


Întrebări frecvente

Poate fi un AI antrenat cu adevărat pe propriul nostru model de date și pe workflow-urile noastre Teamcenter?

Da, dacă “antrenat” înseamnă fundamentat pe surse. Asistentul regăsește informații din exportul șablonului dvs. BMIDE, exporturile șabloanelor de workflow, dataset-urile de stylesheet-uri, sursele SOA și ITK și documentația dvs. proprie și interoghează un Teamcenter de test prin SOA pentru a verifica răspunsurile. Nu facem fine-tuning unui model pe datele clientului; retrieval-ul rămâne actual după fiecare implementare de șablon și îi permite asistentului să spună când ceva nu se află în surse.

Cât costă un asistent AI pentru workflow-uri Teamcenter?

Proof of concept-ul nostru Teamcenter Action Assistant este oferit la un preț fix, publicat pe pagina sa de servicii: două tipuri de acțiuni live pe Teamcenter-ul dvs., inclusiv maparea obiectelor BMIDE, pe parcursul a cinci până la șapte săptămâni, deductibil din rollout. Un asistent de cunoștințe read-only pe sursele customizării dvs. este dimensionat separat și este de obicei primul pas.

Teamcenter Copilot vs. un asistent Teamcenter custom: de care avem nevoie?

Teamcenter Copilot de la Siemens răspunde din documentația Teamcenter și din înregistrările dvs. PLM și, începând cu 2606, recomandă șabloane de workflow pe baza utilizării anterioare. Un asistent custom răspunde din artefactele customizării dvs.: argumente de handlere, XML de stylesheet, surse ITK, note de upgrade. Dacă întrebările dvs. sunt despre datele de produs, folosiți Copilot-ul. Dacă sunt despre motivul pentru care instalarea dvs. se comportă așa cum se comportă, aveți nevoie de cel custom. Majoritatea organizațiilor cu un Teamcenter customizat ajung să le aibă pe ambele, delimitate astfel încât să nu se suprapună.

Va modifica asistentul modelul nostru de date BMIDE sau va implementa în producție?

Nu. Modificările modelului de date rămân în BMIDE, la administratorii dvs., iar fiecare modificare propusă, fie că este un argument de handler, o editare de stylesheet sau un patch de cod, trece prin serverul de test și printr-o revizuire în patru ochi înainte de implementare. Asistentul redactează și explică; pipeline-ul de implementare pe care îl rulați deja promovează.

Ce trebuie să pregătim înainte de un pilot?

Un export al șablonului BMIDE custom, exporturile șabloanelor de workflow, dataset-urile de stylesheet-uri care vă interesează, acces de citire la repository-urile SOA și ITK și un Teamcenter de test cu un cont de utilizator nominal pentru asistent. Din experiența noastră, exportul îi ia unui administrator două până la trei zile, cea mai mare parte pentru a decide care dintre cele 40 de șabloane mai sunt în uz, ceea ce este în sine o curățenie utilă.


Pasul următor

Dacă administratorii dvs. au întrebat deja dacă un AI poate învăța handlerele și stylesheet-urile dvs., cea mai rapidă cale de a afla este un asistent funcțional pe propriul dvs. export de șabloane, pe un server de test, în câteva săptămâni.

Discutați cu inginerii noștri Teamcenter despre un asistent pe customizarea dvs.



Referințe

  1. Siemens Digital Industries Software, “Introducing Teamcenter 2606,” Teamcenter Blog, 12 iunie 2026, https://blogs.sw.siemens.com/teamcenter/teamcenter-2606/ (accesat la 24 septembrie 2026).
  2. Global PLM, “Teamcenter Workflow Handlers” (rule handlers, action handlers, EPM_go/EPM_nogo, handler list), https://globalplm.com/teamcenter-workflow-handlers/ (accesat la 24 septembrie 2026).
  3. Siemens, Teamcenter Gateway Generic Configuration Guide, “Attach Additional Teamcenter Objects to a Workflow and Read their Attributes” (EPM-attach-related-objects arguments), https://docs.plm.automation.siemens.com/content/pl4x/19.1/T4EA/en_US/generic_configuration_guide/concept_of_triggering_transfer/process_based_trigger_workflow/attach_additional_teamcenter_objects_to_a_workflow_and_read_their_attributes.html (accesat la 24 septembrie 2026).
  4. PLM Handbook, “Teamcenter: Introduction to Stylesheets” (XMLRenderingStylesheet datasets, RENDERING and REGISTEREDTO preferences), https://plmhandbook.blogspot.com/2020/10/teamcenter-introduction-to-stylesheets.html (accesat la 24 septembrie 2026).
  5. Siemens Digital Industries Software Community, “Active Workspace 3.3” (XRT editor, deploy without a build), https://community.sw.siemens.com/s/article/active-workspace-3-3 (accesat la 24 septembrie 2026).
  6. Siemens, Teamcenter Services Reference (Java, strong-typed): Connection and DataManagement, https://support.industrysoftware.automation.siemens.com/docs/teamcenter/10.1/help/en_US/custom/services_reference/java/docs/strong/com/teamcenter/soa/client/Connection.html (accesat la 24 septembrie 2026).
  7. Siemens Digital Industries Software, “PLM reviews rank Teamcenter the #1 PLM software on G2,” Teamcenter Blog, 22 septembrie 2026, https://blogs.sw.siemens.com/teamcenter/plm-reviews-teamcenter-g2/ (accesat la 24 septembrie 2026).