kkingjae 2025. 1. 19. 17:25

What is the UDS Protocol?

UDS is a communication protocol used in ECU to enable diagnostic, firmware update, routine testing.

UDS protocol (ISO 14229) is standarized with standards(CAN, KWP 2000, Ethernet, LIN)

We can connect a CAN BUS I/F to the OBD2 connector of a car and send UDS request in to the vehicle.

 

UDS message structure

❶ Protocol control information (PCI)

PCI filed is not th the UDS request itself, but is required for diagnostic UDS requests made on CAN Bus.

in short, the PCI field can be 1-3bytes long and contain information related to the transmission of message that don't fit within a signle CAN frame. → we will detail this more in CAN BUS transport protocol (ISO-TP)

 

❷ UDS Service ID (SID)

when you wish to utilize a specific UDS service, the UDS request message should contain the USD SID. 

We will mainly focus on UDS Service 0x22 which is used to read data from an ECU.

❸ UDS Sub function byte

the sub function byte is used in some UDS request frame. 

however, that in some UDS service like 0x22 the sub function byte is not used.

when a reqeust is sent to an ECU, the ECU may respond positively or negatively. 

in case the response is positive, the tester may want to suppress the response.

→ this is done by setting the 1st bit to 1 in the. sub function byte. 

the remaining 7 bits can be used to define up to 128 sub function value.

for example, when reading DTC Info via SID 0x19, the sub function can be used to control the report type.

 ❹ UDS 'request data parameter' - Data Identifier (DID)

various types of request data parameters are used to provide further configuration of a request beyond the SID and optional sub function byte. 

 

(example #1)

service 0x19, read dtc information lets you read DTC Information. the UDS reqeust for SID 0x19 includes a sub function byte 0x02, then you can read DTC via a status mask. the sub function byte is followed by a 1-byte parameter called DTC status mask to provide further information.

 

(example #2)

service 0x22, read data by identifier. this service uses a data identifier(DID), which is 2-byte value between 0 and 65535(0xffff). the DID service as a parameter idntifier for both request/response. 

Data Identifiers can be proprietary and only known by OEMs, though some DID are standardized. 

 

 

Positive vs Negative UDS response. 

When ECU responds positively to an UDS request, the response frame is structured with similar elements as the request frame. for example, a 'positive' response to a service 0x22 request will contain the response SID 0x62 (0x22 + 0x40) and the 2-byte DID. 

However, in some cases an ECU may provide a negative response to an UDS request 

 

UDS vs CAN Bus : Standards & OSI model 

to better understand UDS, we will look at how it relates to CAN bus and the OSI model.

the CAN is described by a data-link layer and physical layer in the OSI model.

In contrast to CAN, UDS is a higher layer protocol and utilizes both the session layer(5) and application layer(7) 

 

CAN ISO-TP, Transport Protocol (ISO 15765-2)

When implementing diagnostics on CAN, the size of CAN Frame payload.

ISO 15765-2 was establised to solve the challenge of large payloads for CAN based vehicle diagnostics.

the ISO-TP standard outlines how to communicate CAN Data payloads up to 4095 bytes through segmentation

► Flow Control (FC)

the flow control frame is used to configure the subsequent communication. 

 

❶ ISO-TP : Single Frame communication 

this requset is a single frame (SF)

In this simplest case, a tester tool send a single frame to request data from an ECU.

If the response can be contained in a 7-byte payload, the ECU provides a single frame response. 

 

❷ ISO-TP : Multi frame communication

when the payload exceeds 7 bytes, it needs to be split across multiple CAN frames.

As before, a tester starts by sending a single frame (SF) request to an ECU (sender).

However, in this case the response exceeds 7 bytes. 

because of this, the ECU sends a first frame (FF) that contains information on the total packet length as well as the initial chunk of data. when the tester recieves the FF, it will send a FLOW CONTROL (FC) frame, which tells the ECU how the rest of the data transfer should be transmitted. 

 

Following this, the ECU will send Consecutive frames(CF) that contain the remaining data payload.

 

(1) tester request Single Frame UDS message

(2) ECU want to response with big size message 

(3) ECU response First frame (ff) → it means i will send big size message

(4) tester recognized First frame (ff) → then tester want to control big size message

(5) tester send FLOW CONTROL (FC) 

(6) ECU recognized FC and send consecutive frame (CF)

 

(for example)