ADAS-Logs lesen — Objektlisten, Kalibrierstatus und Fehlercodes richtig deuten

Ein Fehlercode ist kein Urteil, sondern ein Anfang

Nach einem Scheibentausch an einem Mittelklassewagen mit Spurhalteassistent bleibt die Warnleuchte an, obwohl die Werkstatt die Scheibe fachgerecht getauscht hat. Das Diagnosegerät zeigt einen Fehlercode, eine Zeile „Kalibrierung nicht abgeschlossen“ und eine Objektliste mit mehreren Einträgen, die während der anschließenden Testfahrt aufgezeichnet wurden. Auf den ersten Blick wirkt das wie ein klarer Befund: Fehler vorhanden, also Bauteil defekt. Tatsächlich sagt keiner dieser drei Werte allein etwas darüber aus, ob ein Sensor kaputt, ein Referenzwert falsch oder die Kalibrierung schlicht noch nicht durchgelaufen ist. Genau an dieser Stelle beginnt die eigentliche Arbeit mit einem ADAS-Log.

Moderne Fahrerassistenz ist kein einzelnes Bauteil. Sie ist eine Kette aus Messung, Interpretation und Reaktion, die Kamera, Radar, Fahrdynamiksensoren, Lenkung und Bremse über gemeinsame Koordinatensysteme verbindet. Ändert sich an einem Fahrzeug etwas, das mechanisch harmlos wirkt — eine andere Reifengröße, eine veränderte Fahrzeughöhe, eine neue Scheibe —, kann trotzdem genau diese gemeinsame Referenz verschoben sein. Ein Assistenzsystem reagiert dann womöglich korrekt auf eine reale, neue Bewegung des Fahrzeugs, nicht fehlerhaft auf ein Phantom. Wer diesen Unterschied nicht kennt, tauscht im Zweifel den falschen Sensor.

Dieser Beitrag trennt deshalb bewusst mehrere Ebenen eines ADAS-Logs. Dazu gehören die Objektliste, die zeigt, was das System erkannt hat, und der Kalibrierstatus, der die geometrische Referenz beschreibt. Dazu kommen die Fehlercodes, die einen erkannten Zustand markieren, und die Zeitbasis, ohne die sich keiner dieser Werte sinnvoll deuten lässt. Am Ende steht die Frage, wie sich daraus ein beweiskräftiges Protokoll bauen lässt — und wo ein Eingriff am Fahrzeug die Zulassungskette berührt.

Warum ein Assistenzsystem seine Umgebung nicht direkt sieht

Ein Radarsensor misst keine Fahrzeuge. Er misst Reflexionen elektromagnetischer Wellen an Oberflächen, aus denen sich Entfernung, Relativgeschwindigkeit und Winkel berechnen lassen. Eine Kamera liefert zunächst nur Pixelwerte, aus denen ein Algorithmus Kanten, Muster und schließlich Objektklassen wie Pkw, Fußgänger oder Fahrbahnmarkierung ableitet. Fahrdynamiksensoren wiederum erfassen Bewegungsgrößen des eigenen Fahrzeugs — Gierrate, Lenkwinkel, Radgeschwindigkeit —, ohne die Umgebung überhaupt zu betrachten. Erst wenn all diese Rohdaten zusammengeführt werden, entsteht das, was ein Log als „Objekt“ oder „Ereignis“ ausweist.

Diese Kette aus Messung, Signalaufbereitung, Interpretation und Regelaktion bedeutet für die Diagnose etwas Konkretes. Ein beobachteter Lenkeingriff oder eine Warnung beweist nie direkt, welcher Sensor ursächlich war. Dieselbe Fahrzeugreaktion kann aus einem fehlerhaften Radarwert, einer falsch interpretierten Kameraszene oder einer fehlerhaften Fusion zwischen beiden entstehen. Das Log zeigt zunächst nur das Ergebnis dieser Kette, nicht automatisch ihren Ursprung. Wer eine Ursache sucht, geht deshalb rückwärts durch die Ebenen — erst die physikalische Messung, dann die Aufbereitung, dann die Interpretation, erst danach die Reaktion.

Für die Praxis heißt das: Ein Fehlercode oder ein auffälliger Log-Eintrag sitzt fast nie an der Stelle, an der er zuerst auffällt. Ein Regelbefehl steht am Ende der Kette. Seine Ursache kann zwei oder drei Ebenen weiter vorn liegen — in der Fusion, der Signalaufbereitung oder sogar in der reinen physikalischen Messung.

