# WriteDataByIdentifier (0x2E)

> WriteDataByIdentifier (0x2E) schreibt einen Datensatz in ein Steuergerät über seinen zwei Byte langen Data Identifier (DID). Der Request 2E F1 98 gefolgt von den Daten schreibt DID 0xF198, die positive Antwort 6E F1 98 spiegelt den Identifier. Schreiben ändert den Zustand, also brauchen die meisten schreibbaren DIDs die Extended Session und SecurityAccess. Welche Identifier in welcher Session schreibbar sind, ist ein zentraler Prüfpunkt.

UDS WriteDataByIdentifier (0x2E) schreibt einen Data Identifier (DID) in ein Steuergerät. Die Request- und Response-Bytes, welche Session nötig ist und was zu prüfen ist.

Source: https://auto-st.com/de/glossar/write-data-by-identifier-0x2e · Updated: 2026-10-07

## 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.

## FAQ

**Wie unterscheidet sich 0x2E von 0x22?**

ReadDataByIdentifier (0x22) liefert den aktuellen Wert eines DID; WriteDataByIdentifier (0x2E) ersetzt ihn. 0x2E trägt die neuen Daten im Request und ändert den Zustand, deshalb braucht es fast immer eine höhere Session und SecurityAccess als der passende Lesezugriff.

**Kann ein Request mehrere DIDs schreiben?**

Nein. Anders als 0x22 schreibt WriteDataByIdentifier genau einen Identifier pro Request: die SID, die zwei Identifier-Bytes, dann den Datensatz. Das Steuergerät muss die feste Länge dieses DID kennen, um den Request zu prüfen.

**Was passiert bei falscher Länge?**

Passen die Daten nicht zur Länge, die das Steuergerät für diesen DID erwartet, antwortet es mit NRC 0x13 (incorrectMessageLengthOrInvalidFormat) und schreibt nicht. Eine korrekte Implementierung schreibt nie einen Teildatensatz.

## Sources

- [ISO 14229-1:2020 Straßenfahrzeuge, Unified diagnostic services (UDS), Teil 1: Anwendungsschicht, Data transmission functional unit, WriteDataByIdentifier (0x2E)](https://www.iso.org/standard/72439.html)
- [ISO 15765-2 Straßenfahrzeuge, Diagnosekommunikation über CAN (DoCAN), Teil 2: Transportprotokoll und Netzwerkschichtdienste](https://www.iso.org/standard/84211.html)

## Related

- [DID (Data Identifier)](https://auto-st.com/de/glossar/did)
- [ReadDataByIdentifier (0x22)](https://auto-st.com/de/glossar/read-data-by-identifier-0x22)
- [UDS (Unified Diagnostic Services)](https://auto-st.com/de/glossar/uds)
- [Dein ODX und CDD, zu Tests gemacht.](https://auto-st.com/de/did-und-routinen-scan)
- [Kenne jede Tür ins ECU.](https://auto-st.com/de/uds-enumeration)
- [UDS-Nachrichten-Decoder](https://auto-st.com/de/tools/uds-nachrichten-decoder)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/de/glossar/write-data-by-identifier-0x2e