ReadDataByIdentifier (0x22)

Was ist ReadDataByIdentifier (0x22)?

ReadDataByIdentifier liest einen benannten Datensatz aus einem Steuergerät. Die zwei Bytes nach der Service-ID sind der Data Identifier (DID); die Antwort spiegelt den Identifier und hängt die Daten an.

Ein normaler Ablauf:

Richtung	Bytes	Bedeutung
Request	22 F1 90	DID 0xF190 lesen (VIN)
Positive Antwort	62 F1 90 57 30 4C ...	Identifier plus 17-Byte-VIN
Negative Antwort	7F 22 31	requestOutOfRange, DID nicht unterstützt

Weitere typische negative Antworten sind 7F 22 13 (incorrectMessageLengthOrInvalidFormat, ungerade Anzahl Identifier-Bytes), 7F 22 33 (securityAccessDenied, DID nur nach einem Unlock lesbar) und 7F 22 7F (serviceNotSupportedInActiveSession).

Wo ist es definiert?

ISO 14229-1:2020 definiert ReadDataByIdentifier (0x22) im Data transmission functional unit. Die Norm beschreibt den Request als SID gefolgt von einem oder mehreren zwei Byte langen Identifiern, die positive Antwort als jeden Identifier gefolgt von seinem Datensatz und den reservierten Identifikations-DID-Bereich 0xF180 bis 0xF1FF. Dateninhalt und Länge jedes DID kommen aus der OEM-Diagnosebeschreibung. Der Transport auf CAN ist ISO 15765-2, weshalb ein langer Datensatz als Mehr-Frame-Nachricht ankommt.

Was es in der Praxis bedeutet

ReadDataByIdentifier ist das Rückgrat der Diagnose. Identifikationsdaten, Messwerte, Kalibrierstatus und Fehlerkontext werden alle so gelesen. Die Zugriffsregel pro DID, welche Session, ob SecurityAccess nötig ist, kommt aus der Spezifikation. Bei der Validierung wird geprüft:

• jeder DID antwortet nur in der vorgesehenen Session und auf dem vorgesehenen Security-Level;
• ein nicht unterstützter Identifier gibt NRC 0x31, nicht einen falschen oder leeren Datensatz;
• ungerade oder abgeschnittene Requests geben NRC 0x13;
• Länge und Typ der Antwort passen zur Spezifikation.

Wir sehen regelmäßig Identifikations-DIDs wie Seriennummern und Fingerprints, die ohne Session und ohne Unlock lesbar sind, was oft in Ordnung ist, und gelegentlich sensible Datensätze, die in der Default Session liegen und das nicht sollten.

Wie AutoST es testet

AutoST liest DIDs bei der Enumeration, entweder den Identifikationsbereich 0xF180 bis 0xF19F als Default oder den vollen Bereich 0x0000 bis 0xFFFF, und hält fest, welche Identifier in welcher Session antworten. Mit einer importierten ODX-, PDX- oder CDD-Datei wird jeder gefundene Identifier mit seinem echten Namen und dekodierten Wert statt einer rohen Zahl gezeigt, sodass das Ergebnis wie deine Diagnosespezifikation liest und nicht wie ein Hex-Dump.