Objektlisten lesen: was eine Object-ID wirklich bedeutet

Eine Objektliste im ADAS-Log listet für jeden Messzyklus die Objekte auf, die das System aktuell verfolgt. Dazu gehören eine laufende Kennung, Position, Geschwindigkeit und eine Klassifikation wie Fahrzeug, Fußgänger oder unbekanntes Hindernis. Diese Kennung, oft als Object-ID bezeichnet, ist kein reales Kennzeichen und keine dauerhafte Identität. Verliert das System ein Objekt kurzzeitig aus dem Blickfeld, etwa weil ein anderes Fahrzeug es verdeckt, vergibt die Fusion beim erneuten Erfassen häufig eine neue Kennung — obwohl es sich um dasselbe physische Fahrzeug handelt.

Für die Diagnose folgt daraus eine einfache, aber oft übersehene Regel: Ein Wechsel der Object-ID im Log ist für sich genommen kein Fehler, sondern normales Verhalten der Trackinglogik. Anders liegt der Fall, wenn sich Objekte auffällig oft neu bilden, obwohl die Sichtbedingungen unverändert gut sind. Auch ein Objekt an einer physikalisch unmöglichen Stelle verdient einen genaueren Blick auf die zugrunde liegenden Rohdaten. Ein einzelner ID-Wechsel allein beweist noch keine Fehlfunktion.

Sinnvoll ist es deshalb, eine Objektliste nie isoliert zu lesen, sondern gemeinsam mit Geschwindigkeit, Lenkwinkel und Systemmodus auf derselben Zeitachse. Nur so lässt sich unterscheiden, ob ein sprunghafter Eintrag tatsächlich ein Sensorartefakt ist oder ob das Fahrzeug in diesem Moment schlicht eine Kurve durchfahren hat und die Fusion korrekt reagiert.

Confidence-Werte sind keine Wahrscheinlichkeit im Alltagssinn

Neben Position und Klasse trägt jeder Objekteintrag häufig einen Confidence-Wert, meist als Prozentzahl oder als Skala von null bis eins. Intuitiv liest sich das wie eine Trefferwahrscheinlichkeit — „90 Prozent sicher ein Fahrzeug“. Tatsächlich ist dieser Wert ein systeminternes, herstellerspezifisches Maß. Er kann aus mehreren Teilalgorithmen zusammengesetzt sein und lässt sich zwischen unterschiedlichen Systemen weder in der Berechnung noch in der Skala vergleichen.

Ein niedriger Confidence-Wert bedeutet deshalb nicht zwangsläufig eine defekte Erkennung. Er kann genauso gut eine schwierige, aber völlig normale Situation widerspiegeln — Gegenlicht, Regen, ein teilweise verdecktes Objekt. Umgekehrt schützt ein hoher Wert nicht davor, dass die Klassifikation im Einzelfall falsch liegt. Wer aus einem einzelnen Confidence-Wert eine allgemeine Aussage über die Zuverlässigkeit des ganzen Systems ableitet, überträgt eine interne Rechengröße auf eine Bedeutung, die sie nicht hat.

Für ein belastbares Protokoll zählt deshalb der Verlauf, nicht der Einzelwert. Sinkt die Confidence eines Objekts über mehrere Zyklen kontinuierlich, während sich die Sichtbedingungen nicht ändern, ist das ein deutlich stärkeres Signal als ein einzelner niedriger Wert an einer Stelle im Log.

Kalibrierstatus im Log: was „kalibriert“ tatsächlich aussagt

Ein Kalibrierstatus im Log zeigt an, ob Kamera und Radar auf eine gemeinsame geometrische Referenz eingemessen sind. Gemeint ist, ob ihre optische beziehungsweise elektronische Achse mit der tatsächlichen Fahrzeuglängsachse übereinstimmt. Diese Referenz entsteht bei der Erstkalibrierung im Werk oder in einer Fachwerkstatt. Sie bleibt so lange gültig, bis sich die Geometrie des Fahrzeugs oder die Lage eines Sensors ändert.

