>>
<<
ISO 14229-1:2020(en)
ISO - Cover page
Foreword
Introduction
1 Scope
2 Normative references
3 Terms and definitions
4 Symbols and abbreviated terms
5 Conventions
6 Document overview
7 Application layer services
 7.1 General
 7.2 Format description of application layer services
 7.3 Format description of service primitives
  7.3.1 General definition
  7.3.2 Service request and service indication primitives
  7.3.3 Service response and service confirm primitives
  7.3.4 Service request-confirm and service response-confirm primitives
 7.4 Service data unit specification
  7.4.1 Mandatory parameters
  7.4.2 Vehicle system requirements
  7.4.3 Optional parameters - A_AE, application layer remote address
8 Application layer protocol
 8.1 General definition
 8.2 A_PDU, application protocol data unit
 8.3 A_PCI, application protocol control information
 8.4 SI, service identifier
 8.5 A_NR_SI, Negative response service identifier
 8.6 Negative response/confirmation service primitive
 8.7 Server response implementation rules
  8.7.1 General definitions
  8.7.2 General server response behaviour
  8.7.3 Request message with SubFunction parameter and server response behaviour
  8.7.4 Request message without SubFunction parameter and server response behaviour
  8.7.5 Pseudo code example of server response behaviour
  8.7.6 Multiple concurrent request messages with physical and functional addressing
9 Service description conventions
 9.1 Service description
 9.2 Request message
  9.2.1 Request message definition
  9.2.2 Request message SubFunction parameter $Level (LEV_) definition
  9.2.3 Request message data-parameter definition
 9.3 Positive response message
  9.3.1 Positive response message definition
  9.3.2 Positive response message data-parameter definition
 9.4 Supported negative response codes (NRC_)
 9.5 Message flow examples
10 Diagnostic and communication management functional unit
 10.1 Overview
 10.2 DiagnosticSessionControl (1016) service
  10.2.1 Service description
  10.2.2 Request message
  10.2.3 Positive response message
  10.2.4 Supported negative response codes (NRC_)
  10.2.5 Message flow example(s) DiagnosticSessionControl – Start programmingSession
 10.3 ECUReset (1116) service
  10.3.1 Service description
  10.3.2 Request message
  10.3.3 Positive response message
  10.3.4 Supported negative response codes (NRC_)
  10.3.5 Message flow example ECUReset
 10.4 SecurityAccess (2716) service
  10.4.1 Service description
  10.4.2 Request message
  10.4.3 Positive response message
  10.4.4 Supported negative response codes (NRC_)
  10.4.5 Message flow example(s) SecurityAccess
 10.5 CommunicationControl (2816) service
  10.5.1 Service description
  10.5.2 Request message
  10.5.3 Positive response message
  10.5.4 Supported negative response codes (NRC_)
  10.5.5 Message flow example CommunicationControl (disable transmission of network management messages)
  10.5.6 Message flow example CommunicationControl (switch a remote network into the diagnostic-only scheduling mode where the node with address 000A16 is connected to)
  10.5.7 Message flow example CommunicationControl (switch to application scheduling mode with enhanced address information, the node 000A16, which is connected to a sub-network, is addressed)
 10.6 Authentication (2916) service
  10.6.1 Service overview
  10.6.2 Authentication with PKI Certificate Exchange (APCE)
  10.6.3 Authentication with Challenge-Response (ACR)
  10.6.4 Common requirements
  10.6.5 Request message
  10.6.6 Positive response message
  10.6.7 Supported negative response codes (NRC_)
  10.6.8 Message flow example(s) Authentication
 10.7 TesterPresent (3E16) service
  10.7.1 Service description
  10.7.2 Request message
  10.7.3 Positive response message
  10.7.4 Supported negative response codes (NRC_)
  10.7.5 Message flow example(s) TesterPresent
 10.8 ControlDTCSetting (8516) service
  10.8.1 Service description
  10.8.2 Request message
  10.8.3 Positive response message
  10.8.4 Supported negative response codes (NRC_)
  10.8.5 Message flow example(s) ControlDTCSetting
 10.9 ResponseOnEvent (8616) service
  10.9.1 Service description
  10.9.2 Request message
  10.9.3 Positive response message
  10.9.4 Supported negative response codes (NRC_)
  10.9.5 Message flow example(s) ResponseOnEvent
 10.10 LinkControl (8716) service
  10.10.1 Service description
  10.10.2 Request message
  10.10.3 Positive response message
  10.10.4 Supported negative response codes (NRC_)
  10.10.5 Message flow example(s) LinkControl
