DTC vor der Demontage: Was ein OBD-Protokoll wirklich beweistAlle Beiträge

DTC vor der Demontage: Was ein OBD-Protokoll wirklich beweist

Ein DTC-Snapshot dokumentiert den Diagnosezustand zu einem Zeitpunkt; er beweist weder Fehlerfreiheit noch die Plug-and-play-Fähigkeit eines Steuergeräts.

Veröffentlicht: 2026-09-07Lesezeit: 2 minDaten, KI & Innovation
KI & DatenAutoverwertungVINOE-NummerFahrzeugdatenTeileidentifikationAPI

Ein Diagnoseprotokoll vor der Demontage erhöht die Transparenz elektronischer Teile. Es kann zeigen, welche Steuergeräte erreichbar waren, welche Fehlercodes gespeichert waren und unter welchen Bedingungen gelesen wurde. Es ist jedoch kein Zertifikat für vollständige Funktion: Fehler können sporadisch, gelöscht, außerhalb der Eigendiagnose oder erst unter Last sichtbar sein.

Aussagekraft richtig begrenzen

  • 'Keine DTC gespeichert' bedeutet nur, dass das verwendete System zum Auslesezeitpunkt keine entsprechenden Codes meldete.
  • Kommunikation mit einem Steuergerät belegt Erreichbarkeit, nicht alle Ein- und Ausgänge oder Sicherheitsfunktionen.
  • Umgebungsdaten, Kilometerstand, Batteriespannung, Zündung und Diagnosegerät beeinflussen die Interpretation.
  • Gelöschte Fehler, Readiness-Status und Zeit seit Löschung müssen sichtbar bleiben.
  • Nach Ausbau können Transport, elektrostatische Entladung, Feuchtigkeit oder falscher Einbau neue Schäden verursachen.

Prozess mit Diagnosegerät, ERP und tapinomahub

  1. Fahrzeugakte per POST /vehicles/intake anlegen oder Fahrzeug mit GET /vin/{vin}/vehicle abgleichen.
  2. Vollständigen Fahrzeugschnelltest mit einem geeigneten externen Diagnosegerät vor der Demontage durchführen.
  3. Rohprotokoll, Werkzeug, Softwarestand, Zeitpunkt, Spannung und Fahrzeugzustand unverändert im ERP speichern.
  4. Ausgebautes Teil über POST /scanner/label/extract-partnumbers und GET /parts/oe/{oeNumber} identifizieren.
  5. DTC-Auszug, Fahrzeugidentität, OE-Nummer, Ausbau- und Sichtprüfung in einer Teileakte verbinden.
  6. Im Angebot präzise zwischen Diagnosebefund, zusätzlicher Funktionsprüfung und erforderlicher Codierung unterscheiden.

Mindestinhalt eines belastbaren Protokolls

  • VIN oder pseudonymisierte Fahrzeugkennung und tapiId
  • Datum, Uhrzeit, Kilometerstand, Bordspannung und Betriebszustand
  • Diagnosegerät, Softwareversion und verwendeter Scanmodus
  • Erreichbare und nicht erreichbare Steuergeräte
  • DTC mit Status, Klartext und vorhandenen Umgebungsdaten
  • Lösch- oder Reparaturereignisse sowie unveränderte Originaldatei

Quellen und Rechtsgrundlagen

Häufige Fragen

Beweist ein leeres Fehlerprotokoll, dass das Teil funktioniert?

Nein. Es ist ein nützlicher Zeitpunktbefund, ersetzt aber keine bauteilspezifische Funktions- und Sicherheitsprüfung.

Darf der Fehlerspeicher vor dem Verkauf gelöscht werden?

Für einen transparenten Nachweis sollte der unveränderte Eingangsscan erhalten bleiben. Weitere Scans nach Reparatur oder Löschung müssen als eigene Ereignisse dokumentiert werden.

Kann tapinomahub den DTC-Scan durchführen?

Nein. Die öffentliche API bietet keinen OBD-Scan. Sie ordnet Fahrzeug und OE-Teil strukturiert zu; der Diagnosebefund kommt aus einem externen Werkzeug.