„Kalibrierung erfolgreich“ im Log bedeutet dabei nicht automatisch, dass jede Fahrsituation validiert ist. Der Status bestätigt lediglich, dass der Kalibriervorgang innerhalb der dafür vorgesehenen Toleranzen abgeschlossen wurde — nicht, dass die Funktion in jeder denkbaren Wetter-, Licht- oder Verkehrssituation korrekt arbeitet. Diese beiden Aussagen werden in der Praxis häufig gleichgesetzt. Genau das gehört zu den häufigsten Fehlinterpretationen bei der Log-Auswertung.

Ebenso wichtig ist die Trennung zwischen drei unterschiedlichen Nullpunkten: dem mechanischen Geradeauslauf des Fahrzeugs, dem elektronischen Nullpunkt des Lenkwinkelsensors und der geometrischen Ausrichtung der Kamera. Diese drei Größen sind miteinander verknüpft, aber nicht identisch. Ein Log, das nur einen der drei Werte zeigt, beantwortet nicht automatisch die Frage nach den anderen beiden.

Wann der Kalibrierstatus eine Neukalibrierung verlangt

Zwei Veränderungen am Fahrzeug tauchen in der Praxis besonders häufig auf, wenn ein Kalibrierstatus plötzlich „nicht kalibriert“ oder „außerhalb der Toleranz“ meldet. Der erste Weg betrifft die Fahrzeughöhe oder Spur. Ändert sich die reale Bewegungsreferenz des Fahrzeugs, etwa durch eine andere Fahrwerkseinstellung, kann sich die Assistenzregelung auffällig verhalten, obwohl kein Sensor defekt ist — sie reagiert korrekt auf eine veränderte Wirklichkeit. Der zweite Weg betrifft die Sensorlage selbst. Wird eine Scheibe getauscht, ein Kamerahalter gelöst oder ein Radarsensor neu montiert, verschiebt sich die optische oder geometrische Achse, und die Objekt- beziehungsweise Spurreferenz driftet.

Für die Log-Auswertung folgt daraus eine klare Reihenfolge: erst die Mechanik und die Referenzgeometrie prüfen, dann die Software oder den Sensor verdächtigen. Wer diese Reihenfolge umkehrt, tauscht im schlechtesten Fall einen funktionierenden Sensor gegen einen baugleichen aus. Er wundert sich dann, warum der Fehler bestehen bleibt — weil die eigentliche Ursache in der Fahrzeuggeometrie lag, nicht im Bauteil.

Welche konkreten Schritte eine Neukalibrierung im Einzelnen braucht, hängt stark vom Fahrzeug, vom Sensorhersteller und vom jeweiligen Verfahren ab. Das ist ein eigenes, sehr praxisnahes Thema für sich. Für die Log-Lektüre selbst zählt vor allem eines: der Status vor und nach einer mechanischen Änderung, dokumentiert auf derselben Zeitachse wie die übrigen Werte.

DTC, Event und Degradation richtig unterscheiden

Ein Fehlercode, im Log meist als DTC geführt, beschreibt einen vom Steuergerät erkannten Zustand oder Fehlerpfad — nicht automatisch eine defekte Komponente. Ein DTC kann durch einen elektrischen Defekt entstehen, durch eine Plausibilitätsverletzung zwischen zwei Sensoren, durch eine Grenzwertüberschreitung oder schlicht durch eine noch nicht abgeschlossene Kalibrierung. Der Code allein sagt nicht, welcher dieser Fälle zutrifft.

Neben klassischen Fehlercodes führen viele Systeme zusätzlich Ereigniseinträge, die kein DTC im engeren Sinn sind, aber trotzdem protokolliert werden. Ein Beispiel ist die automatische Degradation, bei der eine Funktion ihre Genauigkeitsanforderungen bewusst herabsetzt, statt komplett auszufallen. Eine solche Degradation kann greifen, wenn Sichtbedingungen schlecht sind oder ein Sensor vorübergehend unzuverlässige Werte liefert. Das System reduziert dann seinen Funktionsumfang, statt sich falsch sicher zu verhalten. Wer im Log nur nach Fehlercodes sucht, übersieht solche Einträge leicht.

Für eine saubere Auswertung lohnt sich deshalb, alle drei Kategorien getrennt zu betrachten: den DTC als markierten Zustand, das Event als protokolliertes Verhalten und die Degradation als bewussten Rückzug der Funktion. Erst das Zusammenspiel aller drei ergibt ein Bild davon, was tatsächlich passiert ist. Ein einzelner DTC bleibt dabei immer nur der Startpunkt einer Prüfung, keine Bestätigung der Ursache.