11 Data transmission functional unit
 11.1 Overview
 11.2 ReadDataByIdentifier (2216) service
  11.2.1 Service description
  11.2.2 Request message
  11.2.3 Positive response message
  11.2.4 Supported negative response codes (NRC_)
  11.2.5 Message flow example ReadDataByIdentifier
 11.3 ReadMemoryByAddress (2316) service
  11.3.1 Service description
  11.3.2 Request message
  11.3.3 Positive response message
  11.3.4 Supported negative response codes (NRC_)
  11.3.5 Message flow example ReadMemoryByAddress
 11.4 ReadScalingDataByIdentifier (2416) service
  11.4.1 Service description
  11.4.2 Request message
  11.4.3 Positive response message
  11.4.4 Supported negative response codes (NRC_)
  11.4.5 Message flow example ReadScalingDataByIdentifier
 11.5 ReadDataByPeriodicIdentifier (2A16) service
  11.5.1 Service description
  11.5.2 Request message
  11.5.3 Positive response message
  11.5.4 Supported negative response codes (NRC_)
  11.5.5 Message flow example ReadDataByPeriodicIdentifier
 11.6 DynamicallyDefineDataIdentifier (2C16) service
  11.6.1 Service description
  11.6.2 Request message
  11.6.3 Positive response message
  11.6.4 Supported negative response codes (NRC_)
  11.6.5 Message flow examples DynamicallyDefineDataIdentifier
 11.7 WriteDataByIdentifier (2E16) service
  11.7.1 Service description
  11.7.2 Request message
  11.7.3 Positive response message
  11.7.4 Supported negative response codes (NRC_)
  11.7.5 Message flow example WriteDataByIdentifier
 11.8 WriteMemoryByAddress (3D16) service
  11.8.1 Service description
  11.8.2 Request message
  11.8.3 Positive response message
  11.8.4 Supported negative response codes (NRC_)
  11.8.5 Message flow example WriteMemoryByAddress
12 Stored data transmission functional unit
 12.1 Overview
 12.2 ClearDiagnosticInformation (1416) service
  12.2.1 Service description
  12.2.2 Request message
  12.2.3 Positive response message
  12.2.4 Supported negative response codes (NRC_)
  12.2.5 Message flow example ClearDiagnosticInformation
 12.3 ReadDTCInformation (1916) service
  12.3.1 Service description
  12.3.2 Request message
  12.3.3 Positive response message
  12.3.4 Supported negative response codes (NRC_)
  12.3.5 Message flow examples – ReadDTCInformation
 13 InputOutput control functional unit
  13.1 Overview
  13.2 InputOutputControlByIdentifier (2F16) service
 14 Routine functional unit
  14.1 Overview
  14.2 RoutineControl (3116) service
  15 Upload download functional unit
  16 Security sub-layer definition
  17 Non-volatile server memory programming process
Annex A (normative) Global parameter definitions
Annex B (normative) Diagnostic and communication management functional unit data-parameter definitions
Annex C (normative) Data transmission functional unit data-parameter definitions
Annex D (normative) Stored data transmission functional unit data-parameter definitions
Annex E (normative) Input output control functional unit data-parameter definitions
Annex F (normative) Routine functional unit data-parameter definitions
Annex G (normative) Upload and download functional unit data-parameter
Annex H (informative) Examples for addressAndLengthFormatIdentifier parameter values
Annex I (normative) Security access state chart
Annex J (informative) Recommended implementation for multiple client environments
Bibliography

International

Standard

ISO 14229-1
Road vehicles — Unified diagnostic services (UDS) —
Part 1:
Application layer
Véhicules routiers — Services de diagnostic unifiés (SDU) —
Partie 1: Couche application
Reference number
ISO 14229-1:2020(en)
Third edition
2020-02

