# UDS DID Lookup: Standard Data Identifiers

> This lookup lists the data identifiers (DIDs) that ISO 14229-1 Annex C reserves for standard purposes: the identification block 0xF180 to 0xF19F (boot and application software, fingerprints, VIN, serial and part numbers, programming date), the manufacturer and supplier specific ranges, and the periodic, dynamic, OBD, tachograph, airbag and safety ranges up to 0xFFFF. Search by code, name or meaning. Everything outside these ranges is defined by the ECU description (ODX or CDD).

Look up the data identifiers reserved by ISO 14229-1: VIN (F190), active session (F186), software and hardware numbers, fingerprints, OBD and safety ranges.

Source: https://auto-st.com/tools/did-lookup · Updated: 2026-10-07

## How it works

The table is Annex C of ISO 14229-1:2020 in searchable form. Single identifiers are listed with their ISO name; the reserved ranges (manufacturer specific, supplier specific, periodic, dynamically defined, OBD, tachograph, airbag, safety) are listed by their first code with the end of the range in the name, and a search for any code inside a range finds that range. The meaning column is ours: what the identifier is for and what to check when you test.

## How to read the result

The identification block 0xF180 to 0xF19F is the ECU's business card and the first thing a scan reads. It also contains the identifiers that record who programmed the ECU and when (the fingerprints and repair shop codes), which is why write probing concentrates on it. The ranges above 0xF200 mostly exist to map other protocols into UDS: periodic identifiers for 0x2A, dynamic identifiers defined with 0x2C, and the OBD PIDs of ISO 15031.

Anything from 0x0000 to 0xF17F and the manufacturer ranges is defined by the OEM. Without the ODX or CDD file, a scanner sees only "answered" or "not answered"; with it, the result reads like the specification.

## Limits

The tool knows the standard, not your ECU. It cannot tell you which DIDs exist on a specific controller, in which session, or whether they are writable. That is what the DID and routine scan in AutoST does: it enumerates the whole identifier space per session, names the results from the ODX or CDD and probes which identifiers accept a write.

## FAQ

**Which DIDs should every ECU answer?**

ISO 14229-1 reserves the ranges but does not force an ECU to implement any particular DID. In practice almost every ECU answers F186 (active session), F190 (VIN) and the F18x identification block, because OEM diagnostic specifications require them. Reading those first is how a scan calibrates itself.

**Where do the other DIDs come from?**

From the ECU description: the ODX (ISO 22901) or CDD (Vector CANdela) file that the OEM or supplier maintains. It names every DID, its length and its data type. AutoST imports these files so scan results show names instead of hex numbers and so write probing knows the expected length.

**Which standard DIDs are security relevant?**

Those an attacker would want to change: VIN (F190), serial number (F18C), the fingerprints (F183 to F185) and repair shop codes (F198, F19A), which record who programmed the ECU. They must be readable where needed and writable only in the right session after SecurityAccess, if at all. AutoST tests exactly that in its write-probing stage.

## Sources

- [ISO 14229-1:2020 Unified diagnostic services (UDS), Part 1: Application layer, Annex C (data identifier definitions)](https://www.iso.org/standard/72439.html)

## Related

- [DID (Data Identifier)](https://auto-st.com/glossary/did)
- [ODX (Open Diagnostic Data Exchange)](https://auto-st.com/glossary/odx)
- [CDD (CANdela Diagnostic Description)](https://auto-st.com/glossary/cdd)
- [UDS Message Decoder](https://auto-st.com/tools/uds-message-decoder)
- [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/tools/did-lookup