UDS Protocol: Services, Message Flow and Diagnostics

Introduction

The UDS Protocol (Unified Diagnostic Services) is one of the most important communication protocols used in modern automotive Electronic Control Units (ECUs). It enables diagnostic testers, engineering tools and vehicle service equipment to communicate with ECUs for reading vehicle information, identifying faults, executing diagnostic routines, accessing protected functions and performing software programming.

Defined by the ISO 14229 series, the UDS Protocol provides a standardized application-layer diagnostic framework for automotive electronic systems. It is widely used in engine control units, transmission controllers, ABS, airbags, body control modules, battery management systems and other vehicle electronic systems.

For automotive embedded engineers, understanding UDS is essential when developing diagnostic software, implementing AUTOSAR Diagnostic Communication Manager (DCM), performing ECU validation, developing bootloaders or working with tools such as Vector CANoe and CANalyzer.

This comprehensive guide explains UDS architecture, diagnostic services, message formats, communication flow, negative response codes, CAN communication, DoIP and practical ECU diagnostic workflows.

1. What Is UDS Protocol?

UDS stands for Unified Diagnostic Services. It is an automotive diagnostic communication protocol standardized under ISO 14229.

The UDS Protocol follows a client-server communication model:

• Client: Diagnostic tester or external diagnostic equipment.
• Server: ECU that receives and processes diagnostic requests.

The diagnostic client sends a request, and the ECU processes it according to its supported services, operating conditions, security permissions and diagnostic configuration.

UDS supports several diagnostic operations:

• Reading ECU identification information.
• Reading sensor and internal ECU data.
• Reading and clearing Diagnostic Trouble Codes (DTCs).
• Executing diagnostic routines.
• Controlling ECU inputs and outputs.
• Changing diagnostic sessions.
• Managing diagnostic security and authentication.
• Downloading and uploading software.
• Supporting ECU reprogramming.

The application-layer services are independent of a particular vehicle communication medium. UDS can operate over different transport mechanisms, including CAN and Ethernet-based DoIP.

Important UDS standards

Standard	Purpose
ISO 14229-1:2026	UDS application-layer services
ISO 14229-2	UDS session-layer services
ISO 15765-2:2024	Diagnostic communication over CAN (DoCAN) transport and network layer
ISO 13400-2:2025	Diagnostic communication over Internet Protocol (DoIP)
AUTOSAR DCM	Diagnostic Communication Manager implementation in AUTOSAR

Always check the applicable standard edition and OEM requirements when developing an ECU diagnostic implementation.

2. Why Is UDS Used in Automotive Diagnostics?

Modern vehicles contain multiple interconnected ECUs. Each ECU performs specific functions and generates diagnostic information when an abnormal operating condition occurs.

The UDS Protocol provides a common diagnostic framework for communicating with these ECUs.

Its major advantages include:

Standardized diagnostics: Provides defined diagnostic services across different ECU platforms.

Fault identification: Allows diagnostic tools to retrieve DTCs and related diagnostic information.

ECU configuration: Supports reading and writing selected ECU parameters.

Security management: Provides mechanisms to restrict access to protected diagnostic functions.

Software programming: Supports diagnostic services required during ECU flashing.

Engineering validation: Enables automated testing, ECU verification and debugging.

Service diagnostics: Helps workshop technicians identify vehicle faults.

The exact services and permissions depend on the ECU implementation and vehicle manufacturer.

3. UDS Protocol Architecture

UDS uses a layered communication architecture. The application layer defines diagnostic services, while lower layers provide communication and data transfer mechanisms.

Simplified UDS architecture

       Diagnostic Tester
              |
              |
       UDS Client Application
              |
       UDS Application Layer
          ISO 14229-1
              |
       Session Layer
          ISO 14229-2
              |
       Transport / Network
          /          \
       CAN           Ethernet
       |                 |
    ISO-TP              DoIP
 ISO 15765-2        ISO 13400
       |                 |
       +--------+--------+
                |
             ECU Server
                |
        Diagnostic Software
                |
        AUTOSAR DCM / ECU

The main architectural components are:

Application layer: Defines diagnostic services, request parameters, response formats and negative response codes.

Session layer: Supports diagnostic communication sessions and associated session-level behavior.

Transport and network layers: Transfer diagnostic messages between the tester and ECU.

