Understanding UDS DID (Data Identifier)

In the context of the Unified Diagnostic Services (UDS) protocol, DID stands for Data Identifier.

A Data Identifier is essentially a parameter that allows diagnostic testers or scan tools to request specific data from electronic control units (ECUs) in a vehicle. Think of it like an address or label for a particular piece of data stored within the ECU.

ECUs in a vehicle store a vast amount of information, and the UDS protocol provides a standardized way to access this data using these Data Identifiers. When performing diagnostics using UDS, a tester sends a diagnostic request to a specific ECU, and this request includes the Data Identifier for the data it wants to retrieve.

The ECU then responds with the requested data associated with that identifier. Data Identifiers are used for a variety of tasks, including reading sensor values, checking the status of specific functions, and retrieving diagnostic trouble codes (DTCs).

UDS Request and Response Frame Format

Here are some practical examples of how Data Identifiers are used in UDS diagnostics:

• Reading Sensor Values: You can use a Data Identifier to request real-time data from sensors connected to the ECU, such as engine coolant temperature, vehicle speed, or oxygen sensor readings.

• Status Checking: Data Identifiers can be used to check the status of various functions within an ECU. For example, you might check if a particular system, like cruise control, is currently active.

• DTC Retrieval: To retrieve diagnostic trouble codes (DTCs) from an ECU, you send a Data Identifier that corresponds to a request for stored fault codes. The ECU then responds with the specific DTCs and their descriptions, helping technicians diagnose problems.

• Configuration Information: Data Identifiers can also be used to retrieve configuration or parameter data stored within an ECU. This can be useful for customizing settings or configurations within the vehicle.

In most UDS request services, different types of request data parameters are used to provide further configuration of a request beyond the Service ID (SID) and optional sub-function byte. Here are two examples:

• Example #1: Service 0x19 lets a user read DTC information.
• Example #2: Service type 0x22 is “Read Data By Identifier.” This service utilizes a DID, which is 2 bytes in size and ranges from 0 to 65535 (0xFFFF).

The DID serves as a parameter identifier for both requests and responses, similar to a Parameter ID (PID) used in OBD2.

It’s important to note that Data Identifiers are often proprietary. They are mainly known by the vehicle Original Equipment Manufacturers (OEMs), although some DIDs are standardized across the industry.

Table of UDS DIDs

The following table provides some examples of UDS DIDs commonly used in UDS request frames:

In conclusion, Data Identifiers are a cornerstone of the UDS protocol. They offer a standardized way to access and retrieve specific data from ECUs within a vehicle. This makes diagnostic tasks more efficient and consistent across different vehicle makes and models that support the UDS protocol.