WriteDataByIdentifier (0x2E)

Was ist WriteDataByIdentifier (0x2E)?

WriteDataByIdentifier schreibt einen benannten Datensatz in ein Steuergerät. Die zwei Bytes nach der Service-ID sind der Data Identifier (DID), der Rest des Requests sind die neuen Daten. Die positive Antwort spiegelt nur den Identifier, ohne Daten.

Ein normaler Ablauf:

Richtung	Bytes	Bedeutung
Request	2E F1 98 01 02 03 04	DID 0xF198 mit vier Bytes schreiben
Positive Antwort	6E F1 98	Schreiben akzeptiert
Negative Antwort	7F 2E 33	securityAccessDenied

Weitere typische negative Antworten sind 7F 2E 31 (requestOutOfRange, DID nicht schreibbar), 7F 2E 13 (incorrectMessageLengthOrInvalidFormat, Datenlänge falsch für den DID), 7F 2E 22 (conditionsNotCorrect) und 7F 2E 7F (serviceNotSupportedInActiveSession).

Wo ist es definiert?

ISO 14229-1:2020 definiert WriteDataByIdentifier (0x2E) im Data transmission functional unit. Die Norm beschreibt den Request als SID, zwei Byte Identifier und Datensatz, die positive Antwort als SID plus 0x40 und Identifier und die feste Datenlänge pro Identifier. Die Zugriffsregeln und die Identifier-Liste kommen aus der OEM-Diagnosebeschreibung. Auf CAN ist der Transport ISO 15765-2.

Was es in der Praxis bedeutet

Ein Schreibzugriff auf einen DID ändert den Zustand, deshalb ist es der Service, den ein sorgfältiger Test zuletzt anfasst. Welche Identifier in welcher Session und auf welchem Security-Level schreibbar sind, legt die Spezifikation fest. Bei der Validierung wird geprüft:

• jeder schreibbare DID ist nur in der vorgesehenen Session und nach dem vorgesehenen Unlock schreibbar;
• ein Schreibzugriff auf einen nur lesbaren DID gibt NRC 0x31, keinen stillen Erfolg;
• die Datenlänge wird erzwungen: ein zu kurzer oder zu langer Datensatz gibt NRC 0x13 und keinen Teilschreibzugriff;
• der Wert liest sich mit 0x22 exakt so zurück, wie er geschrieben wurde;
• Bedingungen wie ein laufender Motor erzeugen korrekt conditionsNotCorrect.

Wir sehen regelmäßig schreibbare Identifikations-DIDs, darunter Seriennummern und Fingerprints, die einen Schreibzugriff in der Extended Session ohne SecurityAccess akzeptieren, wodurch sich ein Datensatz überschreiben lässt, der fest sein sollte.

Wie AutoST es testet

Weil Schreiben destruktiv ist, lässt AutoST das Schreibtesten (0x2E) im Default aus und fragt vor dem Start ausdrücklich nach. Aktiviert prüft es DID-Schreibzugriffe mit Falschlängen- und Rückleseprüfungen gegen die Identifier aus deiner importierten ODX-, PDX- oder CDD-Datei, hält fest, ob das Steuergerät die korrekte Länge erzwingt und welche Session und welches Security-Level jeder Schreibzugriff braucht, und brute-forct keine unbekannten Identifier.