For example, UDS on CAN uses ISO-TP to transport diagnostic messages that cannot fit into a single CAN frame.

UDS over Ethernet uses DoIP for diagnostic communication through IP networks.

4. UDS Communication Model: Client and Server

The UDS Protocol follows a request-response communication model.

The diagnostic tester behaves as the client, while the ECU behaves as the server.

A typical communication sequence is:

1. The tester establishes communication with the target ECU.
2. The tester sends a diagnostic request.
3. The ECU receives and validates the request.
4. The ECU checks the active session and security permissions.
5. The ECU executes the requested operation.
6. The ECU sends a positive or negative response.
7. The tester interprets the response and continues diagnostics.

Unlike periodic CAN application signals, UDS communication consists of structured diagnostic transactions.

Example: Reading ECU identification

The tester sends:

22 F1 90

The ECU responds:

62 F1 90 [VIN DATA]

Here:

• 22 – ReadDataByIdentifier request.
• F1 90 – Data Identifier associated with the VIN.
• 62 – Positive response SID.
• [VIN DATA] – Returned vehicle identification data.

This example assumes the ECU supports the requested DID and permits access in the current diagnostic state.

5. UDS Message Format

Every UDS diagnostic application message begins with a Service Identifier (SID).

The SID identifies the requested diagnostic operation.

UDS request format

+-------------------+----------------------+------------+
| Service ID (SID)  | Service Parameters   |
+-------------------+----------------------+------------+

UDS positive response format

+-------------------+----------------------+----------------+
| Response SID      | Response Parameters  |
+-------------------+----------------------+----------------+

For most services, the positive response SID is calculated as:

Positive Response SID = Request SID + 0x40

Examples:

Request SID	Positive response SID
0x10	0x50
0x11	0x51
0x19	0x59
0x22	0x62
0x27	0x67
0x31	0x71

Some requests can suppress positive responses using the suppress-positive-response indication bit in applicable subfunctions.

UDS negative response format

When an ECU cannot execute a diagnostic request, it can return a negative response:

7F <Request SID> <NRC>

For example:

7F 22 31

This means:

• 7F – Negative Response SID.
• 22 – Original request service.
• 31 – Request Out Of Range.

6. Most Important UDS Diagnostic Services

The following services are commonly encountered in automotive ECU development, testing and diagnostics.

6.1 Diagnostic Session Control (0x10)

Diagnostic Session Control allows the tester to switch the ECU into a supported diagnostic session.

Common diagnostic sessions include:

Session	Subfunction
Default Session	0x01
Programming Session	0x02
Extended Diagnostic Session	0x03

The default session provides normal diagnostic functionality.

The extended session generally enables additional diagnostic operations.

The programming session is used for supported ECU programming activities.

Example request:

10 03

This requests Extended Diagnostic Session.

Positive response:

50 03 [P2 SERVER] [P2* SERVER]

The response can include server timing parameters used by the tester to manage response timeouts.

Practical application: Before performing protected configuration operations or certain diagnostic routines, the tester may need to enter the appropriate diagnostic session.

6.2 ECU Reset (0x11)

ECU Reset requests a controlled ECU reset.

Common reset types include:

• Hard Reset (0x01).
• Key Off On Reset (0x02).
• Soft Reset (0x03).

The supported reset types depend on the ECU.

Example:

11 01

This requests a Hard Reset.

Positive response SID:

51

The ECU may reset after sending the response, depending on its implementation.

Practical application: ECU reset is commonly used after programming, configuration changes or diagnostic operations that require software reinitialization.

6.3 Security Access (0x27)

SecurityAccess provides a seed-and-key mechanism for controlling access to protected diagnostic functions.

Typical sequence:

1. Tester requests a security seed.
2. ECU generates and returns the seed.
3. Tester calculates the corresponding key using the authorized OEM algorithm.
4. Tester sends the key.
5. ECU verifies the key.
6. If successful, the requested security level becomes accessible.

Example sequence:

Tester -> ECU: 27 01
ECU -> Tester: 67 01 [SEED]

Tester -> ECU: 27 02 [KEY]
ECU -> Tester: 67 02

The subfunction pairing and security algorithm depend on the ECU specification.

SecurityAccess is commonly used to protect:

• ECU programming.
• Calibration changes.
• Configuration writing.
• Protected routines.

