KI-generierte PMI in NX: Die Kurzfassung
KI-generierte PMI bedeutet: Ein LLM schlägt Maße und Toleranzen aus einer schriftlichen Richtlinie vor, und NXOpen setzt sie am Modell. inteliScience hat das an einem Demo-Teil durchgespielt, mit eigenem Chatbot, eigener NXOpen-Bridge und unserer internen PMI-Richtlinie: Maß-PMI kamen brauchbar heraus, GD&T war nicht im Scope, und ein Mensch hat weiterhin jede Annotation freigegeben.
Das Problem: PMI-Erstellung ist langsam, weil die Regeln in Köpfen stecken
Ein Maß in Siemens NX (Designcenter) zu platzieren, sind ein paar Klicks. Zu entscheiden, welches Feature ein Maß bekommt, welche Toleranzklasse gilt, in welche Modellansicht es gehört und welche Notiz dazukommt, ist der langsame Teil. Diese Entscheidung steckt in einer Richtlinie, die das halbe Team nur überflogen hat, und im Kopf des Methodikers, der sie geschrieben hat.
Siemens beschreibt PMI in Designcenter als die Annotationen und Metadaten, die festlegen, wie ein Teil gefertigt wird: Maße, Toleranzen, Toleranzrahmen, Bezüge, Oberflächenangaben, Notizen, organisiert in Modellansichten. Die offizielle Designcenter-Seite zur Model-Based Definition behandelt auch Convert to PMI für alte Zeichnungsansichten.
Ob das Modell oder die Zeichnung der Master sein soll, ist eine Entscheidung, die wir bereits dokumentiert haben, siehe MBD oder Zeichnung als Master. Dieser Artikel setzt voraus, dass das Modell gewinnt, und stellt die nächste Frage: Wer schreibt die PMI, und nach welchen Regeln.
Könnte ein LLM unsere Richtlinie lesen und den ersten Durchgang übernehmen? Wir haben es ausprobiert.
Was wir gebaut haben: ein Chatbot, eine NXOpen-Bridge und dazwischen eine Richtlinie
Drei Bausteine, alle von uns: ein LLM-basierter Assistent (dahinter ein aktuelles gehostetes LLM, das Modell ist austauschbar), eine NXOpen-Bridge, die gegen eine laufende NX-Sitzung arbeitet, und unsere interne PMI/MBD-Richtlinie als einziger Fachinput. Kein Siemens-Produkt, kein Marketplace-Plugin. Die Richtlinie (Bemaßungsregeln je Feature-Typ, Toleranzklassen je Größenbereich, Ansichts- und Notizkonventionen) ging unverändert hinein, was sich als der lehrreichste Fehler des Experiments herausstellte.
Der Ablauf: Der Assistent liest die Richtlinie und schlägt über die Bridge PMI für das Demo-Teil vor (dieselbe Art von LLM-zu-NX-Verbindung, die wir für MCP beschrieben haben). Die Bridge prüft jeden Vorschlag gegen das Modell und die Richtlinie, erzeugt nur, was besteht, und übergibt das Ergebnis an einen Menschen in NX.
Hausregel, und wir weichen nicht davon ab: Die KI schlägt vor, NXOpen führt aus, Regeln und ein Mensch validieren. Das LLM ruft NX nie direkt auf und darf nie „Pass“ sagen.
Und weil die Frage immer kommt: Designcenter Copilot tut das nicht. Siemens’ Copilot-Tipps-Seite (12. Mai 2026) beschreibt Hilfestellung auf Basis der Dokumentation, bei der hervorgehobene Wörter in einer Antwort als direkte Links zu Befehlen dienen. NX plus Copilot für „Wie mache ich“, NX plus eine Bridge wie unsere für „Erstelle meine PMI nach unseren Regeln“.
Was der Assistent richtig gemacht hat und was einen menschlichen Durchgang brauchte
Es funktionierte für die einfachen Fälle: Durchgangsbohrungen, Plattendicke, Außenmaße, überall dort, wo die Richtlinie eine Regel je Feature-Typ und eine Toleranzzeile je Größenbereich hat. Einen menschlichen Durchgang brauchte es überall dort, wo die Richtlinie Interpretation verlangt, und dort, wo sie schweigt.
Was gut lief: Der Assistent hat die Struktur der Richtlinie korrekt gelesen, sodass Feature-Typ plus Größenbereich häufiger zur richtigen Toleranzzeile führte, als wir es von einem für Menschen geschriebenen Dokument erwartet hatten. Maße landeten auf den Features, die er benannt hatte, mit den Messwerten der Bridge als Nennwerte, in der vorgeschriebenen Ansicht. Und ein Richtlinienzitat in jedem Vorschlag hat den Review verändert: Statt “Stimmt das?” fragt der Prüfer “Steht das wirklich in Absatz 4.2?”.
Was einen menschlichen Durchgang brauchte, die Art von Dingen, die man jedes Mal prüft:
- Falsche Feature-Referenz, wo zwei Features gleich aussehen, aber unterschiedliche Funktionen haben (eine Passbohrung neben einem gleich großen Durchgangsloch).
- Toleranzklasse aus der benachbarten Tabellenzeile, wo ein Maß auf der Grenze zwischen zwei Bereichen liegt.
- Doppelte PMI an symmetrischen Features, wo die Richtlinie ein Maß mit Wiederholungsvermerk erwartet.
- PMI auf einer Ebene, die zulässig ist, aber nicht die, die ein Zerspaner lesen würde.
- Selbstbewusstes Lückenfüllen: Wo die Richtlinie nichts sagte, schlug der Assistent etwas Plausibles vor. Plausibel ist das gefährliche Wort in diesem ganzen Thema.
Die Prüfzeit ging nicht auf null, und das wollen wir auch nicht. Der Prüfer wurde vom Autor zum Auditor, mit einem Verweis, den er in jeder Zeile prüfen kann.
Warum das Richtliniendokument wichtiger ist als das Modell
Tauschen Sie das LLM aus, und das Ergebnis verschiebt sich ein wenig. Tauschen Sie die Richtlinie aus, und das Ergebnis ändert sich komplett. Das ist der zentrale Befund.
PMI-Richtlinien von Unternehmen sind zwei Normen nachgelagert. ASME Y14.41, Digital Product Definition Data Practices, legt die Anforderungen an die Erstellung und Überarbeitung digitaler Produktdefinitions-Datensätze fest. ISO 16792:2021 ist das ISO-Gegenstück und deckt sowohl reine 3D-Modell- als auch Modell-plus-Zeichnung-Datensätze ab. Keine der beiden Normen haben wir dem Assistenten gegeben. Unsere Richtlinie ist die Unternehmensschicht darüber: hauseigene Toleranztabellen, Ansichtskonventionen, Ausnahmen.
Diese Richtlinie wurde für Leser geschrieben, die Lücken mit Erfahrung füllen. Ein LLM füllt Lücken mit Plausibilität. Die meisten Fehlerbilder oben sind also Richtlinienfehler im KI-Kostüm: „siehe typische Werte“ statt einer Tabelle, ein „gilt wenn“, das im Kopf des Autors lebt, zwei Regeln, die sich stillschweigend widersprechen.
Was eine LLM-taugliche Richtlinie braucht, nach dem, was wir korrigieren mussten: jede Toleranzregel als explizite Tabellenzeile; eine „gilt wenn“-Bedingung je Regel, gebunden an einen Feature-Typ, den die Bridge erkennen kann; Konflikte auf dem Papier aufgelöst; ein Glossar, das Richtlinienbegriffe auf NX-Feature-Typen und -Ansichten abbildet; und eine Versionsnummer, damit jeder Vorschlag nachvollziehbar ist.
Unsere klare Empfehlung: Bevor Sie irgendetwas in die Modellauswahl investieren, investieren Sie die Zeit in die Richtlinie. Sie überlebt jeden Modellwechsel und zahlt sich selbst dann aus, wenn die KI nie kommt.
Das funktioniert an einem Demo-Teil. Was für die Produktion fehlt: Richtlinien-Versionierung, Validierungsregeln, die blockieren statt warnen, Teamcenter-Freigabe, ein Audit-Trail je Annotation, GD&T und Bezugssysteme sowie ein menschlicher Freigabeschritt, der nicht übersprungen werden kann. Diese Lücke schließen wir als Projekt mit festem Umfang: MBD-PMI-Authoring-Assistent für Siemens NX.
KI-generierte PMI vs. regelbasiertes NXOpen vs. manuelle Erstellung
Drei Wege, PMI auf ein Modell zu bekommen, und sie sind keine Rivalen. Regelbasiertes NXOpen ist richtig, wenn die Regeln vollständig und stabil sind. LLM-gestützte Erstellung ist richtig, wenn die Regeln Prosa mit Lücken sind. Manuell bleibt alles, was heute Freigaberisiko trägt.
| Kriterium | Manuelle PMI-Erstellung | Regelbasierte NXOpen-Automatisierung | LLM-gestützt (KI-generierte PMI) |
|---|---|---|---|
| Regelquelle | Kopf des Konstrukteurs plus Richtlinie | Regeln codiert und geprüft | Richtlinie im Kontext, Bridge erzwingt |
| Umgang mit Mehrdeutigkeit | Ja, durch Erfahrung | Nein, undefinierter Fall schlägt fehl oder wird übersprungen | Ja, durch Raten, daher die menschliche Prüfung |
| Wiederholbarkeit | Gering zwischen Konstrukteuren | Vollständig | Hoch für abgedeckte Fälle, nicht garantiert |
| Erklärbarkeit | „Weil ich es weiß“ | Regel-ID im Log | Richtlinienverweis je Annotation |
| Wer validiert | Peer-Review, falls überhaupt | Regeln, dann Freigabeprüfung | Erst Regeln, dann ein Mensch, immer |
| GD&T und Bezüge heute | Ja | Ja, wo Regeln existieren | Nicht in unserem Lauf |
| Am besten für | Neue Teile, geringe Stückzahl | Stabile Familien, hohe Stückzahl | Prosa-Richtlinien, gemischte Teile, erster Durchgang |
Die regelbasierte Spalte ist keine Theorie. Die Case Study zur PMI-Automatisierung im Automotive-Bereich ist genau das: codierte Regeln, die PMI in NXOpen erzeugen, ohne LLM in der Schleife. Wenn Ihre Regeln bereits in Code passen, raten wir davon ab, ein LLM hinzuzufügen; es bringt eine Validierungslast, die Sie nicht brauchen. Das LLM verdient seinen Platz dort, wo die Richtlinie überwiegend Regeln ist, teils Ermessen, nie ganz fertig.
Was noch fehlt: GD&T, Bezüge, Freigabe
Keine Toleranzrahmen, keine Bezugssysteme, keine Teamcenter-Freigabe in diesem Lauf. Das ist der nächste Schritt, und ein schwererer: Ein Bezugsschema ist eine Entscheidung darüber, wie das Teil funktioniert und wie es gespannt wird, kein Tabellen-Lookup.
GD&T kommt nach den Bezügen, die Reihenfolge ist also fix. Wir wollen, dass der Assistent ein Bezugsschema mit funktionaler Begründung vorschlägt und ein Mensch es annimmt oder umschreibt, bevor ein einziger Toleranzrahmen erzeugt wird.
Die Freigabe ist die andere Lücke. Eine Produktionsversion braucht einen Audit-Trail je Annotation: welcher Assistent und welche Richtlinienversion sie vorgeschlagen haben, welche Regeln sie bestanden hat, wer sie genehmigt hat, wann sie in den Teamcenter-Freigabestatus gelangt ist. Die KI entscheidet an einem freigegebenen Modell nie über Pass oder Fail.
Siemens’ Designcenter-Release vom Juni 2026 (das Release, das NX in Designcenter umbenannt hat) listet gleichzeitige Mehrbenutzer-PMI-Operationen in Live Share auf, und das Early Access Program für Designcenter 2612 läuft im September 2026. Eine Bridge, die ihre Richtlinienversion und ihre NX-Version festpinnt, übersteht diesen Takt. Eine Demo nicht.
So probieren Sie das im eigenen Team aus
Den nützlichen Teil dieses Experiments können Sie ohne unsere Bridge nachstellen; die ersten vier Schritte brauchen gar keine KI.
- Wählen Sie ein Demo-Teil mit Bohrungen, Flächen und einem symmetrischen Feature. Nie Kundengeometrie für den ersten Lauf.
- Auditieren Sie die Richtlinie: Tabellen, „gilt wenn“, aufgelöste Konflikte, Glossar, Versionsnummer.
- Schreiben Sie den Bridge-Vertrag vor dem ersten Code: was ein Vorschlag enthält, was abgelehnt wird, was geloggt wird.
- Definieren Sie die menschliche Prüfstufe. Wer prüft, was geprüft wird und was „freigegeben“ in Ihrem PLM bedeutet.
- Beginnen Sie nur mit Maß-PMI. GD&T und Bezüge sind Runde zwei.
- Sortieren Sie jede Korrektur in „Richtlinienproblem“ oder „Modellproblem“. Rechnen Sie damit, dass der erste Stapel größer ist.
- Entscheiden Sie den Weg. Überwiegend Regellücken: Richtlinie reparieren, regelbasiertes NXOpen erwägen. Überwiegend Ermessensentscheidungen: Das LLM bleibt, und der Prüfer auch.
Schritt 2 allein verbessert bereits die manuelle PMI-Erstellung.
Häufig gestellte Fragen
Was ist KI-generierte PMI in Siemens NX?
KI-generierte PMI sind Produkt- und Fertigungsinformationen (Maße und Toleranzen, später GD&T), die ein LLM aus einer schriftlichen Richtlinie vorschlägt und ein NXOpen-Programm am Modell erzeugt. Das LLM greift nie direkt auf NX zu: Es liefert strukturierte Vorschläge, die Bridge validiert sie, und ein Mensch gibt das Ergebnis frei.
Kann Designcenter Copilot PMI aus meiner Richtlinie erstellen?
Nicht so, wie Siemens es beschreibt. Designcenter Copilot beantwortet Fragen auf Basis der Siemens-Dokumentation und verlinkt Sie zu den passenden Befehlen. PMI aus den eigenen Hausregeln zu erstellen ist eine andere Aufgabe, daher unser eigener Assistent und unsere NXOpen-Bridge.
KI-generierte PMI vs. regelbasierte NXOpen-PMI-Automatisierung: Womit sollten wir anfangen?
Regelbasiert, wenn sich Ihre Richtlinie bereits wie Code liest: vollständige Tabellen, keine Ermessensentscheidungen. LLM-gestützt, wenn sie Prosa mit Lücken ist und Sie einen ersten Durchgang wollen, den ein Prüfer auditieren kann. In beiden Fällen kommt zuerst die Bereinigung der Richtlinie, und die Freigabe bleibt beim Menschen.
Was kostet ein Pilotprojekt für KI-gestützte PMI-Erstellung?
Das hängt mehr vom Zustand Ihrer Richtlinie ab als von der KI. Explizite Tabellen halten den Bridge-Vertrag kurz; eine Prosa-Richtlinie bedeutet, dass der Pilot mit Methodikarbeit beginnt. Wir definieren ihn als Projekt mit festem Umfang, nachdem wir Ihre Richtlinie gelesen haben, nicht aus einer Preisliste.
Entscheidet die KI, ob die PMI korrekt sind?
Nein, und das sollte sie auch nicht. Die Bridge weist alles zurück, was nicht zum Modell oder zu den Richtlinientabellen passt, und ein Mensch gibt jede Annotation vor der Freigabe frei. Die KI schlägt vor, NXOpen führt aus, Regeln und ein Mensch validieren.
Nächster Schritt
Möchten Sie Ihre eigene PMI-Richtlinie an einem Demo-Teil laufen sehen? Buchen Sie ein kostenloses Strategiegespräch und bringen Sie die Richtlinie mit. Sprechen Sie mit unseren Ingenieuren über KI-generierte PMI in NX
