GlossaryUDS

ReadDataByIdentifier (0x22)

UDS ReadDataByIdentifier (0x22) reads a data identifier (DID) from an ECU. The request and response bytes, which session it needs and what to validate.

Updated October 7, 2026This page as Markdown

In short

ReadDataByIdentifier (0x22) reads a data record from an ECU by its two-byte data identifier (DID). The request 22 F1 90 asks for the VIN DID, the positive response 62 F1 90 followed by the data returns it. Many DIDs are readable in the default session, others require the extended session or SecurityAccess. It is the most used UDS read service, so its access rules decide what a tester can read.

What is ReadDataByIdentifier (0x22)?

ReadDataByIdentifier reads a named data record from an ECU. The two bytes after the service ID are the data identifier (DID); the response echoes the identifier and appends the data.

A normal exchange:

Direction	Bytes	Meaning
Request	`22 F1 90`	read DID 0xF190 (VIN)
Positive response	`62 F1 90 57 30 4C ...`	identifier plus 17-byte VIN
Negative response	`7F 22 31`	requestOutOfRange, DID not supported

Other typical negative responses are 7F 22 13 (incorrectMessageLengthOrInvalidFormat, odd number of identifier bytes), 7F 22 33 (securityAccessDenied, DID readable only after an unlock) and 7F 22 7F (serviceNotSupportedInActiveSession).

Where is it defined?

ISO 14229-1:2020 defines ReadDataByIdentifier (0x22) in the Data transmission functional unit. The standard specifies the request as the SID followed by one or more two-byte identifiers, the positive response as each identifier followed by its data record, and the reserved identification DID range 0xF180 to 0xF1FF. The data content and the length of each DID come from the OEM diagnostic description. The transport on CAN is ISO 15765-2, which is why a long record arrives as a multi-frame message.

What it means in practice

ReadDataByIdentifier is the backbone of diagnostics. Identification data, measurement values, calibration status and fault context are all read this way. The access rule per DID, which session, whether SecurityAccess is needed, comes from the specification. In validation, engineers check:

each DID answers only in the intended session and at the intended security level;
an unsupported identifier gives NRC 0x31, not a wrong or empty record;
odd or truncated requests give NRC 0x13;
the returned length and type match the specification.

We regularly see identification DIDs such as serial numbers and fingerprints that read without any session or unlock, which is often acceptable, and occasionally sensitive records exposed in the default session that should not be.

How AutoST tests it

AutoST reads DIDs during enumeration, either the identification range 0xF180 to 0xF19F by default or the full 0x0000 to 0xFFFF space, and records which identifiers answer in which session. With an imported ODX, PDX or CDD file, each discovered identifier is shown with its real name and decoded value instead of a raw number, so the result reads like your diagnostic specification rather than a hex dump.

FAQ

Frequently asked questions

Can one request read several DIDs?

Yes. ISO 14229-1 allows multiple two-byte identifiers in a single 0x22 request, for example 22 F1 90 F1 87. The ECU answers with each identifier followed by its data, limited by the transport layer and the P2 timing.

What does 62 F1 90 mean?

The response service ID is the request SID plus 0x40, so 0x22 becomes 0x62. F1 90 echoes the identifier that was read, and the bytes after it are the data record, here the 17 ASCII characters of the VIN.

Which DIDs are standardised?

ISO 14229-1 reserves the 0xF180 to 0xF1FF range for identification DIDs such as VIN (F190), and application and boot software identifiers. Most other identifiers are defined by the OEM in the ODX or CDD file.

Sources

← Glossary