Never implement unauthorized seed-key extraction or brute-force attempts. Follow OEM security requirements.

6.4 Tester Present (0x3E)

Tester Present keeps a diagnostic session active when the tester needs to communicate with an ECU over an extended period.

ECUs may automatically return to the default session after the configured S3 session timeout.

Example request:

3E 00

Positive response:

7E 00

Another commonly used request is:

3E 80

This requests suppression of the positive response.

Practical application: Tester Present is important during long diagnostic routines and ECU programming workflows.

6.5 Read Data By Identifier (0x22)

ReadDataByIdentifier reads ECU information using a Data Identifier (DID).

Examples include:

• Vehicle Identification Number.
• ECU part number.
• Software version.
• Hardware identification.
• Calibration information.
• Selected internal measurement values.

Example:

22 F1 90

Positive response:

62 F1 90 [VIN DATA]

The DID identifies the requested data element.

Not every DID is available in every ECU. OEM-specific and supplier-specific DIDs are also common.

6.6 Write Data By Identifier (0x2E)

WriteDataByIdentifier writes data associated with a supported DID.

Example:

2E [DID HIGH] [DID LOW] [DATA]

Positive response:

6E [DID HIGH] [DID LOW]

Possible applications include:

• Variant coding.
• ECU configuration.
• Supported calibration parameters.
• Selected identification data.

The ECU may require a specific session, security authorization and operating conditions before allowing a write operation.

6.7 Read DTC Information (0x19)

ReadDTCInformation retrieves diagnostic trouble code information stored in the ECU.

It can support operations such as:

• Reading DTCs by status mask.
• Reading the number of DTCs.
• Reading DTC status information.
• Retrieving snapshot records.
• Retrieving extended diagnostic records.

Example:

19 02 FF

This is a commonly used request for reporting DTCs by status mask.

Positive response SID:

59

DTC information helps engineers identify abnormal operating conditions and investigate faults.

6.8 Clear Diagnostic Information (0x14)

ClearDiagnosticInformation requests deletion of supported diagnostic information.

Example:

14 FF FF FF

The three-byte group identifies the requested DTC group.

Positive response:

54

Important: Clearing a DTC does not repair the underlying fault. If the fault condition remains, the ECU may detect it again.

6.9 Routine Control (0x31)

RoutineControl executes predefined diagnostic routines inside an ECU.

The three main control types are:

Subfunction	Operation
0x01	Start Routine
0x02	Stop Routine
0x03	Request Routine Results

A Routine Identifier (RID) identifies the routine.

Typical applications:

• Actuator testing.
• Self-diagnostic routines.
• Memory checks.
• Calibration procedures.
• Flash memory erase preparation.

Example request structure:

31 01 [RID HIGH] [RID LOW]

Positive response:

71 01 [RID HIGH] [RID LOW] [RESULT]

The supported routines and their parameters are defined by the ECU implementation.

6.10 Control DTC Setting (0x85)

ControlDTCSetting allows the tester to request enabling or disabling supported DTC setting behavior.

Common subfunctions:

• 0x01 – On.
• 0x02 – Off.

Example:

85 02

This requests disabling DTC setting.

This service is used in selected OEM testing and programming workflows. Its availability and restrictions depend on the ECU.

6.11 Authentication (0x29)

Authentication provides a mechanism for the diagnostic client to prove its identity to the ECU.

It is particularly relevant to modern vehicle cybersecurity architectures.

Depending on implementation, it can support:

• Certificate verification.
• Challenge-based authentication.
• Proof of ownership.
• Authentication configuration.
• Deauthentication.

Unlike the traditional seed-key mechanism of service 0x27, Authentication can use certificate-based mechanisms and identity-related access control.

It is important to understand both services when developing modern secure diagnostic systems.

6.12 ECU Programming Services

UDS also provides services used during ECU software download and programming.

Important services include:

SID	Service	Purpose
0x34	RequestDownload	Initiates a download
0x36	TransferData	Transfers data blocks
0x37	RequestTransferExit	Completes the transfer sequence

A typical programming workflow involves entering programming session, obtaining required authorization, preparing memory, initiating download, transferring data, completing the transfer and verifying the programmed software.

The actual workflow is OEM- and bootloader-dependent.

7. Positive and Negative Response Codes

The ECU can respond positively when a request is accepted and processed.