Contents Page

Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be in the Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO's adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31, Data communication.
This third edition cancels and replaces the second edition (ISO 14229-1:2013), which has been technically revised. The main changes compared to the previous edition are as follows:
—
new diagnostic service for Authentication has been introduced to address cyber security topics;
—
new clause "Security sub-layer definition";
—
some unused SubFunction of ReadDTCInformation service are deleted, e.g. Mirror Memory;
—
the ReadDataByPeriodicIdentifier is updated; and
—
several clarifications and corrections are implemented.
A list of all parts in the ISO 14229 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A complete listing of these bodies can be found at www.iso.org/members.html.

Introduction

ISO 14229 has been established in order to define common requirements for diagnostic systems, whatever the serial data link is.
To achieve this, ISO 14229 is based on the Open Systems Interconnection (OSI) Basic Reference Model in accordance with ISO/IEC 7498-1 and ISO/IEC 10731, which structures communication systems into seven layers. When mapped on this model, the services used by a diagnostic tester (client) and an Electronic Control Unit (ECU, server) are broken into the following layers in accordance with Table 1:
—
Application layer (layer 7), unified diagnostic services specified in this document, ISO 14229-3 UDSonCAN, ISO 14229-4 UDSonFR, ISO 14229-5 UDSonIP, ISO 14229-6 UDSonK-Line, ISO 14229-7 UDSonLIN, ISO 14229-81
1 Under preparation. Stage at the time of publication: ISO/FDIS 14229-8:2020.
UDSonCXPI, further standards and ISO 27145-3 VOBD.
—
Presentation layer (layer 6), vehicle manufacturer specific, ISO°27145-2 VOBD.
—
Session layer services (layer 5) specified in ISO 14229-2.
—
Transport layer services (layer 4), specified in ISO 15765-2 DoCAN, ISO 10681-2 Communication on FlexRay, ISO 13400-2 DoIP, ISO 17987-2 LIN, ISO 20794-32
2 Under preparation. Stage at the time of publication: ISO/FDIS 20794-3:2020.
CXPI, ISO 27145-4 VOBD.
—
Network layer services (layer 3), specified in ISO 15765-2 DoCAN, ISO 10681-2 Communication on FlexRay, ISO 13400-2 DoIP, ISO 17987-2 LIN, ISO 20794-3 CXPI, ISO 27145-4 VOBD.
—
Data link layer (layer 2), specified in ISO 11898-1, ISO 11898-2, ISO 17458-2, ISO 13400-3, IEEE 802.3, ISO 14230-2, ISO 17987-3 LIN, ISO 20794-43
3 Under preparation. Stage at the time of publication: ISO/FDIS 20794-4:2020.
CXPI, and further standards, ISO 27145-4 VOBD.
—
Physical layer (layer 1), specified in ISO 11898-1, ISO 11898-2, ISO 17458-4, ISO 13400-3, IEEE 802.3, ISO 14230-1, ISO 17987-4 LIN, ISO 20794-4 CXPI, and further standards, ISO 27145-4 VOBD.
NOTE The diagnostic services in this document are implemented in various applications, e.g. road vehicles – tachograph systems, road vehicles – interchange of digital information on electrical connections between towing and towed vehicles, road vehicles – diagnostic systems, etc. Future modifications to this document will provide long-term backward compatibility with the implementation standards as described above.
Table 1 — Example of diagnostic/programming specifications applicable to the OSI layers
OSI seven layera Enhanced diagnostics services VOBD
a Seven layers according to ISO/IEC 7498-1 and ISO/IEC 10731.
Application
(layer 7)
ISO 14229-1, ISO 14229-3 UDSonCAN, ISO 14229-4 UDSonFR, ISO 14229-5 UDSonIP, ISO 14229-6 UDSonK-Line, ISO 14229-7 UDSonLIN, ISO 14229-8 UDSonCXPI, further standards ISO 27145-3
Presentation
(layer 6)
vehicle manufacturer specific ISO 27145-2
Session
(layer 5)
ISO 14229-2
Transport
(layer 4)
ISO 15765-2 ISO 10681-2 ISO 13400-2 Not applicable ISO 17987-2 ISO 20794-3 further standards ISO 27145-4
Network
(layer 3)
further standards
Data link
(layer 2)
ISO 11898-1,
ISO 11898-2
ISO 17458-2 ISO 13400-3,
IEEE 802.3
ISO 14230-2 ISO 17987-3 ISO 20794-4 further standards
Physical
(layer 1)
ISO 17458-4 ISO 14230-1 ISO 17987-4 further standards

