UDS Protocol Basics: Services, Message Flow & Diagnostics (ISO 14229)

UDS diagnostic message flow showing tester, ECU, request and response services

INTRODUCTION

UDS (Unified Diagnostic Services) is the standard diagnostic protocol used by modern vehicles to communicate with ECUs for fault diagnosis, configuration, programming, and validation. If you are learning automotive embedded systems, ECU testing, or diagnostics tools like CANoe/CANalyzer, understanding UDS is a must.

This guide explains UDS in a simple, practical way: how messages flow between a tester and an ECU, what the key services do, and how diagnostics actually work in real vehicle networks.

What Is UDS Protocol?

UDS stands for Unified Diagnostic Services, standardized as ISO 14229. It defines how a diagnostic tester (client) communicates with an ECU (server) to perform operations like:

  • Reading ECU identification and sensor data
  • Reading and clearing DTCs (Diagnostic Trouble Codes)
  • Running routines (actuator tests, calibration, self-tests)
  • Security unlocking for protected operations
  • ECU programming support (often used with flashing workflows)

UDS can run on multiple transports, most commonly:

  • UDS on CAN (DoCAN) using ISO 15765-2 (CAN TP)
  • UDS on IP (DoIP) using ISO 13400

Why UDS Is Used in Automotive Diagnostics

UDS provides:

  • Standardized diagnostic operations across ECUs
  • Clear request/response rules
  • Built-in error reporting (Negative Response Codes)
  • Secure access for critical functions
  • Session-based control (default, extended, programming)

This makes UDS suitable for both service workshops and OEM engineering tools.

UDS Communication Model: Tester and ECU

UDS follows a client-server model:

  • Tester sends a request to the ECU (client behavior)
  • ECU processes and responds (server behavior)

UDS is not “broadcast data streaming” like typical CAN signals. It is a structured diagnostic conversation.

UDS Message Flow Explained (Step-by-Step)

A typical UDS flow looks like this:

  • Tester selects the ECU address (physical or functional addressing)
  • Tester requests a diagnostic session (if needed)
  • Tester may request security access (if required)
  • Tester reads data, runs routines, clears DTCs, writes parameters
  • ECU responds with positive response data or negative response codes
  • Tester maintains session using keep-alive messages if needed

UDS Request and Response Format

Service ID (SID)

Each UDS service is identified by a Service ID (1 byte).

  • Request SID: for example 0x10 (Diagnostic Session Control)
  • Positive response SID: request SID + 0x40
    • Example: request 0x10 → positive response 0x50

Example

Tester sends:

  • 10 03 (request programming session)

ECU responds:

  • 50 03 ... (positive response with timing parameters)

Most Important UDS Services for Beginners

Below are the core services that appear in almost every real diagnostic project.

1) Diagnostic Session Control (0x10)

Used to switch ECU into different diagnostic modes.

Common sessions:

  • Default Session (0x01)
  • Programming Session (0x02)
  • Extended Diagnostic Session (0x03)

Why it matters:

  • Many operations are allowed only in a specific session.

Typical request:

  • 10 03 (switch to extended session)

2) ECU Reset (0x11)

Used to reset the ECU in a controlled way.

Common reset types:

  1. Hard reset
  2. Key-off/on reset
  3. Soft reset

Practical use:

  • After coding changes, after programming steps, after configuration write.

3) Security Access (0x27)

Unlocks protected functions (writing data, routines, programming).

How it works:

  • Tester requests a seed
  • ECU returns seed
  • Tester computes key (using OEM algorithm)
  • Tester sends key
  • ECU unlocks if key matches

Important concept:

  • Without security unlock, ECU returns negative responses for protected services.

4) Tester Present (0x3E)

Keeps the session alive.

Why it matters:

  • ECUs can time out and revert to default session if the tester stays silent.
  • Tester Present prevents session timeout during long diagnostics or flashing.

5) Read Data By Identifier (0x22)

Reads ECU data identified by a DID (Data Identifier).

Examples:

  • VIN
  • ECU part number
  • Software version
  • Calibration ID
  • Sensor snapshot values (implementation-specific)

Typical request:

  • 22 F1 90 (example DID for VIN in many stacks)

Response:

  • 62 F1 90 ...data...

6) Write Data By Identifier (0x2E)

