# DID (Data Identifier) > A data identifier (DID) is a two-byte value from 0x0000 to 0xFFFF that names a data record inside an ECU: the VIN is F190, the ECU serial number F18C, the active diagnostic session F186. ReadDataByIdentifier (0x22) reads it, WriteDataByIdentifier (0x2E) writes it, and 0x2A, 0x2C and 0x2F use DIDs as well. ISO 14229-1 Annex C reserves the identification block 0xF180 to 0xF19F and a few other ranges; everything else is defined by the manufacturer in ODX or CDD files. A DID is the 16-bit identifier UDS uses to address a data record, read with 0x22 and written with 0x2E. Standard ranges from ISO 14229-1 Annex C and writable DIDs. Source: https://auto-st.com/glossary/did ยท Updated: 2026-10-07 ## What is a DID? A data identifier is a 16-bit number that stands for one data record inside the ECU. Instead of addressing memory, the tester asks for a DID and the ECU returns the record with whatever length and encoding the manufacturer defined. `22 F1 90` reads the VIN and the ECU answers `62 F1 90` followed by 17 bytes; `22 F1 86` returns the active diagnostic session as one byte, `62 F1 86 03` for the extended session. Several services work with DIDs: ReadDataByIdentifier (`0x22`) and WriteDataByIdentifier (`0x2E`), ReadScalingDataByIdentifier (`0x24`), ReadDataByPeriodicIdentifier (`0x2A`, which uses the low byte of the `F2xx` range), DynamicallyDefineDataIdentifier (`0x2C`) and InputOutputControlByIdentifier (`0x2F`). ## Where is it defined? ISO 14229-1:2020 Annex C lists the standard data identifiers. The identification block `0xF180` to `0xF19F` carries boot and application software identification (`F180` to `F182`), the fingerprints (`F183` to `F185`), the active session (`F186`), spare part and software numbers (`F187` to `F189`), the system supplier identifiers (`F18A`, `F18B`), the ECU serial number (`F18C`), the VIN (`F190`), the ECU hardware number (`F191`), the programming date (`F199`) and the repair shop codes (`F198`, `F19A`). Further ranges are reserved for periodic identifiers (`F200` to `F2FF`), dynamically defined identifiers (`F300` to `F3FF`), OBD (`F400` to `F8FF`), tachograph, airbag and safety systems, and system supplier specific use (`FD00` to `FEFF`). The ranges `0x0100` to `0xA5FF` and others are vehicle manufacturer specific and are documented in the ECU's ODX or CDD file. ## What it means in practice DIDs are where information leaks and where unauthorised changes happen. On the bench, the first thing a tester reads is the identification block, because it tells you software version, hardware revision and programming history and almost every ECU answers it. The second thing is a sweep of the whole identifier space per session, because the interesting DIDs are the undocumented ones: debug counters, internal states, sometimes key material or configuration bytes. We regularly see identification DIDs that are writable in the extended session without SecurityAccess, which lets anyone rewrite the fingerprints or the serial number and destroys the audit trail of who programmed the ECU. We also see DIDs that accept any length on write and ECUs that return different data for the same DID in different sessions. ## How AutoST tests it AutoST reads the identification range `0xF180` to `0xF19F` by default and can sweep the full `0x0000` to `0xFFFF` space in every discovered session, over CAN or DoIP. An imported ODX, PDX or CDD file names the discovered identifiers and provides the expected lengths, and the opt-in write-probing phase checks which DIDs accept a `0x2E` write, with wrong-length and write-back checks, off by default and confirmed before it runs. ## Common misunderstandings A DID is not a memory address; ReadMemoryByAddress (`0x23`) is a different service with a different risk profile. And a DID that answers `0x31` in the default session may well answer in the extended session, so a sweep in one session says nothing about the others. ## FAQ **How many DIDs does an ECU have?** Anything from a dozen to several thousand. The standard reserves ranges but does not force an ECU to implement a single DID; the manufacturer specification does. A full sweep of 0x0000 to 0xFFFF with ReadDataByIdentifier takes roughly ten minutes per session over CAN and is the only way to find undocumented ones. **Which DIDs are security relevant?** Those an attacker would read or change: the VIN (F190), the serial number (F18C), the fingerprints F183 to F185 and the repair shop codes F198 and F19A that record who programmed the ECU, plus manufacturer DIDs that hold calibration, keys or feature flags. Readable where needed, writable only after SecurityAccess, if at all. **Why does an ECU answer 0x31 for a DID?** requestOutOfRange means the ECU does not support that DID in the current session or at all. It is the normal answer during a DID sweep and marks the identifiers that do not exist; 0x33 securityAccessDenied marks the ones that exist but are protected. ## Sources - [ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1: Application layer, Annex C (data identifier definitions)](https://www.iso.org/standard/72439.html) - [ISO 22901-1:2008 Road vehicles, Open diagnostic data exchange (ODX), Part 1: Data model specification](https://www.iso.org/standard/41207.html) ## Related - [ReadDataByIdentifier (0x22)](https://auto-st.com/glossary/read-data-by-identifier-0x22) - [WriteDataByIdentifier (0x2E)](https://auto-st.com/glossary/write-data-by-identifier-0x2e) - [ODX (Open Diagnostic Data Exchange)](https://auto-st.com/glossary/odx) - [UDS DID Lookup: Standard Data Identifiers](https://auto-st.com/tools/did-lookup) - [Your ODX and CDD, turned into tests.](https://auto-st.com/did-routine-scanning) - [Know every door into the ECU.](https://auto-st.com/uds-enumeration) --- AutoST by Zyberum. Canonical page: https://auto-st.com/glossary/did