International Standard ISO 14229-1:2020(en)
Road vehicles — Unified diagnostic services (UDS) —
Part 1:
Application layer

1 Scope

This document specifies data link independent requirements of diagnostic services, which allow a diagnostic tester (client) to control diagnostic functions in an on-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.
It specifies generic services, which allow the diagnostic tester (client) to stop or to resume non-diagnostic message transmission on the data link.
This document does not apply to non-diagnostic message transmission on the vehicle's communication data link between two electronic control units. However, this document does not restrict an in-vehicle on-board tester (client) implementation in an ECU in order to utilize the diagnostic services on the vehicle's communication data link to perform bidirectional diagnostic data exchange.
This document does not specify any implementation requirements.

2 Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 14229-2, Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
ISO 7816-8, Identification cards — Integrated circuit cards — Part 8: Commands and mechanisms for security operations
ISO/IEC 9594-8, Information technology — Open Systems Interconnection — The Directory — Part 8: Public-key and attribute certificate frameworks
IEEE 754-2008, IEEE Standard for Floating-Point Arithmetic
IEEE 1609.2, Standard for Wireless Access in Vehicular Environments — Security Services for Applications and Management Messages
X.509, Information technology — Open Systems Interconnection — The Directory: Public-key and attribute certificate frameworks
RFC 5280, Internet Engineering Task Force — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 5755, Internet Engineering Task Force — An Internet Attribute Certificate Profile for Authorization

3 Terms and definitions

For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
—
ISO Online browsing platform: available at https://www.iso.org/obp
—
IEC Electropedia: available at http://www.electropedia.org/
3.1
boot memory partition
area of the server (3.18) memory in which the boot software (3.2) is located
3.2
boot software
software which is executed in a special part of server (3.18) memory which is used primarily to boot the ECU (3.9) and perform server programming
Note 1 to entry: This area of memory is not erased during a normal programming sequence and executes when the server application is missing or otherwise deemed invalid to always ensure the capability to reprogram the server.
Note 2 to entry: See 0 and 17.3.1.1.
3.3
client
function that is part of the tester (3.20) and that makes use of the diagnostic services (3.6)
Note 1 to entry: A tester normally makes use of other functions such as data base management, specific interpretation, human-machine interface.
3.4
diagnostic channel
dedicated transmission path from client (3.3) to server (3.18) for diagnostic communication
Note 1 to entry: Several simultaneously connected clients to one server can be differentiated by an individual tester (3.20) source address.
3.5
diagnostic data
data that is located in the memory of an electronic control unit (3.9) which may be inspected and/or possibly modified by the tester (3.20)
The server (3.18) is not obliged to keep internal copies of its data for diagnostic purposes, in which case the tester may only request the current value.
Note 1 to entry: Diagnostic data includes analogue inputs and outputs, digital inputs and outputs, intermediate values and various status information.
Note 2 to entry: Examples of diagnostic data are vehicle speed, throttle angle, mirror position, system status, etc. Three types of values are defined for diagnostic data:
—
the current value: the value currently used by (or resulting from) the normal operation of the electronic control unit;
—
a stored value: an internal copy of the current value made at specific moments (e.g. when a malfunction occurs or periodically); this copy is made under the control of the electronic control unit;
—
a static value: e.g. VIN.
Note 3 to entry: Defining a repair shop or development testing session selects different server functionality (e.g. access to all memory locations may only be allowed in the development testing session).
3.6
diagnostic service
information exchange initiated by a client (3.3) in order to require diagnostic information from a server (3.18) or/and to modify its behaviour for diagnostic purpose
3.7
diagnostic session
state within the server (3.18) in which a specific set of diagnostic services (3.6) and functionality is enabled
3.8
diagnostic trouble code
DTC
numerical common identifier for a fault condition identified by the on-board diagnostic system
3.9
ECU
electronic control unit
unit providing information regarding the connected sensor and control network
Note 1 to entry: Systems considered as electronic control units include anti-lock braking system (ABS) and engine management system.
3.10
functional unit
set of functionally close or complementary diagnostic services (3.6)
3.11
local server
server (3.18) that is connected to the same local network as the client (3.3) and is part of the same address space as the client
3.12
permanent DTC
diagnostic trouble code (3.8) that remains in non-volatile memory, even after a clear DTC request, until other criteria (typically regulatory) are met (e.g. the appropriate monitors for each DTC have successfully passed)
Note 1 to entry: Refer to the relevant legislation for all necessary requirements.
3.13
record
one or more diagnostic data (3.5) elements that are referred to together by a single means of identification
Note 1 to entry: A snapshot including various input/output data and trouble codes is an example of a record.
3.14
remote server
server (3.18) that is not directly connected to the main diagnostic network
Note 1 to entry: A remote server is identified by means of a remote address. Remote addresses represent an own address space that is independent from the addresses on the main network.
Note 2 to entry: A remote server is reached via a local server (3.11) on the main network. Each local server on the main network can act as a gate to one independent set of remote servers. A pair of addresses therefore always identifies a remote server: one local address that identifies the gate to the remote network and one remote address identifying the remote server itself.
3.15
remote client
client (3.3) that is not directly connected to the main diagnostic network
Note 1 to entry: A remote client is identified by means of a remote address.
Note 2 to entry: Remote addresses represent an own address space that is independent from the addresses on the main network.
3.16
reprogramming software
part of the boot software (3.2) that allows for reprogramming of the electronic control unit (3.9)
3.17
security
mechanism for protecting vehicle modules from "unauthorized" intrusion through a vehicle diagnostic data (3.5) link
3.18
server
function that is part of an electronic control unit (3.9) and that provides the diagnostic services (3.6)
Note 1 to entry: This document differentiates between the server (i.e. the function) and the electronic control unit to ensure independence from implementation.
3.19
supported DTC
diagnostic trouble code (3.8) which is currently configured/calibrated and enabled to execute under predefined vehicle conditions.
3.20
tester
system that controls functions such as test, inspection, monitoring, or diagnosis of an on-vehicle electronic control unit (3.9) and can be dedicated to a specific type of operator (e.g. an off-board scan tool dedicated to garage mechanics, an off-board test tool dedicated to assembly plants, or an on-board tester)
Note 1 to entry: The tester is also referenced as the client (3.3).