Warum Kamera, Radar, Lenkung und Bremse dieselbe Zeitbasis brauchen

Jeder der beteiligten Sensoren und Steuergeräte misst und meldet in einem eigenen Takt. Ein Radarsensor aktualisiert seine Objektliste in einem anderen Intervall als eine Kamera, und beide unterscheiden sich wiederum vom Takt der Lenkwinkel- oder Bremssteuerung. Werden diese Signale ohne gemeinsame Zeitbasis übereinandergelegt, entsteht schnell eine scheinbare Reihenfolge, die mit der tatsächlichen physikalischen Abfolge nichts zu tun hat.

Ein Beispiel macht das greifbar. Wirkt ein Lenkeingriff im Log unmittelbar nach einem Confidence-Abfall, sieht das nach einer klaren Kausalkette aus — erst schlechte Erkennung, dann falscher Eingriff. Synchronisiert man dieselben Kanäle jedoch korrekt, kann sich zeigen, dass der Lenkeingriff bereits vorher begonnen hatte. Beide Ereignisse liefen dann in Wirklichkeit unabhängig voneinander. Ohne saubere Zeitbasis verwechselt die Auswertung leicht eine zeitliche Nähe mit einer tatsächlichen Ursache.

Deshalb gehören Geschwindigkeit, Lenkwinkel, Gierrate, Bremszustand, Sensor-Alignment und Systemmodus in jedem brauchbaren Log auf dieselbe, gemeinsam referenzierte Zeitachse. Fehlt dieser Kontext, liefert selbst ein technisch hochauflösendes Log nur eine scheinbare Genauigkeit, die sich bei der Auswertung nicht einlösen lässt.

Dropouts und Buslast: wann ein Aussetzer kein Sensorfehler ist

Ein kurzer Aussetzer in der Objektliste — ein Objekt verschwindet für einen oder zwei Zyklen und taucht danach wieder auf — wird im Log oft als Dropout bezeichnet. Nicht jeder Dropout bedeutet, dass der Sensor selbst versagt hat. Ebenso häufig steckt die Ursache im Datenbus, über den Kamera, Radar und Steuergeräte ihre Werte austauschen. Ist der Bus stark ausgelastet, etwa weil viele Steuergeräte gleichzeitig senden, kann eine einzelne Nachricht verzögert ankommen oder in seltenen Fällen verloren gehen.

Für die Unterscheidung hilft ein Blick auf das Muster. Tritt ein Aussetzer regelmäßig bei hoher Systemlast auf, etwa in komplexen Verkehrssituationen mit vielen gleichzeitig erkannten Objekten, spricht das eher für eine Buslast- oder Verarbeitungsgrenze als für einen defekten Sensor. Tritt derselbe Aussetzer dagegen unabhängig von der Verkehrssituation immer am selben physischen Sensor auf, deutet das stärker auf ein Problem an genau diesem Bauteil hin.

Wichtig bleibt in beiden Fällen: Ein einzelner Dropout ist noch kein Beweis. Erst ein wiederkehrendes Muster über mehrere Fahrten, verglichen mit Buslast und Systemzustand zum jeweiligen Zeitpunkt, liefert eine belastbare Aussage darüber, wo die eigentliche Grenze liegt.

Plausibilisierung mit der realen Fahrzeugbewegung

Die aussagekräftigste Prüfung eines ADAS-Logs vergleicht nicht nur interne Systemwerte miteinander. Sie stellt sie der tatsächlichen Fahrzeugbewegung gegenüber. Wirkt eine Objekterkennung oder ein Lenkeingriff im Log auffällig, lohnt sich zuerst eine Frage: Läuft das Fahrzeug mechanisch geradeaus, und sind die dokumentierten Achs- und Höhenwerte plausibel? Erst wenn diese Grundlage stimmt, wird ein Sensorfehler zur naheliegenden Erklärung.

Eine veränderte Achsgeometrie kann das Fahrzeug tatsächlich anders laufen lassen, als es die Assistenzsoftware ursprünglich erwartet hat. In diesem Fall reagiert das System womöglich vollkommen korrekt auf eine neue, reale Bewegung — nicht fehlerhaft auf ein Phantom. Diese Kausalrichtung wird in der Praxis häufig verwechselt. Statt zuerst die Mechanik zu hinterfragen, wird sofort die Software oder der Sensor als Ursache vermutet.