If a request cannot be completed, the ECU can return a Negative Response Code (NRC).

Common UDS NRC values

NRC	Meaning
0x10	General Reject
0x11	Service Not Supported
0x12	Subfunction Not Supported
0x13	Incorrect Message Length or Invalid Format
0x21	Busy Repeat Request
0x22	Conditions Not Correct
0x24	Request Sequence Error
0x31	Request Out Of Range
0x33	Security Access Denied
0x35	Invalid Key
0x36	Exceeded Number Of Attempts
0x37	Required Time Delay Not Expired
0x78	Response Pending
0x7E	Subfunction Not Supported In Active Session
0x7F	Service Not Supported In Active Session

Understanding NRC 0x78

NRC 0x78 is particularly important during ECU programming and long-running diagnostic routines.

Example:

Tester -> ECU: 31 01 [RID]
ECU -> Tester: 7F 31 78

This means the ECU received the request correctly but has not completed the requested operation.

The tester must wait according to the applicable diagnostic timing rules. The ECU subsequently sends the final positive or negative response.

The tester should not treat 0x78 as a completed transaction or immediately send an unrelated request.

8. UDS Addressing: Physical vs Functional

UDS supports two important addressing approaches.

Physical addressing

Physical addressing communicates with one specific ECU.

Applications include:

• Reading ECU data.
• Writing configuration.
• Security access.
• ECU programming.
• Executing diagnostic routines.

Functional addressing

Functional addressing sends a diagnostic request to a group of ECUs.

It is commonly used for supported discovery or vehicle-wide diagnostic requests.

However, not every UDS service supports functional addressing, and response behavior depends on the service and network implementation.

Feature	Physical	Functional
Communication	One specific ECU	Multiple eligible ECUs
Addressing	Individual	Group
Common usage	ECU-specific diagnostics	Supported group requests
Programming	Normally used	Generally unsuitable

9. UDS Over CAN vs UDS Over DoIP

The UDS application-layer services can operate over different transport technologies.

UDS over CAN (DoCAN)

UDS over CAN uses ISO 15765-2 for transport and network-layer communication.

Important characteristics:

• Uses CAN communication.
• Supports diagnostic messages through ISO-TP.
• Uses Single Frames, First Frames, Consecutive Frames and Flow Control Frames.
• Supports multi-frame diagnostic messages.
• Can operate with Classical CAN or CAN FD according to the implementation.

Classical CAN carries up to 8 data bytes per frame, whereas CAN FD supports larger data fields up to 64 bytes.

ISO-TP handles segmentation and reassembly when diagnostic data exceeds the capacity of an individual CAN frame.

UDS over DoIP

DoIP means Diagnostic Communication over Internet Protocol.

It uses automotive Ethernet and IP networking.

Important characteristics:

• Uses IP networking.
• Uses UDP for vehicle discovery and certain communication functions.
• Uses TCP for diagnostic communication.
• Supports communication through vehicle gateways.
• Provides higher available bandwidth than conventional Classical CAN.

DoIP is particularly useful for modern vehicle architectures, advanced ECUs and software programming.

Comparison

Feature	UDS over CAN	UDS over DoIP
Main standard	ISO 15765-2	ISO 13400
Network	CAN	Ethernet/IP
Transport	ISO-TP	TCP/IP and UDP/IP functions
Bandwidth	Lower	Higher
Multi-frame handling	ISO-TP	DoIP transport mechanisms
Typical application	Traditional ECU diagnostics	Modern vehicle diagnostics and programming

The diagnostic service definitions remain largely consistent, but addressing, framing, transport handling and timing differ.

10. Practical UDS Diagnostic Workflow

Consider a diagnostic engineer investigating a fault in an engine control unit.

A typical diagnostic sequence is:

Step 1: Establish ECU communication

The tester establishes communication with the target ECU using the configured diagnostic addressing.

Step 2: Enter extended diagnostic session

10 03

The ECU may respond:

50 03 [TIMING PARAMETERS]

Step 3: Read ECU identification

22 F1 90

The tester retrieves the VIN if supported.

Step 4: Read diagnostic trouble codes

19 02 FF

The tester retrieves the supported DTC information.

Step 5: Investigate fault details

The tester requests applicable snapshot and extended diagnostic records.

Step 6: Perform authorized diagnostic operations

