Understanding UDS Request and Response Frame Formats

This page covers the UDS Request Frame Format and UDS Response message Format. It describes the fields used in a UDS service request message, UDS positive response message, and UDS negative response message.

UDS Request/Response Message

UDS (Unified Diagnostic Services) is a request and response based protocol based on a client-server architecture. It is a collection of diagnostic services, each identified by a unique service identifier (SID). The SID is one byte in size, ranging from 0x00 to 0x3E.

UDS Request Message | Service Request Message

The UDS service request message has the following structure:

{ SIDRQ, SubFn, DID, Data_Record }

Where:

• SIDRQ: Service ID Request (Mandatory)
• SubFn: Sub Function (Optional)
• DID: Data Identifier (Optional)
• Data_Record: Data Record (Optional)

‘M’ stands for mandatory and ‘O’ stands for optional. Using the ‘SID’ field in the service request message, the server understands the service requested by the client.

Refer to UDS specifications for the meanings of various SIDs with numbers and their detailed services. The SID is a mandatory field and present in all service request messages.

For example:

• SID of 0x22 indicates “Read data by identifier”.
• SID of 0x31 indicates “Routine control”.

The “Sub Function” field specifies which sub-functionality of the service has been requested. It is also 1 byte in size. This field exists only for certain selected services.

For example:

• 0x01 - Start the routine
• 0x02 - Stop the routine
• 0x03 - Results are requested by routine

The DID (Data Identifier) field is 2 bytes in size. All data elements are identified by unique numbers. In OBD (On-Board Diagnostics), DIDs are standardized, whereas in UDS, different car manufacturers define their own unique DIDs that can be understood by a UDS tester tool. One service request message can contain one or multiple DID elements.

The ‘Data Record’ field is an optional field. For example, if the DID is for ‘write data by identifier’, then the data values to be written are specified after the DID in the message.

UDS Positive Response Message

In UDS off-board diagnostics, the tester acts as the client, and the ECU acts as the server. When the server (i.e., ECU) receives a service request message, it checks the message. If everything is valid, it executes the requested service and responds to the client (i.e., tester) with a positive response message.

The UDS positive response message has the following structure:

{ SIDPR, SubFn, DID, Data_Record }

Where:

• SIDPR = SIDRQ + 0x40

For example, for a SIDRQ of 0x2E, SIDPR equals 0x6E.

UDS Negative Response Message

In UDS off-board diagnostics, the tester acts as the client, and the ECU acts as the server. When the server (i.e., ECU) receives a service request message, it checks the message. If the server finds something is wrong, it responds with a negative response message (of a total of 3 bytes).

Reasons for the server not performing the requested service can include a wrong message format, unfavorable working conditions, etc.

The UDS negative response message has the following structure:

{ NR_SID, SIDRQ, NRC }

Where:

• NR_SID is always 0x7F.
• SIDRQ is the same as the SID present in the service request message.
• NRC is the Negative Response Code.

The standard defines various UDS NRC values with their meanings.

For example:

• NRC of 0x01 indicates “General reject”.
• NRC of 0x11 indicates “Service not supported”.
• NRC of 0x12 indicates “Sub-function not supported”.
• NRC of 0x13 indicates “Invalid message length/format”.