Pexon Consulting | 9 Min. Lesezeit | 02.06.2026
TL;DR
Der VLM DRW Validator löst den Review-Bottleneck im Maschinenbau: Vision-Language-Modelle lesen Konstruktionszeichnungen und prüfen automatisch gegen ASD (Konstruktions-Richtlinien) und ASE (Erzeugnis-Standards). Maße, Toleranzen, Schraffuren, Stücklisten-Konsistenz werden markiert, der Konstruktions-Senior reviewt nur die Auffälligkeiten. Aus 4-Augen-Workshops werden 30-Minuten-Reviews — bei höherer Trefferquote als manuell.
Warum 4-Augen-Reviews im Maschinenbau immer der Engpass werden
Jede freigegebene Konstruktionszeichnung in einem qualitäts-bewussten Maschinenbau-Unternehmen durchläuft mindestens einen 4-Augen-Review. Konstrukteur erstellt, Senior-Konstrukteur prüft. In QM-zertifizierten Häusern kommt oft noch ein dritter Review durch den Norm-Verantwortlichen dazu. Das ist gut für die Qualität — und schlecht für den Durchsatz.
Aus drei Pexon-Discovery-Workshops mit Maschinenbauern 2025/2026: Die durchschnittliche DRW-Liegezeit im Review-Pool beträgt 3-8 Werktage. Bei kleineren Serien-Konstruktionen ist das tolerierbar, bei Projekt-Engineering (Sondermaschinenbau, Anlagenbau) wird es zum Engpass für den gesamten Auftragsdurchlauf. In einem Sondermaschinenbau-Projekt haben wir gemessen: 17 % der gesamten Engineering-Zeit gingen für Review-Iteration und Korrektur-Schleifen drauf — nicht für die eigentliche Konstruktion.
Der zweite Pain: Die Review-Trefferquote ist niedriger, als man denkt. Eine interne Stichprobe bei einem unserer Kunden zeigte, dass von 80 stichprobenartig nach-geprüften freigegebenen DRWs 22 Stück mindestens einen Norm-Verstoß enthielten, der im 4-Augen-Review nicht erkannt wurde — meist falsche Norm-Verweise oder veraltete Bemaßungs-Konventionen. Der Mensch sieht, was er kennt, und übersieht, was er vor zwei Jahren das letzte Mal in der Norm gelesen hat.
Was VLMs in einer CAD-Zeichnung wirklich erkennen
Vision-Language-Modelle (VLM) wie GPT-4o Vision, Claude Sonnet 4 mit Vision oder Gemini 2.0 Flash haben in den letzten 18 Monaten einen Sprung gemacht, der für CAD-Zeichnungs-Review interessant wird. Konkret:
- Bemaßungs-Ketten erkennen sie strukturell — können prüfen, ob alle Maße eindeutig sind und keine Mehrfach-Bemaßung vorliegt
- Toleranz-Einträge (ISO 2768, ISO 8015, GD&T-Symbolik) lesen sie zu 85-95 % korrekt
- Schraffuren als Werkstoff-Indikator und Schnitt-Markierungen werden zuverlässig klassifiziert
- Schriftfeld-Inhalte (Zeichnungs-Nummer, Maßstab, Erstell-Datum, Freigabe-Stempel) sind Pflicht-Routine
- Stücklisten-Tabellen mit Positions-Nummern, Material-Nummern und Mengen werden zeilenweise extrahiert
Was VLMs in der aktuellen Generation noch nicht zuverlässig können: 3D-Geometrie-Verständnis aus 2D-Ansichten ableiten, komplexe GPS-Toleranzkonstellationen in der Konformität bewerten, handschriftliche Korrektur-Vermerke entziffern. Für 80-90 % der Routine-Prüfungen reicht das vorhandene VLM-Können. Die restlichen 10-20 % bleiben Mensch-Domäne — und genau das ist der Konstruktions-Senior, der weniger Zeit auf Routine-Checks verwendet und mehr auf die schwierigen Fälle.
Die Architektur — VLM DRW Validator in drei Komponenten
+-----------+ +-------------------+ +-----------------+
| PLM-Hook | | VLM DRW Validator | | Azure OpenAI |
| (DRW- |--->| - PDF → PNG |--->| GPT-4o Vision |
| Release- | | - Multi-View | | (EU-Region) |
| Event) | | Segmentation | +-----------------+
+-----------+ | - VLM-Prüf-Engine | OR
| - Rule-Mapping | +-----------------+
+-------------------+--->| AWS Bedrock |
| | Claude Sonnet 4 |
v | (EU-Frankfurt) |
+---------------+ +-----------------+
| Review-Report |
| mit Markierg. |
| (PDF + JSON) |
+---------------+Komponente 1 — PDF-Vorbereitung. Konstruktionszeichnungen kommen aus dem PLM meist als PDF mit eingebetteten Vektoren. Für VLMs muss das in hochauflösende PNG-Tiles segmentiert werden, weil ein A0-PDF in einem einzigen Bild zu viel Detail-Verlust hat. Wir nutzen eine Multi-View-Segmentierung, die Hauptansicht, Detailansichten und Schriftfeld separat schickt.
Komponente 2 — VLM-Prüf-Engine. Pro Tile ein VLM-Call mit spezifischem System-Prompt für die Prüfaufgabe. Das ist der teure Teil — bei einem typischen DRW mit 6-12 Tiles entstehen 10.000-25.000 Input-Tokens und 2.000-5.000 Output-Tokens. Bei Claude Sonnet 4 (3 USD/Mio Input, 15 USD/Mio Output) sind das pro DRW etwa 0,06-0,15 EUR.
Komponente 3 — Rule-Mapping gegen ASD/ASE. Die VLM-Antworten werden gegen die internen ASD-Konstruktions-Richtlinien und ASE-Erzeugnis-Standards gemappt. Ein Verstoß wird mit Stelle (Tile + Bounding-Box) und betroffener Regel markiert. Output ist ein annotiertes PDF plus strukturiertes JSON für die PLM-Integration.
Welche Prüfungen automatisch laufen — fünf Familien
In der aktuellen Pexon-Implementation prüft der VLM DRW Validator fünf Familien von Anforderungen:
Familie 1 — Bemaßungs-Konsistenz. Sind alle Maße eindeutig? Gibt es Mehrfach-Bemaßung? Sind tolerierte Maße korrekt mit Toleranzwerten versehen? Stimmen Maßangaben in Hauptansicht und Detailansichten überein?
Familie 2 — Toleranz-Korrektheit. Sind ISO-2768- oder ISO-8015-Verweise im Schriftfeld vorhanden? Sind Form- und Lage-Toleranzen (GD&T) syntaktisch korrekt? Passen die Toleranz-Klassen zur Bauteil-Funktion (das prüft die Engine nur grob, fachlich bleibt beim Konstrukteur)?
Familie 3 — Schraffur- und Werkstoff-Konsistenz. Ist die Schraffur in Schnitten DIN-konform (ISO 128-50)? Passt die Werkstoff-Schraffur zum Werkstoff-Eintrag im Schriftfeld? Sind Schraffur-Linienabstände gleichmäßig?
Familie 4 — Stücklisten-Position-Check. Sind alle Positions-Nummern in der Zeichnung mit einem Eintrag in der Stückliste verknüpft? Gibt es Positions-Nummern in der Stückliste ohne Eintrag in der Zeichnung? Stimmen Mengen überein?
Familie 5 — Norm-Verweis-Aktualität. Sind alle im Schriftfeld zitierten Normen aktuell gültig? Verweist die Zeichnung auf zurückgezogene oder ersetzte Normen? Diese Familie verbindet sich direkt mit dem Norm-Konformitäts-Agent und nutzt dessen aktuelle Norm-Datenbank.
Jede Familie liefert separate Issues mit Severity-Level. Der Review-Report bündelt sie nach Severity, damit der Senior-Konstrukteur in der Eskalations-Reihenfolge prüft.
Code-Beispiel — Prüf-Pipeline mit GPT-4o Vision oder Claude Sonnet 4
Vereinfachte Implementation der Prüf-Engine. Mandantenfähigkeit, Caching und Async-Handling sind weggelassen.
from openai import AzureOpenAI
from pydantic import BaseModel
import base64
class DRWFinding(BaseModel):
severity: str # "critical" | "major" | "minor"
family: str # "bemassung" | "toleranz" | "schraffur" | "stueckliste" | "norm"
bbox: tuple # (x1, y1, x2, y2) im Tile
rule_id: str # ASD- oder ASE-Regel-ID
description: str
suggested_fix: str
client = AzureOpenAI(
azure_endpoint="https://pexon-eu.openai.azure.com",
api_version="2025-01-01-preview",
api_key="...",
)
def validate_drw_tile(tile_png: bytes, asd_rules: list[dict], ase_rules: list[dict]) -> list[DRWFinding]:
"""Prüft einen DRW-Tile gegen ASD- und ASE-Regeln."""
b64 = base64.b64encode(tile_png).decode()
system = f"""Du prüfst eine Konstruktionszeichnung gegen interne Standards.
ASD-Regeln (Konstruktions-Richtlinien): {asd_rules}
ASE-Regeln (Erzeugnis-Standards): {ase_rules}
Markiere Verstöße mit Severity, Bounding-Box, Regel-ID, Beschreibung und Korrektur-Vorschlag."""
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": system},
{"role": "user", "content": [
{"type": "text", "text": "Prüfe diese Konstruktionszeichnung."},
{"type": "image_url", "image_url": {"url": f"data:image/png;base64,{b64}"}},
]},
],
response_format={"type": "json_object"},
max_tokens=4000,
)
return parse_findings(response.choices[0].message.content)Drei wichtige Detail-Entscheidungen:
response_format=json_objectfür strukturierte Outputs. Ohne das halluziniert das Modell Bounding-Boxes als Fließtext.- ASD- und ASE-Regeln im System-Prompt statt in jedem User-Prompt. Spart pro Tile-Call ca. 1.500-3.000 Input-Tokens, weil Prompt-Caching greift.
- Pro Tile ein separater Call statt einem Mega-Call mit dem ganzen DRW. Höhere Genauigkeit, bessere Bounding-Box-Präzision, leichter zu debuggen.
Was VLMs heute noch NICHT zuverlässig erkennen
Fair-Play: Es gibt drei Klassen von Prüfungen, in denen der VLM DRW Validator aktuell nicht zuverlässig genug ist und der Mensch unverzichtbar bleibt.
1. Komplexe GPS-Toleranz-Konstellationen. Wenn mehrere Form- und Lage-Toleranzen aufeinander aufbauen und Material-Bedingungen (M, L) ins Spiel kommen, übersieht der VLM regelmäßig die wechselseitigen Abhängigkeiten. Das ist Senior-Konstrukteur-Domäne — und wird es noch 2-3 Modell-Generationen bleiben.
2. 3D-Geometrie-Plausibilität. Wenn ein DRW geometrisch unmöglich ist (z.B. zwei Maße, die sich im Raum widersprechen, aber in beiden 2D-Ansichten einzeln korrekt aussehen), erkennt der VLM das nicht. Das ist ein CAD-System-Job, nicht ein VLM-Job.
3. Handschriftliche Korrektur-Vermerke. In gewachsenen Konstruktionen finden sich oft handschriftliche Annotationen aus alten Reviews. Die werden zu 30-50 % korrekt gelesen — was zu wenig ist. Wenn solche Vermerke fachlich wichtig sind, muss der Konstrukteur sie selbst aufnehmen oder in saubere CAD-Annotationen überführen.
Unsere klare Empfehlung: Den Validator als „Rauschen-Filter“ einsetzen. Er findet 80-90 % der Routine-Verstöße zuverlässig, der Senior-Konstrukteur kann sich auf die fachlich anspruchsvollen 10-20 % konzentrieren. Wer den Validator als Vollersatz für den 4-Augen-Review verkauft, schädigt das Vertrauen in das Tool nach den ersten zwei Fehlern.
Pilot-Ergebnisse aus drei Maschinenbau-Projekten
Aus drei Pexon-Pilotprojekten in 2025/2026 (mittelständische Maschinenbauer, 400-1.800 MA):
- Projekt 1, Sondermaschinenbau: 320 DRWs in 6 Wochen geprüft. Trefferquote auf bekannte Norm-Verstöße: 91 %. Review-Zeit pro DRW von 95 Min auf 12 Min reduziert. False-Positive-Rate (Validator markiert OK-Stellen als Verstoß): 8 %.
- Projekt 2, Serien-Maschinenbau: 1.100 DRWs in 8 Wochen. Trefferquote 88 %. Review-Zeit von 45 Min auf 8 Min. False-Positive 11 % — höher, weil die Standardisierung der DRWs schlechter war als in Projekt 1.
- Projekt 3, Anlagenbau: 230 DRWs in 4 Wochen. Trefferquote 93 % (hohe Standardisierung). Review-Zeit von 180 Min auf 22 Min. False-Positive 5 %.
In allen drei Projekten war der größte Hebel die Norm-Verweis-Aktualität (Familie 5). Hier lagen manuelle Trefferquoten bei 40-55 %, der Validator bringt sie auf 88-92 % — weil der VLM nie vergisst, eine Norm-Datenbank-Abfrage zu machen. Das ist der eigentliche Compliance-Gewinn.
Kosten und Zeitrahmen
Aus zwei laufenden Pexon-Projekten der typische Setup-Aufwand:
Laufende Kosten: VLM-Tokens typisch 800-2.500 EUR pro Monat bei 200-500 DRWs pro Monat. Hosting + Storage 200-500 EUR pro Monat. Wartung 0,5-1 PT pro Monat.
ROI-Rechnung: Wenn der manuelle Review-Aufwand pro DRW bei 45-180 Min liegt und der Validator das auf 8-22 Min reduziert, sparen Sie pro DRW 25-160 Min Senior-Konstrukteur-Zeit. Bei 200-500 DRWs pro Monat sind das 80-1.300 Stunden — typisch 0,3-1,2 FTE Senior. Amortisation 5-11 Monate.
Häufig gestellte Fragen
Funktioniert der VLM DRW Validator auch mit DWG-Dateien direkt oder nur mit PDF?
Wir konvertieren intern DWG via ODA File Converter zu PDF, dann PDF zu PNG. Direkter Zugriff auf DWG-Strukturen (z.B. Layer, Block-Definitionen) ist theoretisch möglich, bringt aber wenig zusätzlichen Wert für VLM-basierte Prüfungen. Wer Layer- oder Block-spezifische Prüfungen braucht, fährt mit klassischen DWG-Bibliotheken (AutoLISP, RealDWG) besser.
Können auch 3D-Modelle aus SolidWorks oder NX geprüft werden?
Nicht direkt mit VLM, weil Vision-Modelle 2D-orientiert sind. Für 3D-Geometrie-Prüfungen gibt es spezialisierte CAD-Validierungs-Tools (z.B. Q-Checker, CADIQ), die in der Regel besser für strukturelle Modell-Qualitätsprüfungen geeignet sind. Wir empfehlen die Kombination: 3D-Validierung mit CADIQ-Klasse-Tools, 2D-DRW-Validierung mit VLM.
Wie hoch sind die laufenden Token-Kosten bei vielen DRWs?
Bei 1.000 DRWs pro Monat reden wir über 1.500-4.000 EUR Token-Kosten. Bei sehr hohem DRW-Volumen (>3.000 pro Monat) lohnt sich Prompt-Caching plus Switching auf günstigere Modelle (z.B. GPT-4o-mini Vision für Routine-Familien, Claude Sonnet 4 für Norm-Aktualität-Checks). Damit lassen sich die Kosten um 40-60 % drücken.
Was passiert mit der Compliance, wenn der Validator einen Verstoß übersieht?
Die Verantwortung bleibt beim Senior-Konstrukteur, der die Freigabe gibt. Der Validator ist Tool, nicht juristisch verantwortliche Instanz. In der Audit-Doku wird der Validator-Lauf protokolliert, damit nachvollziehbar ist, welche Prüfungen automatisch erfolgten — der Mensch unterschreibt aber weiterhin. Das ist die saubere Verantwortungs-Architektur.
Kann ich das Tool auch on-premise betreiben für sensible Konstruktionen (Rüstung, Dual-Use)?
Ja. Mit Open-Source-VLMs wie Qwen 2.5-VL oder InternVL 2.5 auf eigener GPU-Infrastruktur. Die Genauigkeit liegt bei 70-85 % gegenüber GPT-4o oder Claude Sonnet 4 — für viele Routine-Prüfungen ausreichend, für komplexe Toleranz-Konstellationen ein Stück weniger zuverlässig. Setup-Aufwand zusätzlich 15-25 PT für Private KI-Infrastruktur.
Nächster Schritt
Wenn Sie aktuell die DRW-Review-Bottlenecks in Ihrem Maschinenbau-Unternehmen analysieren oder bereits einen Prototypen evaluieren: Wir machen das im 6-Wochen-Pilotprojekt für Generative AI konkret — Discovery, ASD/ASE-Erfassung und Pilot mit 50-100 realen DRWs aus Ihrem Bestand.
Verwandte Themen
→FMEA Agent OpenAI: Delta-FMEA bei Design-Change automatisieren
→Norm-Konformitäts-Agent: ISO/DIN/SAE-Updates automatisch mappen