If required, the tester performs security authorization and executes supported routines.

Step 7: Clear DTCs when appropriate

14 FF FF FF

This is done only after the fault has been investigated and corrective action has been performed.

Step 8: Verify ECU behavior

The tester reads diagnostic information again and verifies that the fault condition has been resolved.

During longer operations, Tester Present may be required to maintain the diagnostic session.

11. UDS Testing and Implementation Best Practices

Automotive embedded engineers should consider the following practices when developing UDS clients and ECU diagnostic servers.

1. Implement correct request and response parsing.
2. Validate SID, subfunction, DID, RID and message length.
3. Handle all applicable negative response codes.
4. Implement P2 and P2* response timing correctly.
5. Manage S3 session timeout and Tester Present.
6. Validate physical and functional addressing.
7. Implement security access and authentication according to OEM requirements.
8. Maintain consistent DID and RID configuration.
9. Log requests, responses, timestamps and ECU addresses.
10. Test positive responses, negative responses, timeout conditions and communication failures.
11. Verify diagnostic behavior across ECU operating states.
12. Validate programming and recovery procedures before production use.

Common UDS troubleshooting scenarios

Problem	Possible cause	Investigation
NRC 0x11	Service unsupported	Check ECU diagnostic specification
NRC 0x22	Operating conditions not satisfied	Check ECU state and prerequisites
NRC 0x31	DID or RID unsupported	Verify identifier and parameters
NRC 0x33	Security authorization missing	Check security level
NRC 0x35	Incorrect security key	Verify authorized algorithm and key handling
NRC 0x78	ECU processing not completed	Follow P2* timing
No response	Addressing, transport or ECU communication issue	Check CAN/DoIP configuration and network logs

12. Role of UDS in AUTOSAR ECU Development

UDS is closely connected with AUTOSAR diagnostic architecture.

In AUTOSAR Classic Platform, the Diagnostic Communication Manager (DCM) handles diagnostic communication and service processing.

Important diagnostic components include:

• DCM – Diagnostic Communication Manager.
• DEM – Diagnostic Event Manager.
• PduR – PDU Router.
• CanTp – CAN Transport Protocol.
• CanIf – CAN Interface.
• SoAd – Socket Adaptor, in applicable Ethernet communication architectures.
• DoIP – Diagnostic communication over IP implementation.

DCM processes diagnostic requests and coordinates the relevant diagnostic functionality.

DEM manages diagnostic events, DTC status and associated diagnostic data.

This architecture is important when developing production automotive ECU diagnostic software.

13. Applications of UDS Protocol in the Automotive Industry

The UDS Protocol is used across multiple automotive engineering activities.

ECU development: Validating diagnostic functions during ECU development.

Vehicle servicing: Reading and clearing fault codes.

ECU flashing: Supporting bootloader-based software programming.

Automotive testing: Executing diagnostic test cases using CANoe, CANalyzer and automated test environments.

Manufacturing: Performing end-of-line diagnostics and configuration.

Vehicle cybersecurity: Controlling access to protected diagnostic functionality.

Vehicle maintenance: Retrieving diagnostic information for fault investigation.

Understanding UDS is therefore valuable for embedded software developers, diagnostic engineers, validation engineers and automotive test engineers.

Conclusion

The UDS Protocol is a fundamental part of modern automotive ECU diagnostics. Based on the ISO 14229 framework, it provides standardized diagnostic services for reading ECU information, identifying faults, controlling diagnostic operations, managing security and supporting software programming.

Understanding important services such as Diagnostic Session Control (0x10), ECU Reset (0x11), SecurityAccess (0x27), ReadDataByIdentifier (0x22), ReadDTCInformation (0x19), RoutineControl (0x31) and Authentication (0x29) provides a strong foundation for automotive diagnostic engineering.

Engineers should also understand ISO-TP, DoIP, diagnostic addressing, response timing and negative response handling to implement reliable diagnostic systems.

Whether you are developing an AUTOSAR ECU, implementing an ECU bootloader, building diagnostic tools or performing automotive validation, UDS is an essential technical skill.

Strengthen your automotive embedded systems knowledge with practical learning in UDS diagnostics, AUTOSAR, ECU bootloader development and automotive testing through relevant Piest Systems training programs.

Frequently Asked Questions (FAQs)