Bibliography
[1]
ISO 4092:1988/Cor.1:1991, Road vehicles — Diagnostic systems for motor vehicles — Vocabulary — Technical Corrigendum 1
[2]
ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model
[3]
ISO/IEC 7618-8:2006, Identification cards — Integrated circuit cards
[4]
ISO/TR 8509:1987, Information processing systems — Open Systems Interconnection — Service conventions
[5]
ISO/IEC 9798-2, IT Security techniques — Entity authentication — Part 2: Mechanisms using authenticated encryption
[6]
ISO/IEC 9798-3, IT Security techniques — Entity authentication — Part 3: Mechanisms using digital signature techniques
[7]
ISO/IEC 9798-4, Information technology — Security techniques — Entity authentication — Part 4: Mechanisms using a cryptographic check function
[8]
ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference Model — Conventions for the definition of OSI services
[9]
ISO 11992-4, Road vehicles — Interchange of digital information on electrical connections between towing and towed vehicles — Part 4: Diagnostics
[10]
ISO 14229-3, Road vehicles — Unified diagnostic services (UDS) — Part 3: Unified diagnostic services on CAN implementation (UDSonCAN)
[11]
ISO 14229-4, Road vehicles — Unified diagnostic services (UDS) — Part 4: Unified diagnostic services on FlexRay implementation (UDSonFR)
[12]
ISO 14229-5, Road vehicles — Unified diagnostic services (UDS) — Part 5: Unified diagnostic services on Internet Protocol implementation (UDSonIP)
[13]
ISO 14229-6, Road vehicles — Unified diagnostic services (UDS) — Part 6: Unified diagnostic services on K-Line implementation (UDSonK-Line)
[14]
ISO 14229-7, Road vehicles — Unified diagnostic services (UDS) — Part 7: UDS on local interconnect network (UDSonLIN)
[15]
ISO 14229-8, Road vehicles — Unified diagnostic services (UDS) — Part 8: Unified diagnostic services on clock extension peripheral interface implementation (UDSonCXPI)
[16]
ISO 15031-2, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 2: Guidance on terms, definitions, abbreviations and acronyms
[17]
ISO 15031-6, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 6: Diagnostic trouble code definitions
[18]
ISO 15765-4, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 4: Requirements for emissions-related systems
[19]
ISO 22901-1, Road vehicles — Open diagnostic data exchange (ODX) — Part 1: Data model specification
[20]
ISO 26021-2, Road vehicles — End-of-life activation of on-board pyrotechnic devices — Part 2: Communication requirements
[21]
ISO 27145-2, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics (VOBD) communication requirements — Part 2: Common data dictionary
[22]
ISO 27145-3, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics (VOBD) communication requirements — Part 3: Common message dictionary
[23]
SAE J1939:2011, Serial Control and Communications Heavy Duty Vehicle Network — Top Level Document
[24]
SAE J1939-73:2010, Application Layer — Diagnostics
[25]
ISO 10681-2, Road vehicles — Communication on FlexRay — Part 2: Communication layer services
[26]
ISO 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling
[27]
ISO 11898-2, Road vehicles — Controller area network (CAN) — Part 2: High-speed medium access unit
[28]
ISO 13400-2, Road vehicles — Diagnostic communication over Internet Protocol (DoIP) — Part 2: Transport protocol and network layer services
[29]
ISO 13400-3, Road vehicles — Diagnostic communication over Internet Protocol (DoIP) — Part 3: Wired vehicle interface based on IEEE 802.3
[30]
ISO 14230-1, Road vehicles — Diagnostic communication over K-Line (DoK-Line) — Part 1: Physical layer
[31]
ISO 14230-2, Road vehicles — Diagnostic communication over K-Line (DoK-Line) — Part 2: Data link layer
[32]
ISO 15031-4, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 4: External test equipment
[33]
ISO 15031-5, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 5: Emissions-related diagnostic services
[34]
ISO 15765-2, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 2: Transport protocol and network layer services
[35]
ISO 16844-7, Road vehicles — Tachograph systems — Part 7: Parameters
[36]
ISO 17458-2, Road vehicles — FlexRay communications system — Part 2: Data link layer specification
[37]
ISO 17458-4, Road vehicles — FlexRay communications system — Part 4: Electrical physical layer specification
[38]
ISO 17987-2, Road vehicles — Local Interconnect Network (LIN) — Part 2: Transport protocol and network layer services
[39]
ISO 17987-3, Road vehicles — Local Interconnect Network (LIN) — Part 3: Protocol specification
[40]
ISO 17987-4, Road vehicles — Local Interconnect Network (LIN) — Part 4: Electrical physical layer (EPL) specification 12 V/24 V
[41]
ISO 20794-3, Road vehicles — Clock extension peripheral interface (CXPI) — Part 3: Transport and network layer
[42]
ISO 20794-4, Road vehicles — Clock extension peripheral interface (CXPI) — Part 4: Data link layer and physical layer
[43]
ISO 26021-2, Road vehicles — End-of-life activation of on-board pyrotechnic devices — Part 2: Communication requirements
[44]
ISO 27145-4, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics (WWH-OBD) communication requirements — Part 4: Connection between vehicle and test equipment
[45]
IEEE 802.3, IEEE Standard for Ethernet
[46]
SAE J1978, OBD II Scan Tool — Equivalent to ISO/DIS 15031-4:December 14, 2001
[47]
SAE J1979, E/E Diagnostic Test Modes
[48]
SAE J1979-2, Compliant OBDII Scan Tool
[49]
SAE J1979-DA, Digital Annex of E/E Diagnostic Test Modes
[50]
SAE J2012, Diagnostic Trouble Code Definitions
[51]
SAE J2534, Recommended Practice for Pass-Thru Vehicle Programming (STABILIZED Jul 2019)
[52]
ISO 15765-5, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 5: Specification for an in-vehicle network connected to the diagnostic link connector
ICS 43.180
Price based on 466 pages
iso.org

1 Under preparation. Stage at the time of publication: ISO/FDIS 14229-8:2020.
2 Under preparation. Stage at the time of publication: ISO/FDIS 20794-3:2020.
3 Under preparation. Stage at the time of publication: ISO/FDIS 20794-4:2020.