Eine zweite Kontrollprüfung betrifft die Zeitbasis selbst. Werden mehrere relevante Signale auf identischer Zeitachse verglichen und verschwindet eine zunächst auffällige Kausalität nach korrekter Synchronisierung, war die scheinbare Verbindung zwischen den Ereignissen von Anfang an nicht tragfähig. Beide Prüfungen gehören deshalb an den Anfang jeder Log-Auswertung, nicht ans Ende — erst die Geometrie, dann die Zeitbasis.

Was ein belastbares Diagnoseprotokoll enthalten muss

Ein einzelner Log-Ausschnitt beweist selten etwas Verlässliches. Aussagekräftig wird ein ADAS-Log erst als Vorher-Nachher-Dokumentation: derselbe Fahrzeugzustand, dieselbe Strecke oder zumindest vergleichbare Bedingungen, einmal vor und einmal nach einer relevanten Änderung. Nur im Vergleich lässt sich beurteilen, ob eine Auffälligkeit neu ist oder schon vorher bestand.

Ein Mindestsatz an Angaben gehört deshalb in jedes brauchbare Protokoll. Dazu zählen die Fahrzeug- und Softwarevariante, alle vorgenommenen Umbauten, die verwendete Zeitbasis, der Betriebszustand des Fahrzeugs während der Aufzeichnung und, soweit relevant, die Umgebungsbedingungen. Fehlt einer dieser Punkte, lässt sich ein späterer Vergleich nicht mehr sauber ziehen. Man weiß dann zwar, was das System gemeldet hat, aber nicht mehr, unter welchen Bedingungen.

Eine Diagnoseaussage, die nicht auf mindestens zwei voneinander unabhängige Beobachtungen entlang dieser Kette gestützt ist, bleibt eine Vermutung. Wer nur den letzten Wert in der Kette notiert — etwa „Fehlercode X gesetzt“ —, verliert die entscheidende Information. Sie fehlt später genau dort, wo zwischen einem echten Defekt, einer verschobenen Referenz und einer falsch interpretierten Situation zu unterscheiden wäre.

Umbauten, ADAS und die Frage nach der Zulassungskette

Wer an einem Fahrzeug etwas ändert, das die ADAS-Referenzgeometrie berührt — eine andere Fahrzeughöhe, eine andere Rad-Reifen-Kombination, ein Sensorumbau —, bewegt sich technisch schnell in einem Bereich, der über die reine Log-Auswertung hinausgeht. Eine Objektliste oder ein Kalibrierstatus zeigt zwar, ob das System nach der Änderung noch plausibel arbeitet. Sie beantwortet aber nicht automatisch, ob die Änderung selbst zulassungsrechtlich unbedenklich ist.

Umbauten am eigenen Fahrzeug. Ob ein Umbau auf öffentlichen Straßen betrieben werden darf, entscheidet der Genehmigungszustand des Fahrzeugs — die Genehmigung des Teils, der Einbau nach ihren Auflagen und, wo nötig, die Abnahme durch eine dafür zuständige Stelle. Solange diese Kette nicht vollständig ist, gehört der Umbau auf Privatgelände, Testflächen und in nicht öffentliche Bereiche.

Für sicherheitsrelevante Assistenzsysteme kommt eine zusätzliche Ebene hinzu, die rein technischer Natur ist. Ein System, das seine Umgebung falsch einschätzt, weil eine Referenz nicht neu kalibriert wurde, kann im schlechtesten Fall zu spät oder falsch eingreifen. Diese Erklärung ersetzt weder eine fahrzeugbezogene Freigabe noch eine Begutachtung durch eine dafür zuständige Stelle. Sie zeigt lediglich, wie sich die Wirkung einer Änderung im Log überhaupt erkennen lässt, bevor über ihre Zulässigkeit entschieden wird.

Häufige Fragen

Einordnung: wo die Angaben herkommen

Die Fundstellen stehen hier gebündelt, damit der Fließtext ohne Normkürzel und Herstellerlinks auskommt. Die ISO-Normen sind kostenpflichtige Katalogwerke ohne öffentlich verlinkbaren Volltext und werden deshalb nur im Klartext genannt. Der Normtext zu § 19 StVZO ist am 18.09.2026 am amtlichen Angebot gegengelesen.