1. UDS overview
UDS (Unified Diagnostic Services) enables ECUs to monitor the operation of control system components, automatically record faults and execute diagnostic logic when faults are detected. A vehicle diagnostic module can store fault memory and provide real-time operating parameters. External diagnostic tools establish diagnostic communication with ECUs using defined diagnostic rules and read stored faults and parameters for analysis. UDS commonly follows ISO 15765 and ISO 14229 and is widely used on vehicle electronic control units (ECUs).
2. Basic principles of UDS
2.1 UDS protocol stack
The UDS protocol stack is mainly divided into two parts: the network layer and the application layer.
Network layer: addresses the difference in data length between the ISO 11898 classic CAN data link layer (maximum 8 bytes per frame) and the UDS application layer defined in ISO 14229, which can require up to 4095 bytes. For example, if the UDS application needs to send 20 bytes, CAN cannot carry it in a single frame and multiple frames are required. ISO 15765-2 defines how to transmit multi-byte data efficiently and in order over CAN. The network layer defines single-frame and multi-frame transmissions. A single frame (SF) contains the entire UDS payload within one CAN frame (up to 8 bytes). Multi-frame transmissions use First Frame (FF), Flow Control (FC), and Consecutive Frame (CF) to handle longer payloads. The network layer also defines timing parameters such as N_Ar, N_As, N_Br, N_Bs, N_Cr, and N_Cs; these will be discussed in detail below.
Application layer: the application layer protocol is typically request/response based, where each client request receives a corresponding server response.
2.2 Functional addressing and physical addressing
A diagnostic client (tester) sends diagnostic requests and the server (ECU) responds. The client can use functional addressing (one message addressed to all servers on the network, typically CAN ID 0x7DF), which is a one-to-many mode where all ECUs on the bus should respond to that message. Alternatively, the client can use physical addressing (point-to-point), addressing a single ECU in a one-to-one mode. Each ECU that supports UDS has both a functional CAN ID and a unique physical CAN ID; the vehicle-level convention usually sets the functional CAN ID to 0x7DF and assigns unique physical CAN IDs to each ECU.
3. Network layer overview
Network layer functions include:
- Forwarding application-layer diagnostic CAN frames;
- Packaging and unpackaging multi-frame data and coordinating with other layers;
4. Network layer protocol
Protocol control information (N_PCI) structure
The network layer classifies N_PDU into four types by the protocol control information (N_PCI): Single Frame (SF), First Frame (FF), Consecutive Frame (CF), and Flow Control (FC). For CAN diagnostics, the frame type is determined by the first byte of the CAN payload. The four types are described below.
Single Frame (SF)
A single frame contains the entire UDS service in one CAN frame. The first byte is the N_PCI byte. The high nibble indicates the frame type and the low nibble indicates the length of valid data in N_Data.
For example, if the first byte is 0x03, the high nibble 0 indicates single frame and the low nibble 3 indicates three valid data bytes. The remaining bytes are padding (e.g. 0x00).
First Frame (FF)
When N_Data is too long for a single frame, the sender splits the data into multiple N_PDU. The sender first transmits a First Frame to inform the receiver of the total data length.
In the First Frame, the high nibble of the first byte is 1 to indicate FF. The low nibble of byte 1 combined with byte 2 forms a 12-bit field representing the total N_Data length. For example, 0x10 0x18 indicates a total of 24 bytes to be sent.
Flow Control (FC)
Multi-frame UDS communication sequence:
- Sender sends the First Frame (FF) to the receiver.
- Receiver parses the First Frame.
- Based on its conditions (receive buffer size, processing capability, whether it can receive data now, etc.), the receiver replies with a Flow Control frame (FC).
- The sender decides subsequent actions based on the received FC.
When the first byte has high nibble 3, the frame is an FC. The low nibble of byte 1 is the Flow Status (FS): 0 means continue to send, 1 means wait, 2 means overflow (the FF_DL exceeds the receiver entity buffer size). Byte 2 is the Block Size (the number of consecutive CF frames allowed to be sent in one block). Byte 3 is STmin, the minimum separation time between consecutive CF frames.
Consecutive Frame (CF)
After the sender transmits the First Frame and receives an FC indicating it may proceed, the sender transmits Consecutive Frames according to the CF control information.
If the first byte has high nibble 2, the frame is a CF. The low nibble of byte 1 is the Sequence Number (SN). SN starts at 0 for the First Frame, and the first CF after an FC uses SN=1. Each successive CF increments SN by 1. SN is not affected by FC; when SN reaches 0x0F, it wraps to 0 on the next CF.
Timing parameters
The network layer defines six timing parameters: N_Ar, N_As, N_Br, N_Bs, N_Cr, and N_Cs.
Summarized timeouts:
- N_As timeout: sender did not transmit the next N_PDU in time.
- N_Ar timeout: receiver did not send the next N_PDU in time.
- N_Bs timeout: sender did not receive a Flow Control frame in time.
- N_Cr timeout: receiver did not receive a Consecutive Frame in time.
- N_Br timeout: receiver did not send a Flow Control frame in time.
- N_Cs: STmin, the minimum time to wait between sending two consecutive frames; N_Cr maximum is 1000 ms.
5. Addressing formats
Mapping the N_PDU into different positions in the CAN data field produces four addressing formats:
- Normal addressing (11-bit CAN ID)
- Normal fixed addressing (29-bit CAN ID)
- Extended addressing (11-bit CAN ID)
- Mixed addressing (11- or 29-bit CAN ID)
