Während des Fahrzeugbetriebs sammelt jedes Steuergerät aufgetretene Fehlerzustände in seinem Fehlerspeicher. Mit entsprechenden Werkzeugen lässt sich auf diesen Speicher mit Diagnosediensten zugreifen. Typische Abfragen sind:
Der Werkstatttester erzeugt einen Diagnose-Request und sendet ihn an das Steuergerät. Das Steuergerät antwortet mit einer Diagnose-Response. Die Response enthält meist mehrere Fehlermeldungen mit ihren Fehler-Codes, den zugehörigen Statusmasken und Umgebungsdaten (Bild 1). Alle Daten müssen anschließend ausgewertet werden. Fehlerursachen lassen sich mit den aufbereiteten Informationen sehr schnell eingrenzen und die defekte Komponente kann ausgetauscht werden.
Eine Stärke des Fehlerspeichers ist also, dass die Algorithmen zum Erkennen von Fehlerzuständen vom Fahrzeug bereitgestellt werden. Das setzt jedoch voraus, dass diese Diagnosefunktion selbst korrekt arbeitet. Folglich muss diese Funktion während der Fahrzeugentwicklung intensiv getestet werden. Wegen der sehr großen Zahl existierender Fehler-Codes und der umfangreichen Umgebungsdaten und Fehlerzustände können die Tests der Diagnosefunktion sehr aufwendig werden, insbesondere weil für jeden Test auch die Parameter der Diagnose-Requests gesetzt und die Antwortparameter geprüft werden müssen. Dieser Aspekt lässt sich jedoch stark vereinfachen, indem der Tester auf eine abstrakte Sichtweise zurückgreift. Routinetätigkeiten zum Setzen, Prüfen und Auffinden von Fehlereinträgen werden so komplett verborgen.
Es wäre ideal, wenn nach Stimulation (Bild 1) einer im Fehlerspeicher aufzuzeichnenden Situation eine Testfunktion zur Verfügung stünde, die alle UDS-spezifischen Eigenheiten verbirgt und die Diagnoseantworten selbstständig prüft. Ein solche Funktion könnte lauten: „Lies die Umgebungsdaten für Fehler-Code XYZ, prüfe, ob er aktiv ist und die Spannung beim Auftreten des Fehlers zwischen 11,5 und 12,5 Volt lag!“ Der Test-Code selber wäre dann kompakt und übersichtlich.