Writes configuration/calibration parameters to ECU.

Usually requires:

  • Extended session or programming session
  • Security access

Response:

  • 6E ... (positive response)

Practical example:

  • Writing variant coding, feature enable flags, calibration values.

7) Read DTC Information (0x19)

Reads Diagnostic Trouble Codes.

Capabilities include:

    • Read number of DTCs
    • Read DTCs by status mask
    • Read snapshot data
    • Read extended data

    Practical use:

    • Workshop fault scanning
    • Engineering debugging and warranty analysis

    8) Clear Diagnostic Information (0x14)

    Clears stored DTCs (and sometimes related freeze-frame / extended info).

    Important note:

    • Clearing DTCs does not fix the root issue; it resets the diagnostic memory.

    9) Routine Control (0x31)

    Runs specific routines inside the ECU.

    Routine examples:

    • Actuator test
    • Calibration routine
    • Self-test routine
    • Memory check
    • Erase/program preparation steps (often used in flashing)

    Routine Control types:

    • Start routine
    • Stop routine
    • Request routine results

    10) Control DTC Setting (0x85)

    Enables or disables DTC logging (used in some OEM workflows).

    Use case:

    • During special tests or programming, DTC logging might be paused to avoid false faults.

    Positive Response vs Negative Response

    Positive Response

    ECU accepted the request and returned data or confirmation.

    Rule:

    • Positive response SID = Request SID + 0x40

    Example:

    • 22 → 62
    • 10 → 50

    Negative Response (NRC)

    If ECU cannot perform the request, it returns:

    • 7F <RequestSID> <NRC>

    Example:

    • 7F 22 31

    Meaning: Request for service 0x22 failed with NRC 0x31.

    Common Negative Response Codes (NRC) and What They Mean

    These are the ones you see often in real testing:

    • 0x10 General reject
    • 0x11 Service not supported
    • 0x12 Sub-function not supported
    • 0x13 Incorrect message length or invalid format
    • 0x22 Conditions not correct (ECU not ready, wrong state)
    • 0x31 Request out of range (DID/RID not supported)
    • 0x33 Security access denied
    • 0x35 Invalid key
    • 0x36 Exceeded number of attempts
    • 0x37 Required time delay not expired
    • 0x78 Response pending (ECU needs more time)

    Practical note:

    • NRC 0x78 is common when a routine takes time. The tester must wait and continue receiving the final response.

    UDS Addressing: Physical vs Functional

    • Physical addressing: talk to one specific ECU (most operations)
    • Functional addressing: broadcast request to multiple ECUs (common for “who is there” type requests)

    Many write/program operations are typically physical only.

    UDS Over CAN vs UDS Over DoIP

    UDS on CAN (DoCAN)

    • Uses CAN frames (8 bytes in classical CAN)
    • Uses ISO-TP (ISO 15765-2) for multi-frame messages

    UDS on DoIP

    • Uses TCP/IP over Ethernet
    • Higher bandwidth, used in modern architectures (especially for programming and ADAS ECUs)

    Both use the same UDS services. Only the transport changes.

    Real Diagnostic Example Workflow (Workshop Style)

    A common scan tool sequence:

    1. Diagnostic Session Control (0x10) to enter extended session
    2. Read ECU Identification using ReadDataByIdentifier (0x22)
    3. Read DTCs using ReadDTCInformation (0x19)
    4. Read snapshot/extended data if needed
    5. Clear DTCs using ClearDiagnosticInformation (0x14)
    6. Tester Present (0x3E) periodically during long operations

    Best Practices for UDS Testing

    • Always handle negative responses and timeouts
    • Implement proper session management (tester present)
    • Use clear logging: request, response, timestamp, ECU address
    • Validate security access carefully (avoid brute-force behavior)
    • Use consistent DID/RID configuration tables in ECU software

    Conclusion

    UDS (ISO 14229) is the foundation of modern automotive diagnostics. Once you understand how UDS services work, how message flow is structured, and how negative response codes guide debugging, you can confidently move into advanced areas like ECU flashing, DoIP integration, AUTOSAR diagnostics, and automated test scripting. For anyone building an ECU testing tool or working with automotive ECUs, UDS is a core skill that directly impacts real industry projects.

    FAQs

    Exit mobile version