Technische Dokumentation Wenn das fehlende Datenblatt zur Falle wird

Anbieter zum Thema

Würth Elektronik eiSos GmbH & Co. KG

IBR Leiterplatten GmbH & Co. KG

DMB Technics AG

Wer Handbücher nachlässig schreibt, steht durch eine jetzt verschärfte EU-Vorgaben schnell in der Haftungsfalle. Ein Standpunkt von Guido Körber über unsaubere technische Spezifikationen und die drängende Frage, warum wir dringend bessere Datenblätter schreiben müssen.

Entwickler lieben es, komplexe Schaltungen zu entwickeln. Allerdings hassen sie die Dokumentation ihrer Produkte. Somit wird das Verfassen von Handbüchern zu einem ungeliebten Prozess. Doch Guido Körber warnt: Wer heute noch nach dem Prinzip „Das wird schon logisch sein“ dokumentiert, riskiert nicht nur wütende Kunden, sondern auch knallharte juristische Konsequenzen.

Bei vielen komplexen elektronischen Produkten umfassen die Datenblätter schnell 80 Seiten oder mehr. Beim Lesen der technischen Dokumentation fragt man sich jedoch oft, was der Autor mit dem Text sagen wollte. Komplexe Features werden oftmals sehr lieblos auf einer halben Zeile abgehandelt. Es fehlen Grenzwerte und Begründungen dafür, warum ein Register genau so und nicht anders beschrieben werden muss.

Was bleibt dem Hardware-Entwickler, der das Bauteil integrieren soll? Guido Körber, Geschäftsführer von Code Mercenaries, nennt es treffend „die Methode des unbekümmerten Probierens“, oder kurz: MUP.

In seinem Vortrag auf dem Kongress „Power of Electronics“ hat Körber den Finger in eine Wunde gelegt, die in der Elektronikentwicklung chronisch schmerzt. Die technische Dokumentation wird oft von den Leuten geschrieben, die am tiefsten im Design stecken. Daraus ergibt sich allerdings ein Problem: Sie leiden unter Betriebsblindheit und sie setzen voraus, dass der Leser in ihrem Kopf sitzt und ihre Paradigmen und Kenntnisse teilt. Allerdings funktioniert das selten oder gar nicht.

Von 16 Bit und politischer Korrektheit

Besonders ärgerlich wird es, wenn technische Spezifikationen unsauber oder schlicht irreführend sind. Körber rechnet mit den gängigen Sünden der Halbleiterhersteller ab: Wenn ein Datenblatt einen internen A/D-Wandler mit einer Auflösung von 16 Bit anpreist und ihn damit als „ideal für die Prozessüberwachung“ deklariert, in der Praxis aber ein Offset-Fehler von über zehn Prozent ohne einer Möglichkeit der Kalibrierung vorliegt, dann ist das Bauteil für die Anwendung schlicht unbrauchbar. Wer solche Fehler in der eigenen Dokumentation versteckt oder verschweigt, generiert keine Verkäufe, sondern Support-Kosten und verbrannte Erde.

Gleiches gilt für Inkonsistenzen: Wenn an einer Stelle eine Auflösung von 16 Bit versprochen wird, beim Register aber von 15, 14 oder 13 Bit effektiver Auflösung die Rede ist, bekommt der Leser einen Knoten im Gehirn. Die simple Erklärung, dass es sich um einen Signed Integer handelt, fehlt schlicht.

Ein neues Übel ist laut Körber der Drang, etablierte technische Begriffe aus Gründen der politischen Korrektheit umzubenennen. Wer beim I²C-Bus die klassischen Begriffe „Master“ und „Slave“ durch Konstrukte wie „Host“ und „Secondary Device“ ersetzt, stiftet massive Verwirrung. Der ahnungslose Leser fragt sich unweigerlich: „Sind da physisch zwei Devices in dem Chip verbaut?“ Wer für das Lesen des Handbuchs ein Glossar braucht, hat seinen Job als Autor verfehlt.

Der rechtliche Bumerang fliegt bereits

Doch all diese Datenblatt-Ärgernisse sind längst nicht mehr nur ein Support-Problem. Sie werden zur existenziellen Überlebensfrage. „Ohne ordentliche Dokumentation ist es Bastelei und kein Produkt“, stellt Körber klar.

Die juristische Einschlaggefahr hat sich massiv erhöht: Seit dem 27. September 2026 ist die EmpCo-Richtlinie (EU 2024/825) in Kraft getreten. Wer jetzt noch glaubt, im B2B-Umfeld weniger sorgfältig dokumentieren zu müssen als bei Konsumgütern, irrt gewaltig. Fehlerhafte Angaben, wie beispielsweise Einsatzgrenzen, Umwelteigenschaften und Reparierbarkeit, öffnen die Tür für Schadensersatzforderungen. Wenn ein Kunde das Produkt so benutzt, wie es im unklaren Handbuch steht, und es zu einem Schaden kommt, haftet der Hersteller.

Das Titanic-Paradigma

Körber verdeutlicht, wie katastrophal ein Fehler in der Spezifikation sein kann und wie fehlendes Systemverständnis enden könnte. Er nennt ein extremes, aber treffendes historisches Beispiel: den Untergang der Titanic. Das Schiff als „unsinkbar“ zu dokumentieren, war eine falsche Spezifikation. Richtig wäre die Formulierung „Ausgelegt für den Ausfall maximal einer Zelle“ gewesen. Da diese Grenze nicht kommuniziert wurde, fehlte der Respekt vor der Beschädigung mehrerer Kammern.

Noch gravierender war die ungenügende Anleitung für die Crew: Die Ruder der Titanic lagen im Strömungsschatten der Schiffsschrauben. Als der Kapitän nach der Eisberg-Sichtung „Volle Kraft zurück“ befahl, stoppten die Maschinen. Ohne den Vorwärtsschub der Schrauben verloren die Ruder nahezu jede Wirkung. Das Schiff fuhr minutenlang manövrierunfähig auf das Hindernis zu. Ein reines Dokumentations- und Trainingsversagen.

Wie der Noob-Test helfen kann

Damit die eigenen Produkte nicht dasselbe Schicksal erleiden, rät Körber zu einem brutalen Perspektivwechsel. Dokumentation darf kein Anhängsel sein. Sie muss in dem Moment beginnen, in dem das Produkt definiert wird. Und bevor ein Text an den Kunden geht, empfiehlt Körber den sogenannten Noob-Test: Geben Sie das Handbuch einem intelligenten, aber fachfremden Menschen. Das kann etwa ein Mitarbeiter aus dem Einkauf sein. Wenn dieser nicht versteht, was das Bauteil im Kern tun soll, dann wird es der gestresste Entwickler beim Kunden auch nicht verstehen. (heh)

(ID:50972571)