Pexon Consulting | 9 Min. Lesezeit | 20.06.2026
TL;DR
Ein KI-Agent für NX Konstruktionsregeln prüft Design-Rules, DFM-Kriterien und DIN/ISO-Werknormen automatisch direkt im CAD-Modell. Pexon kombiniert die NX Open API und Check-Mate mit einem RAG-System über eure Normentexte. Ergebnis bei unseren Kunden: Konstruktionsfehler werden in der Modellphase gefunden, wo ein Fix rund 1 Euro statt 100 Euro nach Serienanlauf kostet.
Das Problem: Konstruktionsregeln leben in PDFs und Köpfen, nicht im Modell
Die teuersten Konstruktionsfehler sind nicht die offensichtlichen. Es sind die, die formal korrekt aussehen und trotzdem gegen eine interne Werknorm verstoßen: ein Radius unter dem Mindestmaß, eine Toleranz die der Lieferant nicht fertigen kann, eine Materialpaarung die eure Korrosionsrichtlinie verbietet.
Diese Regeln stehen in PDF-Werknormen, in DIN- und ISO-Dokumenten und vor allem in den Köpfen von drei, vier erfahrenen Konstrukteuren. Geht einer in Rente, geht das Wissen mit. Und solange die Prüfung manuell läuft, skaliert sie nicht: Jeder Review kostet Stunden, und unter Termindruck wird er übersprungen.
Die Zahlen dahinter sind brutal. Rund 70 Prozent der Nacharbeit in Engineering-Projekten ist design-induziert, nicht fertigungs-induziert. Und die Kosten eines Fehlers verzehnfachen sich mit jeder Phase: Was in der Konstruktion 1 Euro kostet, kostet in der Fertigung 10 Euro und beim Kunden 100 Euro. Das ist die 1-10-100-Regel, und sie ist der ganze Business Case für automatische Design-Checks.
Die ehrliche Einordnung vorweg: Wer glaubt, ein KI-Agent ersetze den Konstruktions-Review komplett, liegt falsch. Er ersetzt das stumpfe Abklappern von 200 Regeln pro Bauteil und gibt dem Senior-Konstrukteur die 5 Fälle zurück, die wirklich Urteilsvermögen brauchen.
So funktioniert der KI-Agent für NX Konstruktionsregeln
Der Agent kombiniert zwei Welten: die deterministische Geometrie-Prüfung über die NX Open API und die semantische Normprüfung über ein Sprachmodell. Deterministisch heißt: Eine Mindestwandstärke von 2,0 mm ist eine harte Zahl, die prüft kein LLM, die prüft Code. Semantisch heißt: „Vermeide scharfe Innenkanten bei lasttragenden Bauteilen“ ist eine Werknorm-Formulierung, die erst interpretiert werden muss.
NX bringt mit Check-Mate bereits eine Engine für regelbasierte Design Rule Checks mit, die auf Knowledge Fusion aufsetzt. Seit Juni 2021 lassen sich Check-Mate-Checks direkt über NX/Open schreiben, und mit dem Checker Editor aus dem Juni-2023-Release auch über ein Logik-Editor-Framework ohne tiefe Programmierung. Aktuell ist die Release-Linie NX 2506 (Juni 2025), das jüngste Update NX 2512 vom Dezember 2025 (Siemens NX Check-Mate Übersicht).
Der KI-Teil sitzt obendrauf. Statt jede Werknorm-Regel von Hand in Check-Mate zu übersetzen, indexieren wir eure Normentexte in einem RAG-System. Fragt der Agent „Welche Regeln gelten für ein gefrästes Aluminium-Gehäuse?“, holt er die relevanten Norm-Passagen, übersetzt sie in prüfbare Kriterien und mappt sie auf Geometrie-Abfragen der NX Open API. Das ist derselbe Ansatz, mit dem wir auch ISO-Normen und CAD-Modelle multimodal durchsuchbar machen — hier nur mit Schreib-Zugriff auf den Prüf-Workflow statt nur Lese-Zugriff.
Die Regel-Engine: deterministische Geometrie-Checks
Der harte Kern läuft über die NX Open API. Hier ein Auszug einer Regel, die alle Bohrungen eines Bauteils gegen eine Mindest-Wandstärke aus eurer Werknorm prüft. Kommentare auf Deutsch, der Code ist lauffähig gegen ein offenes NX-Part:
# nx_wandstaerke_check.py — prüft Mindest-Wandstärke an Bohrungen
# Läuft im NX Open Python-Kontext (NX 2506+). Aufruf: über "File > Execute > NX Open"
import NXOpen
import NXOpen.Features
# Werknorm-Schwellwert (käme im Live-Betrieb aus dem Regel-Repository, siehe unten)
MIN_WANDSTAERKE_MM = 2.0
def pruefe_wandstaerke():
session = NXOpen.Session.GetSession()
work_part = session.Parts.Work
lw = session.ListingWindow
lw.Open()
verstoesse = []
# Alle Bohrungs-Features im aktiven Part durchgehen
for feature in work_part.Features:
if not isinstance(feature, NXOpen.Features.HolePackage):
continue
# Geometrie-Maße aus dem Feature lesen
for expr in feature.GetExpressions():
# Konvention: Wandstärke-Maße tragen den Präfix "ws_"
if expr.Name.startswith("ws_") and expr.Value < MIN_WANDSTAERKE_MM:
verstoesse.append(
f"{feature.JournalIdentifier}: {expr.Name} = "
f"{expr.Value:.2f} mm < {MIN_WANDSTAERKE_MM} mm"
)
if verstoesse:
lw.WriteLine(f"REGEL-VERSTOSS Wandstärke ({len(verstoesse)} Fund):")
for v in verstoesse:
lw.WriteLine(f" - {v}")
else:
lw.WriteLine("OK: Alle geprüften Wandstärken konform.")
return verstoesse
if __name__ == "__main__":
pruefe_wandstaerke()Das ist der Teil, der niemals halluziniert. Eine Zahl ist eine Zahl. Genau deshalb gehört Geometrie in Code und nicht in ein Sprachmodell.
Die Norm-Ebene: LLM-gestützte Prüfung gegen Werknormen
Die zweite Ebene übersetzt Norm-Prosa in prüfbare Regeln. Hier zeigt sich, warum reines Check-Mate nicht reicht: Werknormen sind in natürlicher Sprache geschrieben, oft mehrdeutig, und ändern sich. Der Agent liest die Norm, schlägt eine maschinenlesbare Regel vor, und ein Konstrukteur bestätigt sie einmalig. Danach läuft sie deterministisch.
# norm_zu_regel.py — übersetzt eine Werknorm-Passage in eine prüfbare JSON-Regel
# Nutzt ein LLM nur für die ÜBERSETZUNG, nicht für die laufende Prüfung.
import json
from anthropic import Anthropic
client = Anthropic() # ANTHROPIC_API_KEY aus der Umgebung
def norm_zu_regel(norm_passage: str) -> dict:
"""Wandelt eine Werknorm-Formulierung in eine strukturierte Regel um."""
prompt = f"""Du bist Konstruktions-Reviewer. Wandle die folgende Werknorm-Passage
in eine maschinenlesbare Prüfregel um. Antworte NUR mit JSON in diesem Schema:
{{"merkmal": "...", "operator": "min|max|verboten|erlaubt", "wert": <zahl|string>,
"einheit": "...", "geltungsbereich": "...", "konfidenz": "hoch|mittel|niedrig"}}
Werknorm-Passage:
"""{norm_passage}""""""
resp = client.messages.create(
model="claude-sonnet-4-6", # namentliche Modell-ID, Stand Juni 2026
max_tokens=512,
messages=[{"role": "user", "content": prompt}],
)
regel = json.loads(resp.content[0].text)
# Sicherheits-Gate: niedrige Konfidenz geht IMMER an einen Menschen
if regel.get("konfidenz") == "niedrig":
regel["review_pflicht"] = True
return regel
if __name__ == "__main__":
passage = ("Bei gefrästen Aluminium-Gehäusen muss die minimale Wandstärke "
"mindestens das 0,8-fache des Fräser-Durchmessers betragen, "
"in keinem Fall jedoch unter 1,5 mm.")
print(json.dumps(norm_zu_regel(passage), ensure_ascii=False, indent=2))Das Sprachmodell macht hier genau eine Sache: die einmalige Übersetzung. Die wiederkehrende Prüfung übernimmt danach die deterministische Regel-Engine. Diese Trennung ist der Grund, warum das Ergebnis auditierbar bleibt — ein Punkt, den jeder QS-Leiter sofort versteht und der bei reinen „KI prüft die Zeichnung“-Versprechen fehlt.
Was das in der Praxis bedeutet: DFM-Check beim Speichern
Der spürbarste Effekt ist nicht der große Audit-Report, sondern der kleine Hinweis im richtigen Moment. Der Konstrukteur speichert ein Bauteil, der Agent läuft im Hintergrund über Check-Mate, und innerhalb von Sekunden steht im HD3D-Fenster: „Innenradius 0,3 mm an Tasche T4 — eure Werknorm fordert mindestens 0,5 mm für Fräsbearbeitung.“
Das ist Design for Manufacturing (DFM), wie es sein soll: präventiv, nicht reaktiv. Bei einem unserer Fertigungskunden lag die Trefferquote nach sechs Wochen Pilot bei einem Regelsatz von rund 120 Werknorm-Regeln. Die Fälle, die der Agent fand, waren überwiegend die unspektakulären — genau die, die sonst erst beim Lieferanten oder in der Montage aufgefallen wären.
Ein ehrlicher Hinweis zur Erwartung: Die ersten zwei Wochen produziert so ein Agent zu viele Treffer, auch False Positives. Das ist normal. Der Wert entsteht im Tuning, wenn ihr die Regeln gegen reale Bauteile kalibriert. Wer das überspringt, bekommt einen Agenten, den die Konstrukteure nach drei Tagen wegklicken.
Architektur: NX Open, Check-Mate und das Regel-Repository
Der Aufbau hat drei Schichten, und jede hat einen klaren Job. Die NX-Schicht (Open API plus Check-Mate) führt die Prüfungen im Modell aus. Die Regel-Schicht hält alle Werknorm-Regeln versioniert in einem Repository — eine Regel-Änderung ist ein Git-Commit, kein Tribal-Knowledge. Die Norm-Schicht indexiert eure DIN-, ISO- und Werknorm-Dokumente und hält sie als RAG-Quelle für neue Regeln bereit.
Warum das Repository der eigentliche Hebel ist: Es macht aus Konstruktionswissen ein Asset, das den einzelnen Mitarbeiter überlebt. Wenn ein Senior in Rente geht, bleibt seine Regel im System. Das ist derselbe Grundgedanke, mit dem wir Projektdokumente in der Fertigung mit KI strukturieren — implizites Wissen wird explizit und durchsuchbar.
Datensouveränität ist bei Konstruktionsdaten kein Nice-to-have. Eure Bauteilgeometrie ist euer Kronjuwel. Deshalb läuft die Norm-Schicht bei uns standardmäßig in eurer Azure-Umgebung oder on-prem, nicht in einer fremden Cloud. Die Geometrie-Prüfung verlässt das NX-Umfeld ohnehin nie.
Worauf Sie bei der Auswahl achten sollten
Nicht jeder „KI-CAD-Check“ hält, was er verspricht. Aus unseren Projekten die fünf Punkte, an denen sich Spreu und Weizen trennen:
- Trennt das Tool Geometrie von Semantik? Wenn ein LLM Maße prüft statt Code, ist das Ergebnis nicht auditierbar. Finger weg.
- Sind die Regeln versioniert? Ein Regelsatz ohne Historie ist ein Black Box, die euer QS-Audit nicht besteht.
- Läuft die Prüfung in NX oder daneben? Ein separates Tool, das niemand öffnet, findet keine Fehler. Der Check muss in den Speicher-Workflow.
- Bleiben die Daten bei euch? Bei Konstruktionsgeometrie ist On-Prem oder eigene Cloud die Untergrenze, nicht der Luxus.
- Gibt es eine Tuning-Phase? Wer ohne Kalibrierung gegen reale Bauteile startet, verbrennt die Akzeptanz der Konstrukteure.
Unsere klare Empfehlung: Startet mit 20 bis 30 hochfrequenten Regeln an einer Bauteilfamilie, nicht mit dem Versuch, die komplette Werknorm auf einmal zu digitalisieren. Der vollständige Regelsatz ist ein Marathon, der Pilot ein Sprint.
Häufig gestellte Fragen
Was kostet ein KI-Agent für NX Konstruktionsregeln?
Ein Pilot mit 20 bis 30 Regeln an einer Bauteilfamilie liegt bei uns im Rahmen eines 6-Wochen-Projekts, typischerweise im niedrigen fünfstelligen Bereich. Der vollständige Roll-out über mehrere Werknormen skaliert mit der Zahl der Regeln, nicht linear mit dem Aufwand — die Architektur baut ihr nur einmal.
Brauche ich Check-Mate oder reicht die NX Open API allein?
Beides hat seinen Platz. Check-Mate liefert die fertige Engine inklusive HD3D-Anzeige und Standard-Checks für Geometrie, PMI und Zeichnungen. Die NX Open API brauchst du für eigene, komplexere Prüflogik. In der Praxis kombinieren wir beides: Check-Mate für den Standard, NX/Open für eure Sonderregeln.
Kann der Agent gegen DIN- und ISO-Normen prüfen, nicht nur gegen Werknormen?
Ja, sofern die Norm eine prüfbare Aussage enthält. DIN ISO 1302 zu Oberflächenangaben oder Maßtoleranzen nach ISO GPS lassen sich in Regeln übersetzen. Reine Gestaltungs-Empfehlungen ohne harte Schwellwerte kann der Agent als Hinweis ausgeben, aber nicht als Pass/Fail entscheiden.
Halluziniert die KI bei der Normprüfung?
Bei der laufenden Geometrie-Prüfung nicht, weil die deterministisch in Code läuft. Das Sprachmodell wird nur einmalig für die Übersetzung einer Norm-Passage in eine Regel eingesetzt, und jede Regel mit niedriger Konfidenz geht zwingend an einen menschlichen Reviewer. Diese Trennung ist der Kern der Auditierbarkeit.
Wie lange dauert die Einführung bis zum produktiven Einsatz?
Der erste lauffähige Check steht innerhalb der ersten Woche. Bis ein Regelsatz von 100+ Regeln sauber kalibriert und von den Konstrukteuren akzeptiert ist, rechnen wir realistisch mit drei bis vier Monaten parallel zum laufenden Betrieb. Der 6-Wochen-Pilot zeigt vorher, ob der Hebel für eure Bauteile stimmt.
Nächster Schritt
Bringt eine reale Baugruppe mit, an der ihr regelmäßig Normabweichungen seht. In einem Use-Case-Workshop bewerten wir gemeinsam, welche eurer Konstruktionsregeln sich für die Automatisierung mit NX Open API und Check-Mate eignen — und welche besser beim Menschen bleiben.
Verwandte Themen
→KI entlang der Wertschöpfungskette im Maschinenbau
→Warum Standard-RAG bei DIN-Normen an Grenzen stößt
