Part of a series on UDS – if you missed it, check out the introduction to the protocol.
What is it?
Data by Identifier, or DID for short, is a core component of building out ECU diagnostics and being able to troubleshoot a malfunctioning ECU. A DID is essentially a piece of data that is given a 16-bit identification code – hence the name data by identifier. This 16-bit ID uniquely binds a piece of data, its length, and its interpretation together into a DID. What each DID represents is entirely up to the purview of the system designer. You may chose to represent internal variables with separate DIDs to facilitate easy read access. You may also combine several items of data into a single DID. Many designers also make use of bit-fields to show the state of a sub-system via a series of booleans.
For example, see our fictional ECU’s list of supported DIDs:
| Data Identifier | Name | Length (Bytes) | Interpretation |
| 0xF190 | Vehicle Identification Number (VIN) | 17 | 17 bytes of ASCII Data representing the VIN |
| 0xF170 | Board Part Number | 4 | Unique 32-bit board part number |
| 0xA001 | System Voltage | 4 | Fixed point value. Scaling of 0.01V, offset of 16384 counts |
| 0xA108 | Door Ajar Status | 1 | Bit-field (0 is closed, 1 is open) Bit 0 – Front Driver Door Status Bit 1 – Front Passenger Door Status Bit 2 – Rear Driver Door Status Bit 3 – Read Passenger Door Status Bit 4 – Trunk Status Bit 5 – Hood Status Bit 6 – Gas Tank Status |
How’s it work?
There are several UDS services that use DIDs. The two most popular are Read Data By Identifier, which is service ID 0x22, and Write Data by Identifier, which has service ID 0x2E. Like the names suggest, service 0x22 is used to read data from the ECUs, and service 0x2E is used to write data into the ECUs. Depending on the DID, it can be either readable, writable, or both.
Read Data by Identifier (0x22)
For service 0x22, there is no sub-service – rather the bytes following the service ID are interpreted as Data ID’s.
As can be seen, the client requests a Read Data by ID of ID 0xA001 (system voltage from the table above) from the server. The server replies with a positive reply (0x62), the ID of the data identifier (0xA001) and finally the data itself. Clearly this is an essential service used for reading predefined values out of the ECU.
An interesting feature of this service, which engineers often omit while designing and testing their UDS servers, is that multiple DIDs can be requested at a time by the tester. This is done simply by adding more IDs in the request. The response can then be decrypted based on the lengths of the individual DIDs.
Notice how the tester issued a read request for DID 0xA001 and 0xA108? And the server replied back with the data for 0xA001, and then in the same reply, the data for 0xA108.
Write Data by Identifier (0x2E)
Analogous to the Read DID Service, Write Data by ID allows the client to write data into predefined values. For example, programming the Vehicle Identification Number (VIN) into an ECU is often done through this service.
As can be seen above, the client requests a Write Data by ID service (0x2E), followed by the ID of the variable to be written (0xF190), and finally the correct length of data required for this variable (17 bytes). The server then validates the data being written (length checks, value checks, etc.) and if all went well, replies with a positive response. Depending on the sensitivity of the data being written or read, individual DIDs may be gated behind UDS security.
Conclusion
Data Identifiers provide an easy way to choose what data can be read out of an ECU, or written into it, by mapping 16-bit IDs with predefined information and lengths. Typical automotive ECUs can have 100’s of DIDs that show information as diverse as internal variables to board part numbers. Among the most popular services related to DIDs are Read Data by Identifier (0x22) and Write Data by Identifier (0x2E).
Shayan Mukhtar 