ISO 14229-1:2026
(Main)Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer
Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer
This document specifies data link independent requirements of diagnostic communication services. These allow a diagnostic tester (client) to control diagnostic functions in an in-vehicle electronic control unit (ECU, server) such as an electronic fuel injection, automatic gearbox, anti-lock braking system, etc. connected to a serial data link embedded in a road vehicle. This document specifies diagnostic communication services, which allow the diagnostic tester (client) to stop or to resume non-diagnostic message transmission, to read vehicle identification data and real-time sensor data, read and clear diagnostic information, control actuators, start/stop routines, and many more functions to assist in diagnosing the vehicle's electronic systems. This document does not apply to non-diagnostic message transmission on the vehicle's communication data link between two electronic control units. This document does not restrict an in-vehicle on-board tester (client) implementation in an ECU/server in order to utilize the diagnostic communication services on the vehicle's communication data link to perform bidirectional diagnostic data exchange. This document does not specify any implementation requirements.
Véhicules routiers — Services de diagnostic unifiés (SDU) — Partie 1: Couche application
General Information
- Status
- Published
- Publication Date
- 04-Jun-2026
- Technical Committee
- ISO/TC 22/SC 31 - Data communication
- Drafting Committee
- ISO/TC 22/SC 31/WG 2 - Vehicle diagnostic protocols
- Current Stage
- 6060 - International Standard published
- Start Date
- 05-Jun-2026
- Due Date
- 09-Oct-2026
- Completion Date
- 05-Jun-2026
Relations
- Effective Date
- 28-Oct-2023
- Revises
ISO 14229-1:2020 - Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer - Effective Date
- 14-Oct-2023
Overview
ISO 14229-1:2026, published by the International Organization for Standardization (ISO), outlines the application layer requirements for Unified Diagnostic Services (UDS) used in road vehicles. The standard is data link independent, focusing on diagnostic communication between an external diagnostic tester (client) and an in-vehicle electronic control unit (ECU, server) across a serial data link. UDS enables reliable, bidirectional diagnostic and maintenance data exchange, essential for electronic system troubleshooting, maintenance, and updates in modern vehicles.
ISO 14229-1:2026 specifies the communication services that a tester can use to monitor, control, and manage the functions of various ECUs, such as those responsible for antilock braking systems, automatic transmissions, or engine management. This standard serves as the foundation for seamless vehicle diagnostics, facilitating advanced automotive service and repair activities.
Key Topics
- Diagnostic Communication Services: The standard defines application layer services for analyzing vehicle and ECU status, including reading identification and sensor data, retrieving or clearing diagnostic trouble codes (DTCs), and controlling actuators for functional tests.
- Data Link Independence: ISO 14229-1:2026 focuses strictly on the application layer, making the defined services usable with multiple physical and data link layers (e.g., CAN, FlexRay, Ethernet) in automotive networks.
- Service Organization: Specific services such as controlling diagnostic sessions (DiagnosticSessionControl), managing security (SecurityAccess), resetting ECUs (ECUReset), controlling network communications (CommunicationControl), managing authentication, and data reading or writing are detailed for robust and secure diagnostics.
- Bidirectional Capabilities: The protocol supports both requests from testers and confirmations or responses from ECUs, ensuring dynamic, interactive diagnostics.
- Functional Units: UDS application layer services are organized into functional units, including data transmission, stored data management, input/output control, routine control, and upload/download procedures.
Applications
ISO 14229-1:2026 is integral to numerous automotive diagnostic applications, enabling:
- Workshop Diagnostics: Efficient troubleshooting and maintenance by accessing sensor data, reading/writing memory, and controlling actuators in real time.
- On-board Diagnostics (OBD): Continuous vehicle condition monitoring, aiding emissions compliance, safety, and reliability through prompt DTC reporting and resolution.
- End-of-Line Testing: Automated testing of vehicle ECUs during the manufacturing process, ensuring correct configuration and functionality.
- Remote Diagnostics and Programming: OTA (Over-the-Air) updating or remote interrogation of ECUs, supporting connected vehicle strategies.
- Security and Authentication: Secure access to diagnostic and reprogramming functions via service authentication schemes.
By standardizing diagnostic communication, ISO 14229-1:2026 enhances interoperability among diagnostic tools and ECUs from multiple manufacturers, ensuring consistency in automotive repair and maintenance workflows.
Related Standards
Implementations of ISO 14229-1:2026 often reference or integrate with related automotive diagnostic and communication standards:
- ISO 14229 Series: Additional parts further detail UDS transport and physical layers.
- ISO 15765 Series: Road vehicles - Diagnostic communication over Controller Area Network (CAN).
- ISO 11898: Road vehicles - Controller area network (CAN) standards.
- ISO 27145 Series: Road vehicles - OBD communication.
- SAE J1979: EOBD/OBD-II communication protocols for diagnostic services.
These standards work together to deliver comprehensive, efficient, and secure automotive diagnostic solutions across the industry.
Summary
ISO 14229-1:2026 (Unified Diagnostic Services - Application Layer) is a cornerstone for data link independent automotive diagnostics, empowering effective electronic control unit monitoring, fault management, and service operations. Adoption of this standard strengthens interoperability, security, and performance in modern vehicle diagnostic communication systems.
Get Certified
Connect with accredited certification bodies for this standard
TÜV Rheinland
TÜV Rheinland is a leading international provider of technical services.
TÜV SÜD
TÜV SÜD is a trusted partner of choice for safety, security and sustainability solutions.
DEKRA Certification Inc.
DEKRA US certification services.
Sponsored listings
Frequently Asked Questions
ISO 14229-1:2026 is a standard published by the International Organization for Standardization (ISO). Its full title is "Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer". This standard covers: This document specifies data link independent requirements of diagnostic communication services. These allow a diagnostic tester (client) to control diagnostic functions in an in-vehicle electronic control unit (ECU, server) such as an electronic fuel injection, automatic gearbox, anti-lock braking system, etc. connected to a serial data link embedded in a road vehicle. This document specifies diagnostic communication services, which allow the diagnostic tester (client) to stop or to resume non-diagnostic message transmission, to read vehicle identification data and real-time sensor data, read and clear diagnostic information, control actuators, start/stop routines, and many more functions to assist in diagnosing the vehicle's electronic systems. This document does not apply to non-diagnostic message transmission on the vehicle's communication data link between two electronic control units. This document does not restrict an in-vehicle on-board tester (client) implementation in an ECU/server in order to utilize the diagnostic communication services on the vehicle's communication data link to perform bidirectional diagnostic data exchange. This document does not specify any implementation requirements.
This document specifies data link independent requirements of diagnostic communication services. These allow a diagnostic tester (client) to control diagnostic functions in an in-vehicle electronic control unit (ECU, server) such as an electronic fuel injection, automatic gearbox, anti-lock braking system, etc. connected to a serial data link embedded in a road vehicle. This document specifies diagnostic communication services, which allow the diagnostic tester (client) to stop or to resume non-diagnostic message transmission, to read vehicle identification data and real-time sensor data, read and clear diagnostic information, control actuators, start/stop routines, and many more functions to assist in diagnosing the vehicle's electronic systems. This document does not apply to non-diagnostic message transmission on the vehicle's communication data link between two electronic control units. This document does not restrict an in-vehicle on-board tester (client) implementation in an ECU/server in order to utilize the diagnostic communication services on the vehicle's communication data link to perform bidirectional diagnostic data exchange. This document does not specify any implementation requirements.
ISO 14229-1:2026 is classified under the following ICS (International Classification for Standards) categories: 43.180 - Diagnostic, maintenance and test equipment. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 14229-1:2026 has the following relationships with other standards: It is inter standard links to ISO 14229-1:2020/Amd 1:2022, ISO 14229-1:2020. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
ISO 14229-1:2026 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
International
Standard
ISO 14229-1
Fourth edition
Road vehicles — Unified diagnostic
2026-06
services (UDS) —
Part 1:
Application layer
Véhicules routiers — Services de diagnostic unifiés (SDU) —
Partie 1: Couche application
Reference number
© ISO 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .viii
Introduction .ix
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Symbols and abbreviated terms. 4
4.1 Symbols .4
4.2 Abbreviated terms .5
5 Conventions . 6
6 Application layer services . 6
6.1 General .6
6.2 Format description of application layer services .8
6.3 Format description of service primitives .8
6.3.1 General definition .8
6.3.2 Service request and service indication primitives .9
6.3.3 Service response and service confirm primitives .9
6.3.4 Service request-confirm and service response-confirm primitives .10
6.4 Service data unit specification .11
6.4.1 Mandatory parameters .11
6.4.2 Vehicle system requirements . 13
6.4.3 Optional parameters - A_AE, application layer remote address . 13
7 Application layer protocol . 14
7.1 General definition .14
7.2 A_PDU, application protocol data unit .14
7.3 A_PCI, application protocol control information .14
7.4 SID, service identifier. 15
7.5 A_NR_SID, Negative response service identifier .16
7.6 Negative response/confirmation service primitive .16
7.7 Server response implementation rules .16
7.7.1 General definitions .16
7.7.2 General server response behaviour .17
7.7.3 Request message with SubFunction parameter and server response behaviour .18
7.7.4 Request message without SubFunction parameter and server response
behaviour . 22
7.7.5 Pseudo code example of server response behaviour .24
7.7.6 Multiple concurrent request messages with physical and functional addressing . 25
8 Service description conventions .26
8.1 Service description . 26
8.2 Request message . 26
8.2.1 Request message definition . 26
8.2.2 Request message SubFunction parameter $Level (LEV_) definition .27
8.2.3 Request message data parameter definition . 29
8.3 Positive response message . 29
8.3.1 Positive response message definition . 29
8.3.2 Positive response message data parameter definition . 30
8.4 Supported negative response codes (NRC_) . 30
8.5 Message flow examples .31
9 Diagnostic and communication management functional unit .32
9.1 Overview .32
9.2 DiagnosticSessionControl (10 ) service .32
9.2.1 Service description .32
iii
9.2.2 Request message . 35
9.2.3 Positive response message .37
9.2.4 Supported negative response codes (NRC_) . 38
9.2.5 Message flow example(s) DiagnosticSessionControl – Start programmingSession . 38
9.3 ECUReset (11 ) service . 39
9.3.1 Service description . . 39
9.3.2 Request message . 39
9.3.3 Positive response message .41
9.3.4 Supported negative response codes (NRC_) .41
9.3.5 Message flow example ECUReset .42
9.4 SecurityAccess (27 ) service .42
9.4.1 Service description . .42
9.4.2 Request message . 44
9.4.3 Positive response message .45
9.4.4 Supported negative response codes (NRC_) . 46
9.4.5 Message flow example(s) SecurityAccess .47
9.5 CommunicationControl (28 ) service . 49
9.5.1 Service description . . 49
9.5.2 Request message . 49
9.5.3 Positive response message . 50
9.5.4 Supported negative response codes (NRC_) .51
9.5.5 Message flow example CommunicationControl (disable transmission of
network management messages) .51
9.5.6 Message flow example CommunicationControl (switch a remote network into
the diagnostic-only scheduling mode where the node with address 000A is
connected to) .52
9.5.7 Message flow example CommunicationControl (switch to application scheduling
mode with enhanced address information, the node 000A , which is connected
to a sub-network, is addressed) .52
9.6 Authentication (29 ) service . 53
9.6.1 Service overview . 53
9.6.2 Authentication with PKI Certificate Exchange (APCE) . 54
9.6.3 Authentication with Challenge-Response (ACR) .59
9.6.4 Common requirements . 63
9.6.5 Request message . 64
9.6.6 Positive response message .70
9.6.7 Supported negative response codes (NRC_) . 77
9.6.8 Message flow example(s) Authentication . 78
9.7 TesterPresent (3E ) service . 98
9.7.1 Service description . . 98
9.7.2 Request message . 99
9.7.3 Positive response message . 99
9.7.4 Supported negative response codes (NRC_) . 100
9.7.5 Message flow example(s) TesterPresent . 100
9.8 ControlDTCSetting (85 ) service . 101
9.8.1 Service description . 101
9.8.2 Request message . 101
9.8.3 Positive response message . 102
9.8.4 Supported negative response codes (NRC_) . 103
9.8.5 Message flow example(s) ControlDTCSetting . 103
9.9 ResponseOnEvent (86 ) service . 104
9.9.1 Service description . 104
9.9.2 Request message . 112
9.9.3 Positive response message . 118
9.9.4 Supported negative response codes (NRC_) . 121
9.9.5 Message flow example(s) ResponseOnEvent . 122
9.10 LinkControl (87 ) service . 136
9.10.1 Service description . . 136
9.10.2 Request message . 136
iv
9.10.3 Positive response message . 138
9.10.4 Supported negative response codes (NRC_) .138
9.10.5 Message flow example(s) LinkControl . 139
10 Data transmission functional unit .141
10.1 Overview .141
10.2 ReadDataByIdentifier (22 ) service .142
10.2.1 Service description . .142
10.2.2 Request message .142
10.2.3 Positive response message .143
10.2.4 Supported negative response codes (NRC_) . 144
10.2.5 Message flow example ReadDataByIdentifier . 146
10.3 ReadMemoryByAddress (23 ) service . 148
10.3.1 Service description . 148
10.3.2 Request message . 148
10.3.3 Positive response message . 149
10.3.4 Supported negative response codes (NRC_) . 150
10.3.5 Message flow example ReadMemoryByAddress. 151
10.4 ReadScalingDataByIdentifier (24 ) service . 153
10.4.1 Service description . 153
10.4.2 Request message .154
10.4.3 Positive response message .154
10.4.4 Supported negative response codes (NRC_) . 155
10.4.5 Message flow example ReadScalingDataByIdentifier . 157
10.5 ReadDataByPeriodicIdentifier (2A ) service . 160
10.5.1 Service description . . 160
10.5.2 Request message . 163
10.5.3 Positive response message . 163
10.5.4 Supported negative response codes (NRC_) . 164
10.5.5 Message flow example ReadDataByPeriodicIdentifier .167
10.6 DynamicallyDefineDataIdentifier (2C ) service . 177
10.6.1 Service description . . 177
10.6.2 Request message . 178
10.6.3 Positive response message . 182
10.6.4 Supported negative response codes (NRC_) . 182
10.6.5 Message flow examples DynamicallyDefineDataIdentifier . 183
10.7 WriteDataByIdentifier (2E ) service . 196
10.7.1 Service description . . 196
10.7.2 Request message . 196
10.7.3 Positive response message . 197
10.7.4 Supported negative response codes (NRC_) . 197
10.7.5 Message flow example WriteDataByIdentifier . 199
10.8 WriteMemoryByAddress (3D ) service .200
10.8.1 Service description . .200
10.8.2 Request message . 201
10.8.3 Positive response message . 202
10.8.4 Supported negative response codes (NRC_) . 203
10.8.5 Message flow example WriteMemoryByAddress .204
11 Stored data transmission functional unit .207
11.1 Overview . 207
11.2 ClearDiagnosticInformation (14 ) service . 207
11.2.1 Service description . . 207
11.2.2 Request message . 207
11.2.3 Positive response message .208
11.2.4 Supported negative response codes (NRC_) .208
11.2.5 Message flow example ClearDiagnosticInformation .210
11.3 ReadDTCInformation (19 ) service .210
11.3.1 Service description . .210
11.3.2 Request message . 221
v
11.3.3 Positive response message . 230
11.3.4 Supported negative response codes (NRC_) .246
11.3.5 Message flow examples – ReadDTCInformation.246
12 InputOutput control functional unit .275
12.1 Overview . 275
12.2 InputOutputControlByIdentifier (2F ) service . 275
12.2.1 Service description . . 275
12.2.2 Request message .276
12.2.3 Positive response message . 277
12.2.4 Supported negative response codes (NRC_) . 278
12.2.5 Message flow example(s) InputOutputControlByIdentifier . 279
13 Routine functional unit . 287
13.1 Overview .287
13.2 RoutineControl (31 ) service .288
13.2.1 Service description .288
13.2.2 Request message .289
13.2.3 Positive response message .290
13.2.4 Supported negative response codes (NRC_) . 291
13.2.5 Message flow example(s) RoutineControl .294
14 Upload download functional unit .297
14.1 Overview . 297
14.2 RequestDownload (34 ) service . 297
14.2.1 Service description . .297
14.2.2 Request message . 297
14.2.3 Positive response message .299
14.2.4 Supported negative response codes (NRC_) .299
14.2.5 Message flow example(s) RequestDownload . 301
14.3 RequestUpload (35 ) service . 301
14.3.1 Service description . . 301
14.3.2 Request message . 302
14.3.3 Positive response message . 303
14.3.4 Supported negative response codes (NRC_) .304
14.3.5 Message flow example(s) RequestUpload . 305
14.4 TransferData (36 ) service .306
14.4.1 Service description . .306
14.4.2 Request message .306
14.4.3 Positive response message . 307
14.4.4 Supported negative response codes (NRC_) .308
14.4.5 Message flow example(s) TransferData .310
14.5 RequestTransferExit (37 ) service . .310
14.5.1 Service description . .310
14.5.2 Request message . 311
14.5.3 Positive response message . 311
14.5.4 Supported negative response codes (NRC_) . 312
14.5.5 Message flow example(s) for downloading/uploading data . 313
14.6 RequestFileTransfer (38 ) service .319
14.6.1 Service description . .319
14.6.2 Request message . 320
14.6.3 Positive response message . 321
14.6.4 Supported negative response codes (NRC_) . 323
14.6.5 Message flow example(s) RequestFileTransfer . 325
15 Security sub-layer definition .327
15.1 General . 327
15.1.1 Purpose . 327
15.1.2 Security sub-layer description . 327
15.1.3 Security sub-layer access . . 328
15.1.4 General server response behaviour . 332
vi
15.2 SecuredDataTransmission (84 ) service .334
15.2.1 Service description . .334
15.2.2 Request message . 334
15.2.3 Positive response message for successful internal message . 336
15.2.4 Supported negative response codes (NRC_) . 338
15.2.5 Message flow example SecuredDataTransmission . 338
16 Non-volatile server memory programming process .341
16.1 General . 341
16.2 Programming phases . . 343
16.3 Detailed programming sequence .344
16.3.1 Programming phase #1 — Download of application software and/or application
data .344
16.4 Server reprogramming requirements . 353
16.4.1 Requirements for servers to support programming. 353
16.4.2 Software, data identification and fingerprints . 356
16.4.3 Server routine access . 357
16.5 Non-volatile server memory programming message flow examples . 357
16.5.1 General information . 357
16.5.2 Programming phase #1 — Pre-Programming step . 357
16.5.3 Programming phase #1 — Programming step . 358
16.5.4 Programming phase #1 — Post-Programming step . 362
Annex A (normative) Global parameter definitions . 363
Annex B (normative) Diagnostic and communication manageme
...