Technische Zeichnungen automatisch auslesen: Was OCR kann und wo es aufhört
- Veröffentlicht:
- Lesezeit
- 16 Min. Lesezeit
- Autor:
- Abbas Mohammadi
OCR für technische Zeichnungen funktioniert für Schriftfeld, Stückliste und Anmerkungstexte in der Praxis am zuverlässigsten – für Bemaßung, Toleranzen und Form- und Lagesymbole nur mit erheblicher Nacharbeit. Entscheidend ist weniger das Werkzeug als der Bestand: Ein Vektor-PDF aus dem CAD braucht keine Zeichenerkennung, ein Scan aus dem Archiv sehr wohl. Dieser Artikel zeigt, was geht, wo es aufhört und wie Sie die Erkennungsqualität an 30 eigenen Zeichnungen messen.
Vektor-PDF oder Scan? Die Frage, die alles andere entscheidet
Die erste Frage ist nicht, welche Software Sie einsetzen, sondern was in Ihren Dateien steckt. Ein direkt aus dem CAD-System exportiertes PDF enthält Text als Text: jedes Zeichen mit Schriftart, Größe, Drehwinkel und Koordinate. Hier braucht es keine OCR, sondern eine Textextraktion, die diese Positionsdaten mitliefert. Das Ergebnis ist exakt, reproduzierbar und für jede Stelle der Zeichnung adressierbar.
Ein Scan ist das Gegenteil: ein Bild ohne Information darüber, wo ein Zeichen anfängt und aufhört. Vor der Erkennung muss es entzerrt, gedreht und binarisiert werden. Die Tesseract-Dokumentation nennt als Richtwert mindestens 300 dpi und warnt, dass schon eine schiefe Vorlage die Zeilensegmentierung und damit das OCR-Ergebnis erheblich verschlechtert. Wer gescannte Zeichnungen digitalisieren will, hat zusätzlich mit Faltkanten, Stempeln und handschriftlichen Änderungen zu tun. Ein PDF, das nur einen eingebetteten Scan enthält oder dessen Text in Kurven zerlegt wurde, gehört trotz Dateiendung in die Scan-Pipeline.
Text markieren
Eine Bemaßung mit der Maus markieren. Lässt sich Text auswählen, hat die Datei eine Textebene.
Suchen
Mit
Strg+Fnach der Zeichnungsnummer suchen. Kein Treffer trotz markierbarem Text deutet auf zerlegte Schrift oder defekte Zeichencodierung hin.Zoomen
Auf 800 % zoomen. Bleiben Linien scharf, ist es Vektor; werden sie pixelig, ist es ein Raster.
Stichprobe hochrechnen
50 zufällige Dateien aus verschiedenen Jahrgängen so prüfen und den Anteil je Klasse notieren. Diese Verteilung bestimmt, welche Pipeline Sie zuerst bauen.
Gemischte Bestände brauchen zwei Pipelines, die dasselbe Zielschema befüllen. Der häufigste Fehler in der Praxis ist, alle Dateien durch die OCR zu schicken – auch die Vektor-PDFs. Das macht ein exaktes Ergebnis absichtlich ungenau.
OCR für technische Zeichnungen: klassische Engine oder Vision-Modell?
Klassische OCR erkennt Zeichen, Vision-Modelle interpretieren Seiten – beides löst verschiedene Probleme. Eine OCR-Engine wie Tesseract oder EasyOCR segmentiert das Bild in Zeilen und Zeichen, vergibt je Zeichen eine Konfidenz und liefert die Position als Rechteck. Das funktioniert gut bei dichtem, waagerechtem Maschinentext: im Schriftfeld, in der Stückliste, in Anmerkungsblöcken.
Auf der Zeichenfläche bricht diese Stärke ein. Bemaßungen stehen entlang der Maßlinie in beliebigen Winkeln. Text steht in Grafiken, durchkreuzt von Hilfslinien und Schraffuren. Durchmesserzeichen, Toleranzrahmen und Oberflächensymbole sind für eine auf Fließtext trainierte Engine unbekannte Zeichen. Klassische OCR liefert hier nichts oder etwas Falsches – aber sie erfindet nichts, was nicht auf dem Blatt steht.
Vision-Language-Modelle (VLMs), multimodale Sprachmodelle, die ein Seitenbild als Ganzes lesen, verhalten sich umgekehrt. Sie erkennen ohne Training, dass rechts unten ein Schriftfeld liegt, dass eine Tabelle eine Stückliste ist und „Ra 1,6“ eine Oberflächenangabe. Dafür geben sie meist keine Position zurück, liefern bei gleichem Bild nicht immer dasselbe Ergebnis und füllen Lücken mit plausiblen Werten. Der Benchmark OmniDocBench (CVPR 2025), der 981 PDF-Seiten aus neun Dokumenttypen auswertet, nennt als Ursachen schwacher VLM-Ergebnisse genau das: fehlende Inhalte auf dichten Seiten und Halluzinationen auf schwer lesbaren Seiten.
| Kriterium | Klassische OCR | Vision-Modell |
|---|---|---|
| Stärke | Dichter, gerader Maschinentext | Layoutverständnis, Kontext, ungewöhnliche Vorlagen |
| Schwäche | Gedrehter Text, Text in Grafik, Sondersymbole | Erfundene Werte, fehlende Inhalte auf dichten Seiten |
| Positionsangabe | Ja, Rechteck je Zeichen oder Wort | Meist nein oder nur grob |
| Reproduzierbarkeit | Deterministisch | Nicht garantiert |
| Fehlerbild | Leer oder falsch, nie erfunden | Plausibel, aber möglicherweise erfunden |
| Rolle in der Pipeline | Rückgrat | Ergänzung für Klassifizierung, Layout, Sonderfälle |
Daraus folgt die Architektur: deterministische Extraktion als Rückgrat, Modelle als Ergänzung. Aus Vektor-PDFs kommt der Text mit Koordinaten aus der Datei, aus Scans per OCR mit Bounding Boxes und Konfidenz. Ein Vision-Modell darf klassifizieren (Schriftfeld, Stückliste, Ansicht, Schnitt) und Sonderfälle vorschlagen – aber jeder Wert, der ins Zielsystem geschrieben wird, muss auf eine Position im Bild zurückführbar sein. Die OWASP-Empfehlungen dazu sind unspektakulär: Abgleich gegen vertrauenswürdige Quellen und menschliche Prüfung. Für Zeichnungen heißen diese Quellen ERP, PDM und die Zeichnung selbst.
Titelblock, Schriftfeld und Stückliste: die dankbaren Fälle
Das Schriftfeld automatisieren Sie zuerst, weil es drei Eigenschaften hat, die der Rest der Zeichnung nicht hat: feste Position, feste Felder, prüfbares Ergebnis. DIN EN ISO 7200:2004-05 legt die Datenfelder in Schriftfeldern fest und nennt acht Pflichtfelder: gesetzlicher Eigentümer, Sachnummer, Ausgabedatum, Blattnummer, Titel, Genehmiger, Ersteller und Dokumentenart. In der Praxis kommen fast immer Werkstoff, Maßstab, Revision und Allgemeintoleranz hinzu.
Wer den Titelblock automatisch erfassen will, braucht keine allgemeine Layoutanalyse, sondern eine Vorlage je Schriftfeldtyp. Die meisten Betriebe haben zwei bis fünf davon: das aktuelle CAD-Schriftfeld, Vorgängerversionen und die Schriftfelder der wichtigsten Zulieferer. Je Vorlage werden die Feldrechtecke einmal definiert; danach heißt die Aufgabe nur noch, Text in einem bekannten Rechteck zu lesen – der einfachste Fall, den OCR kennt. Bei Vektor-PDFs entfällt selbst das.
| Feld | Pflichtfeld nach ISO 7200 | Validierung gegen | Typischer Lesefehler |
|---|---|---|---|
| Zeichnungs-/Sachnummer | ja | Materialstamm im ERP, Dokumentstamm im PDM | O/0- und I/1-Verwechslung |
| Benennung/Titel | ja | Materialkurztext im ERP | Zeilenumbrüche, abgeschnittene Wörter |
| Ausgabedatum | ja | Freigabedatum im PDM | Datumsformate, zweistellige Jahreszahlen |
| Blattnummer | ja | Anzahl Blätter im Dokumentstamm | „1/3“ als Maßstab gelesen |
| Revision | nein | Änderungsstand im PDM | Verwechslung mit Blattnummer |
| Werkstoff | nein | Werkstoffstamm, Normbezeichnung (z. B. 1.4301) | Leerzeichen und Punkte in Werkstoffnummern |
Der Abgleich ist der eigentliche Hebel. Eine Zeichnungsnummer, die im ERP existiert, ist mit hoher Wahrscheinlichkeit richtig gelesen; eine, die nicht existiert, geht in die Nacharbeit. So wird aus einer Erkennungsrate eine Fehlerliste mit Adresse.
Eine Stückliste aus PDF auslesen ist der zweite dankbare Fall, mit einer Zusatzschwierigkeit: der Tabellenstruktur. Bei Vektor-PDFs helfen die Koordinaten: Texte mit gleicher Y-Position bilden eine Zeile, die Spaltengrenzen ergeben sich aus den Linien. Bei Scans übernimmt das eine Tabellenerkennung, deren Qualität Sie mit dem Maß TEDS (Tree-Edit-Distance-based Similarity) beziffern können, das auch OmniDocBench für Tabellen verwendet. Drei Prüfungen gehören danach immer dazu:
- Jede Positionsnummer der Liste muss genau einmal als Positionsballon in der Zeichnung vorkommen.
- Mengen müssen Zahlen sein; „1x“, „2 St.“ und „2“ sind dieselbe Information in drei Schreibweisen.
- Bei mehrseitigen Listen zeigt ein Bruch in der Nummerierung eine verlorene Zeile; Normteile wie „ISO 4762 M8x30“ werden gegen den Normteilstamm aufgelöst statt frei übernommen.
Maße, Toleranzen und Form- und Lagesymbole: die harten Fälle
Maße und Toleranzen erkennen ist deshalb schwer, weil vier Probleme zusammenkommen, die sich in Schriftfeld und Stückliste nicht stellen:
- Drehung: Maßzahlen stehen parallel zur Maßlinie, in jedem Winkel. Standard-OCR erwartet waagerechte Zeilen.
- Zusammengesetzte Angaben: „Ø 20 H7“, „M12x1,5“, „45 ±0,1“ – Symbol, Zahl, Toleranzklasse und Einheit ergeben nur als Ganzes einen Sinn.
- Sondersymbole: Durchmesser, Tiefe, Senkung, Oberflächenzeichen und die Symbole der geometrischen Tolerierung nach DIN EN ISO 1101:2017-09 kommen in keinem Fließtext-Trainingsdatensatz vor.
- Überlagerung: Maßhilfslinien, Schraffuren und Mittellinien kreuzen die Zeichen. Eine Hilfslinie durch eine „8“ ist für die Segmentierung kaum von einer „B“ zu unterscheiden.
Das eigentliche Problem liegt eine Ebene tiefer. Selbst wenn jedes Zeichen richtig erkannt ist, weiß das System nicht, welche Kante das Maß „45 ±0,1“ beschreibt. Diese Zuordnung von Maß zu Geometrie steht in keinem Text; sie steckt in Maßlinie, Pfeilen und Maßhilfslinien. Ein Toleranzrahmen nach ISO 1101 verweist zusätzlich über Bezugsbuchstaben auf andere Elemente der Zeichnung. Für eine Werkstückdatenbank oder eine Prüfplanung ist ein Maß ohne Bezug wertlos – und genau diese Verknüpfung leistet Zeichenerkennung allein nicht.
Wie ein Lösungsansatz aussieht, zeigt eine Arbeit des Fraunhofer IPA aus dem Forschungsprojekt SE.MA.KI (Stand Juli 2022). Der Demonstrator kombiniert Texterkennung mit EasyOCR, das mit fertigungstypischen Sonderzeichen nachtrainiert wurde, Symbolerkennung in der Zeichnung per KI mit einem auf einer Symbolbibliothek trainierten YOLO-Netz, und eine räumliche Zusammenführung von Text und Symbol über ihre Bounding Boxes – ergänzt um eine Plausibilitätskontrolle, die etwa Maße im Bereich des Schriftfelds als Fehlerkennung verwirft.
Das Fraunhofer IPA gibt für diesen Aufbau eine Erkennungsrate von etwa 70 % an. Das ist ein Wert aus einem Forschungsdemonstrator auf dessen eigenem Zeichnungsbestand, keine Produktangabe und nicht auf andere Bestände übertragbar. Er zeigt aber die Größenordnung, mit der Sie bei Maßen und Symbolen rechnen sollten – und dass die restlichen rund 30 % Prüfaufwand bleiben.
| Zeichnungselement | Schwierigkeit | Warum | Realistisches Ziel |
|---|---|---|---|
| Schriftfeld | niedrig | Feste Position, gerader Text, Stammdatenabgleich | Vollautomatisch mit Ausnahmeliste |
| Stückliste | niedrig bis mittel | Tabellenstruktur, mehrseitig | Automatisch mit Zeilenprüfung |
| Anmerkungen, Allgemeintoleranz | mittel | Freitext, Normverweise | Automatisch, im Volltext durchsuchbar |
| Längenmaße ohne Toleranz | mittel bis hoch | Drehung, Überlagerung, Zuordnung zur Kante | Vorschlag mit Pflichtprüfung |
| Passungen, Gewinde, Durchmesser | hoch | Zusammengesetzte Angabe, Sonderzeichen | Vorschlag mit Pflichtprüfung |
| Form- und Lagetoleranzen | sehr hoch | Rahmen, Symbol, Bezüge über die Zeichnung verknüpft | Erkennung als Hinweis, Erfassung manuell |
Ein Prüfschema, mit dem Sie die Erkennungsqualität selbst messen
Ob eine Software, die technische Zeichnungen auslesen soll, zu Ihrem Bestand passt, können Sie in ein bis zwei Personentagen selbst messen – bevor Sie einem Anbieterversprechen glauben. Das Prinzip ist dasselbe wie bei OmniDocBench: manuell erfasste Sollwerte, ein festes Zählschema und getrennte Auswertung je Elementtyp, weil eine Gesamtquote über alle Felder nichts aussagt.
Stichprobe ziehen
30 Zeichnungen: 10 Vektor-PDFs, 10 gute Scans, 10 schlechte Scans (alte Vorlagen, Stempel, Falten). Alle Schriftfeldvarianten müssen vertreten sein.
Zielfelder festlegen
Nur Felder, die ein Zielsystem später braucht: etwa Zeichnungsnummer, Benennung, Revision, Werkstoff, alle Stücklistenpositionen und – falls gewünscht – alle tolerierten Maße.
Sollwerte anlegen
Eine Person erfasst alle Zielfelder manuell in eine Tabelle, eine zweite prüft sie. Die Zeit dafür mitschreiben – sie ist Ihr Vergleichswert für die manuelle Erfassung.
Extraktion laufen lassen
Jeden Kandidaten mit identischen Einstellungen über alle 30 Zeichnungen laufen lassen, Ergebnisse feldweise in dieselbe Tabellenstruktur schreiben.
Zählen und getrennt auswerten
Je Feld genau eines von vier Ergebnissen vergeben – richtig, falsch, leer, halluziniert – und die Quoten je Feldtyp und je Bestandsklasse berechnen. Nie zu einer Gesamtquote zusammenfassen.
- richtig
- Der Wert stimmt nach Normalisierung von Leerzeichen, Groß- und Kleinschreibung und Dezimaltrennzeichen mit dem Sollwert überein.
- falsch
- Ein Wert, der vom Sollwert abweicht, aber auf einem vorhandenen Element der Zeichnung beruht – etwa die Blattnummer im Feld Maßstab.
- leer
- Kein Wert geliefert, obwohl einer auf der Zeichnung steht. Sichtbar und damit in der Nacharbeit billig.
- halluziniert
- Ein Wert, der an keiner Stelle der Zeichnung steht. Nur bei Modellen möglich, die Lücken füllen; die teuerste Kategorie.
- Falschquote
- Anteil von falsch plus halluziniert an allen Feldern mit Sollwert. Diese Zahl entscheidet über den Produktivbetrieb.
Der wichtigste Wert ist die Falschquote, nicht die Trefferquote. Ein Rechenbeispiel mit angenommenen Zahlen: Ein System mit 85 % richtig und 15 % leer ist im Betrieb angenehmer als eines mit 92 % richtig und 8 % falsch. Im ersten Fall prüft ein Mensch die leeren Felder, im zweiten müsste er alle prüfen, weil niemand weiß, wo die 8 % sitzen. Für Freitextfelder wie die Benennung ist richtig oder falsch zu grob; hier hilft die normalisierte Editierdistanz, die OmniDocBench für Text verwendet – die Zahl der Zeichenänderungen bis zum Sollwert, geteilt durch die Textlänge.
Wann sich Automatisierung rechnet – und wann nicht
Ob sich die Automatisierung rechnet, hängt von fünf Größen ab, die Sie nach dem Prüfschema kennen: Anzahl der Zeichnungen, Zielfelder je Zeichnung, manuelle Erfassungszeit je Feld, Falschquote und Prüfzeit je Feld. Die Rechnung ist eine Gegenüberstellung, kein Versprechen.
Ersparnis = N × F × (t_manuell − t_prüf − q_falsch × t_korrektur) − K_pipeline
- N
- Anzahl Zeichnungen
- F
- Zielfelder je Zeichnung
- t_manuell
- manuelle Erfassungszeit je Feld (Schritt 3 des Prüfschemas)
- t_prüf
- Prüfzeit je automatisch erfasstem Feld
- q_falsch
- Falschquote: falsch plus halluziniert (Schritt 5)
- t_korrektur
- Korrekturzeit je falschem Feld
- K_pipeline
- Einrichtung, Schriftfeldvorlagen, Nachtraining, Betrieb
Ein fiktives Rechenbeispiel: Angenommen, ein Archiv umfasst 20.000 Zeichnungen mit je acht Schriftfeldfeldern, die manuelle Erfassung dauert 20 Sekunden je Feld, die Falschquote liegt bei 3 %, die Prüfung eines Vorschlags kostet 4 Sekunden und eine Korrektur 30 Sekunden. Manuell sind das 160.000 Felder × 20 s, rund 889 Stunden. Automatisch sind es 160.000 × 4 s, rund 178 Stunden Prüfung, plus 4.800 Korrekturen × 30 s, also 40 Stunden. Die Differenz von rund 670 Stunden muss die Pipeline finanzieren. Mit 2.000 Zeichnungen ergibt dieselbe Rechnung 67 Stunden – dafür baut niemand eine Pipeline.
Drei Einschränkungen gehören dazu. Erstens: Steigt die Falschquote auf 15 %, wie sie für Maße eher realistisch ist, kommen im Beispiel 200 Stunden Korrektur hinzu, und die Prüfung unsicherer Felder dauert eher 10 als 4 Sekunden – der Vorteil sinkt auf rund 245 Stunden vor Pipeline-Kosten. Zweitens: Die Prüfung entfällt nie ganz; wer sie streicht, verschiebt die Fehler ins ERP, wo sie teurer sind. Drittens: Bei kleinen Beständen frisst allein die Einrichtung der Schriftfeldvorlagen den Nutzen – dann bleibt manuelle Erfassung günstiger.
Was Sie mit den extrahierten Daten anfangen
Extrahierte Schriftfelddaten sind selten das Ziel, sondern der Schlüssel zu anderen Systemen. Vier Anschlussfälle kommen in Betrieben immer wieder vor:
- Zeichnungsbestand durchsuchbar machen: Volltext aus Anmerkungen und Schriftfeld in eine Suche laden, damit „alle Zeichnungen mit Werkstoff 1.4571 ab Revision C“ eine Abfrage ist und keine Wochenaufgabe.
- Stammdatenabgleich: Zeichnungsnummer, Revision und Werkstoff gegen ERP und PDM prüfen und Abweichungen als Liste ausgeben.
- Ersatzteilsuche über Werkstoff und Maß: Sind Hauptabmessungen und Werkstoff erfasst, findet die Instandhaltung ein passendes Teil, auch wenn die Lagerbezeichnung anders lautet.
- Digitales Typenschild vorbereiten: Schriftfelddaten decken einen großen Teil der Stammdaten ab, die eine Verwaltungsschale braucht.
Zeichnungen werden selten allein ausgewertet. Meist liegen daneben Handbücher, Prüfprotokolle und Wartungsberichte, und die eigentliche Frage lautet: Welches Anzugsmoment gilt für die Schraube an Position 12? Wie aus einem PDF-Berg eine beantwortbare Frage wird, beschreibt KI für technische Dokumentation. Die Architektur, mit der ein Chatbot für technische Handbücher seine Antworten mit Quelle und Seite belegt, funktioniert für Zeichnungen genauso – sofern die Positionsdaten aus der Extraktion erhalten bleiben. Und sobald Schriftfelder Namen von Erstellern und Prüfern enthalten, gelten die Anforderungen, die RAG auf eigenen Dokumenten nach der DSK-Orientierungshilfe technisch stellt.
Fazit: Schriftfeld automatisieren, Maße prüfen lassen
OCR für technische Zeichnungen ist keine Ja-oder-Nein-Frage. Schriftfeld und Stückliste lassen sich mit deterministischer Extraktion, Vorlagen je Schriftfeldtyp und Stammdatenabgleich zuverlässig automatisieren – bei Vektor-PDFs ganz ohne Zeichenerkennung. Maße, Toleranzen und Form- und Lagesymbole bleiben ein Vorschlagssystem mit Pflichtprüfung, weil nicht die Zeichen, sondern ihre Zuordnung zur Geometrie das Problem sind. Vision-Modelle helfen beim Layout, dürfen aber keinen Wert ohne Position ins Zielsystem schreiben.
Der nächste Schritt kostet zwei Tage und kein Budget: 30 Zeichnungen, manuell erfasste Sollwerte, vier Zählkategorien, getrennte Auswertung je Feldtyp. Danach wissen Sie, welcher Teil Ihres Archivs sich automatisch erschließen lässt. Wenn Sie für diese Messung oder die anschließende Pipeline einen Sparringspartner suchen, finden Sie unter KI-Lösungen für technische Dokumente, wie ralwo solche Vorhaben angeht.
Häufige Fragen
Quellen
- Fertigungsrelevante Informationen in 2D-Zeichnungen automatisch erkennen und verarbeiten — Fraunhofer IPA
- OmniDocBench: Benchmarking Diverse PDF Document Parsing with Comprehensive Annotations — arXiv (CVPR 2025)
- LLM09:2025 Misinformation – OWASP Gen AI Security Project — OWASP
- Improving the quality of the output – Tesseract documentation — Tesseract OCR
- DIN EN ISO 7200:2004-05 – Technische Produktdokumentation – Datenfelder in Schriftfeldern und Dokumentenstammdaten — DIN Media
- DIN EN ISO 1101:2017-09 – Geometrische Produktspezifikation (GPS) – Geometrische Tolerierung – Tolerierung von Form, Richtung, Ort und Lauf — DIN Media
- Schriftfeld — Wikipedia (deutschsprachige Ausgabe)