Road vehicles — Unified diagnostic services (UDS) — Part 3: Unified diagnostic services on CAN implementation (UDSonCAN)

This document specifies an application profile for the implementation of unified diagnostic services (UDS) on controller area network (CAN) in road vehicles. UDSonCAN references ISO 14229-1 and ISO 14229-2 and specifies implementation requirements of the diagnostic services to be used for diagnostic communication on CAN. This document specifies — additional requirements specific to the implementation of UDS on the CAN network, and; — specific restrictions in the implementation of UDS on the CAN network.

Véhicules routiers — Services de diagnostic unifiés (SDU) — Partie 3: SDU sur l'implémentation du gestionnaire de réseau de communication (SDUsurCAN)

General Information

Status
Published
Publication Date
07-Mar-2022
Current Stage
6060 - International Standard published
Start Date
08-Mar-2022
Due Date
21-Nov-2021
Completion Date
08-Mar-2022
Ref Project

Relations

Buy Standard

Standard
ISO 14229-3:2022 - Road vehicles — Unified diagnostic services (UDS) — Part 3: Unified diagnostic services on CAN implementation (UDSonCAN) Released:3/8/2022
English language
19 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 14229-3
Second edition
2022-03
Road vehicles — Unified diagnostic
services (UDS) —
Part 3:
Unified diagnostic services on CAN
implementation (UDSonCAN)
Véhicules routiers — Services de diagnostic unifiés (SDU) —
Partie 3: SDU sur l'implémentation du gestionnaire de réseau de
communication (SDUsurCAN)
Reference number
ISO 14229-3:2022(E)
© ISO 2022

---------------------- Page: 1 ----------------------
ISO 14229-3:2022(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2022
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
  © ISO 2022 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 14229-3:2022(E)
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms.1
4.1 Symbols . 1
4.2 Abbreviated terms . 2
5 Conventions . 2
6 Service primitive interface definition . 3
7 Technical requirements overview . 3
8 Application layer . 4
8.1 ISO 14229-1 service primitive parameters . 4
8.2 A_Data.req, A_Data.ind, and A_Data.conf service interface . 4
8.3 UDSonCAN services overview . 4
8.4 A_PDU definition . 5
8.5 ReadDataByPeriodicIdentifier service UDSonCAN implementation requirements . 6
8.5.1 UUDT periodic transmission response message handling . 6
8.5.2 Service interface – UUDT . 6
8.5.3 UUDT service primitive parameters . 8
8.5.4 UUDT message format . 9
8.5.5 Periodic transmission message flow . 10
8.6 Timing parameter definition . 13
8.6.1 Request and response message timing parameter values .13
8.6.2 Unsolicited response messages . 13
9 Presentation layer .13
10 Session layer .13
10.1 Service primitive parameter definition . 13
10.2 S_Data.req, S_Data.ind, and S_Data.conf service interface .13
11 Transport layer .14
11.1 USDT service primitive parameters . 14
11.2 T_Data.req, T_Data.ind, and T_Data.conf service interface . 14
11.3 Transport protocol . 14
11.4 T_PDU definition . 14
11.5 DoCAN transport and network layer interface adaptation . 14
11.5.1 Mapping of data link independent service primitives onto CAN data link-
dependent service primitives . 14
11.5.2 Mapping of T_PDU onto N_PDU . 15
12 Network layer .15
12.1 Service primitive parameter definition . 15
12.2 N_Data.req, N_Data.ind, and N_Data.conf service interface . 15
12.3 Network layer services. 16
12.4 N_PDU definition. 16
12.5 N_TAtype service primitive parameter . 16
12.6 Same N_TAtype request and associated response message format . 16
13 Data link layer .17
13.1 Service primitive parameter definition . 17
13.2 L_Data.req, L_Data.ind, and L_Data.conf service interface . 17
13.3 Usage of ISO 15765-4-defined 11-bit CAN identifiers for enhanced diagnostics . 17
iii
© ISO 2022 – All rights reserved

---------------------- Page: 3 ----------------------
ISO 14229-3:2022(E)
13.4 Usage of ISO 15765-4-defined 29-bit CAN identifiers for enhanced diagnostics. 18
14 Physical layer .18
Bibliography .19
iv
  © ISO 2022 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 14229-3:2022(E)
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 second edition cancels and replaces the first edition (ISO 14229-3:2012), which has been technically
revised.
The main changes are as follows:
— restructuration of the document;
— introduction of requirement numbers, names and definitions;
— technical content improvements based on implementation feedback from the automotive industry.
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.
v
© ISO 2022 – All rights reserved

---------------------- Page: 5 ----------------------
ISO 14229-3:2022(E)
Introduction
The ISO 14229 series has been established in order to define common requirements for diagnostic
systems, whatever the serial data link is.
To achieve this, the ISO 14229 series is based on the Open Systems Interconnection (OSI) Basic Reference
[1] [2]
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 structured into the following layers:
— application layer (layer 7) specified in ISO 14229-1 and ISO 14229-3 to ISO 14229-8;
— presentation layer (layer 6) specified in ISO 14229-1 and ISO 14229-3 to ISO 14229-8;
— session layer services (layer 5) specified in ISO 14229-2 and ISO 14229-3 to ISO 14229-8.
Figure 1 illustrates the UDSonCAN document and related documents according to the OSI model.
Figure 1 — ISO 14229-3 document reference according to OSI model
vi
  © ISO 2022 – All rights reserved

---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO 14229-3:2022(E)
Road vehicles — Unified diagnostic services (UDS) —
Part 3:
Unified diagnostic services on CAN implementation
(UDSonCAN)
1 Scope
This document specifies an application profile for the implementation of unified diagnostic services
(UDS) on controller area network (CAN) in road vehicles.
UDSonCAN references ISO 14229-1 and ISO 14229-2 and specifies implementation requirements of the
diagnostic services to be used for diagnostic communication on CAN.
This document specifies
— additional requirements specific to the implementation of UDS on the CAN network, and;
— specific restrictions in the implementation of UDS on the CAN network.
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 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical
signalling
ISO 14229-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer
ISO 14229-2, Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
ISO 15765-2, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 2:
Transport protocol and network layer services
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
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 14229-1, ISO 14229-2,
ISO 15765-2, and ISO 15765-5 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
4 Symbols and abbreviated terms
4.1 Symbols
1
© ISO 2022 – All rights reserved

---------------------- Page: 7 ----------------------
ISO 14229-3:2022(E)
— empty table cell or feature undefined
t
time
t
P_Client
client application layer timer
t
P2_Server server application layer timer
t
P2_CAN_Client client application layer timeout value for CAN
t
P2_CAN_Server
server application layer timeout value for CAN
t
S3_Client
client session layer timer
t
S3_Server server session layer timer
t
S3_Server_Reload
server session layer timeout-reload value
4.2 Abbreviated terms
CAN Controller Area Network
CBFF classical base frame format
CEFF classical extended frame format
DA destination address
DLC data length code
FBFF FD base frame format
FEFF FD extended frame format
IVN in-vehicle network
PCI protocol control information
SA source address
SId service identifier
SOM start of message
STRT serviceToRespondTo
TA target address
UDS unified diagnostic services
USDT unacknowledged segmented data transfer
UUDT unacknowledged unsegmented data transfer
5 Conventions
[2]
This document is based on OSI service conventions as specified in ISO/IEC 10731 .
2
  © ISO 2022 – All rights reserved

---------------------- Page: 8 ----------------------
ISO 14229-3:2022(E)
6 Service primitive interface definition
The service interface defines the service primitive from the application layer to the session layer.

Figure 2 shows the Data.req (request), Data.ind (indication), and Data.conf (confirmation) service
interface.
Key
1 service access point between application and application layer
2 read back from N-layer service provider
t time
Figure 2 — Data.req, Data.ind, and Data.conf service interface
7 Technical requirements overview
Table 1 provides an overview about technical requirements and associated requirement numbers.
Table 1 — Technical requirements overview
OSI#.REQ# Technical requirement title
7 Application layer
7.1 ISO 14229-1 service primitive parameters
7.2 A_Data.req, A_Data.ind, and A_Data.conf service interface
7.3 UDSonCAN specific requirements
7.4 No UDSonCAN-specific requirements
7.5 UUDT periodic transmission response message handling
7.6 UUDT periodic transmission response message server restrictions
7.7 UUDT OSI-layer support
7.8 Service primitive – A_UUData.req
7.9 Service primitive – A_UUData.ind
7.10 Service primitive – A_UUData.conf
7.11 General UUDT service primitive parameters
7.12 Specific UUDT service primitive parameters
3
© ISO 2022 – All rights reserved

---------------------- Page: 9 ----------------------
ISO 14229-3:2022(E)
Table 1 (continued)
OSI#.REQ# Technical requirement title
7.13 UUDT message format
7.14 UUDT A_PDU size
7.15 Request and response message timing parameter values
7.16 Unsolicited response messages
6 Presentation layer
--- No requirement statement in this document
5 Session layer
5.1 Service primitive parameter definition
5.2 S_Data.req, S_Data.ind, and S_Data.conf service interface
4 Transport layer
4.1 USDT service primitive parameters
4.2 T_Data.req, T_Data.ind, and T_Data.conf service interface
3 Network layer
3.1 Service primitive parameter definition
3.2 N_Data.req, N_Data.ind, and N_Data.conf service interface
3.4 N_TAtype service primitive parameter
3.5 Same N_TAtype request and associated response message format
2 Data link layer
2.1 Service primitive parameter definition
2.2 L_Data.req, L_Data.ind, and L_Data.conf service interface
1 Physical layer
— No requirement statement in this document.
8 Application layer
8.1 ISO 14229-1 service primitive parameters
REQ 7.1 UDSonCAN – ISO 14229-1 service primitive parameters
The service primitive parameter shall be implemented as specified in ISO 14229-1.
8.2 A_Data.req, A_Data.ind, and A_Data.conf service interface
This document is part of the ISO 14229 series and therefore, the service interface implementation
follows the ISO 14229-1 specification.
REQ 7.2 UDSonCAN – A_Data.req, A_Data.ind, and A_Data.conf service interface
The A_Data.req, A_Data.ind, and A_Data.conf service interface shall be implemented as specified in
ISO 14229-1.
8.3 UDSonCAN services overview
The purpose of Table 2 is to reference ISO 14229-1 and ISO 14229-2 services as they are applicable for
an implementation in this document. Table 2 contains the UDSonCAN applicable diagnostic services.
Certain UDSonCAN applications can restrict the number of useable services and can categorize them in
application areas/diagnostic sessions (default session, programming session, etc.).
REQ 7.3 UDSonCAN specific requirements
4
  © ISO 2022 – All rights reserved

---------------------- Page: 10 ----------------------
ISO 14229-3:2022(E)
Services that are marked “UDSonCAN-specific requirements” shall be implemented as specified in the
referenced subclause number in accordance with Table 2 "Reference" column.

REQ 7.4 No UDSonCAN-specific requirements
Services specified in Table 2 that are marked “No UDSonCAN-specific requirements” shall be implemented
as specified in ISO 14229-1 and ISO 14229-2 with no additional restrictions.
Table 2 — Overview of applicable ISO 14229-1-defined services
Functional unit Diagnostic service name Comment Reference
name
Diagnostic and DiagnosticSessionControl No UDSonCAN-specific requirements —
communication
ECUReset No UDSonCAN-specific requirements —
management
SecurityAccess No UDSonCAN-specific requirements —
CommunicationControl No UDSonCAN-specific requirements —
TesterPresent No UDSonCAN-specific requirements —
AccessTimingParameters Not supported —
Authentication No UDSonCAN-specific requirements —
SecuredDataTransmission No UDSonCAN-specific requirements —
ControlDTCSetting No UDSonCAN-specific requirements —
ResponseOnEvent No UDSonCAN-specific requirements —
LinkControl No UDSonCAN-specific requirements —
Data ReadDataByIdentifier No UDSonCAN-specific requirements —
transmission
ReadMemoryByAddress No UDSonCAN-specific requirements —
ReadScalingDataByIdentifier No UDSonCAN-specific requirements —
ReadDataByPeriodicIdentifier UDSonCAN-specific requirements see 8.5
DynamicallyDefineDataIdenti- No UDSonCAN-specific requirements —
fier
WriteDataByIdentifier No UDSonCAN-specific requirements —
WriteMemoryByAddress No UDSonCAN-specific requirements —
Stored data ReadDTCInformation No UDSonCAN-specific requirements —
transmission
ClearDiagnosticInformation No UDSonCAN-specific requirements —
Input/output InputOutputControlByIdentifier No UDSonCAN-specific requirements —
control
Remote RoutineControl No UDSonCAN-specific requirements —
activation of
routine
Upload/ RequestDownload No UDSonCAN-specific requirements —
download
RequestUpload No UDSonCAN-specific requirements —
TransferData No UDSonCAN-specific requirements —
RequestTransferExit No UDSonCAN-specific requirements —
RequestFileTransfer No UDSonCAN-specific requirements —
8.4 A_PDU definition
Figure 3 shows the A_PDU.
5
© ISO 2022 – All rights reserved

---------------------- Page: 11 ----------------------
ISO 14229-3:2022(E)
Figure 3 — A_PDU definition
8.5 ReadDataByPeriodicIdentifier service UDSonCAN implementation requirements
8.5.1 UUDT periodic transmission response message handling
The periodic transmission response message is based on a message size which is supported by the in-
vehicle network (IVN). The IVN can consist of gateways and other connected data links than CAN.
REQ 7.5 UDSonCAN – ReadDataByPeriodicIdentifier – UUDT periodic transmission response
message handling
The A_PDU length referenced by a periodicDataIdentifier (pDID) shall not exceed the length limitation
of a non-segmented message.

REQ 7.6 UDSonCAN – ReadDataByPeriodicIdentifier – UUDT periodic transmission response
message server restrictions
Client receiving periodic response messages shall support the message mapping as specified in Table 3.
Server transmitting periodic response messages shall support the message mapping as specified in Table 3.
Table 3 — Periodic transmission response message mapping
Client request Server response
Message type Further server restrictions
requirements requirements
A UUDT mes- No restrictions 1. Only sin- The request for periodic transmission is processed as
sage shall use a gle-frame a regular diagnostic request and the response is sent
different CAN responses for via the network layer (as a USDT message with service
identifier for periodic trans- identifier 6A ).
16
periodic trans- mission
On receiving the N_USData.con that indicates the
mission.
completion of the transmission of the positive response,
2. Multi-frame
the application starts an independent scheduler, which
responses to
handles the periodic transmission.
new (non-period-
ic-transmission)
The scheduler in the server processes the periodic
requests are
transmission as a single CAN frame response message
possible
in a bypass (i.e. writes the message directly to the
CAN-controller/data link layer driver without using the
network-layer).
There is neither a protocol control information (PCI) nor
a service identifier (SId) included in the response mes-
sage. Only the periodic identifier and corresponding data
are included.
8.5.2 Service interface – UUDT
8.5.2.1 General
The unconfirmed unsegmented data transfer (UUDT) is a response message type. UUDT messages
are communicated between the application layer and the data link layer. UUDT periodic response
6
  © ISO 2022 – All rights reserved

---------------------- Page: 12 ----------------------
ISO 14229-3:2022(E)
messages neither support the service identifier information (application layer) nor the protocol control
information (transport layer).
REQ 7.7 UDSonCAN – ReadDataByPeriodicIdentifier – UUDT OSI-layer support
UUDT messages shall bypass the session layer, transport layer, and the network layer and implemented
in the data link layer.
8.5.2.2 Service primitive – A_UUData.req
The A_UUData.req service primitive is issued by the sender node.
REQ 7.8 UDSonCAN – UUDT service primitive – A_UUData.req
The service primitives shall request periodic transmission of A_Data with A_Length number of bytes from
the sender to the receiver peer entities identified by the message type A_Mtype and address information
in A_UUTAtype, A_SA and A_TA.

A_UUData.req
(
A_Mtype,
A_SA,
A_TA,
A_UUTAtype,
A_Data[Data#1, Data#2, …, Data#n ],
A_Length,
)
8.5.2.3 Service primitive – A_UUData.ind
The A_UUData.ind service primitive is received by the receiver node.
REQ 7.9 UDSonCAN – UUDT service primitive – A_UUData.ind
The service primitives shall deliver A_Data with A_Length bytes received from a peer protocol entity
identified by the message type A_Mtype and address information in A_UUTAtype, A_SA and A_TA.

The parameters A_Data and A_Length are only valid when the service primitive is indicated. In case of a
reception error no indication is generated.
A_UUData.ind
(
A_Mtype,
A_SA,
A_TA,
A_UUTAtype,
A_Data[Data#1, Data#2, …, Data#n ],
A_Length,
)
8.5.2.4 Service primitive – A_UUData.conf
7
© ISO 2022 – All rights reserved

---------------------- Page: 13 ----------------------
ISO 14229-3:2022(E)
The A_UUData.conf service is received by the sender node.
REQ 7.10 UDSonCAN – UUDT service primitive – A_UUData.conf
The service primitives shall confirm the completion of a A_UUData.req service identified by the message
type A_Mtype and address information in A_UUTAtype, A_SA, and A_TA. The parameter A_Result provides
the status of the service request.

A_UUData.conf
(
A_Mtype,
A_SA,
A_TA,
A_UUTAtype,
A_Result
A_Length,
)

Figure 4 shows the UUDT service primitive interface. The sender node implementation of L_Data.conf
and A_UUData.conf is not in the scope of this document.

a
CAN ACK (acknowledge) bit is set by a receiver node and indicated to the sender.
b
The data link layer of the sender node initiates a L_Data.conf service primitive to indicate to the application
layer.
Figure 4 — UUDT service primitive interface
8.5.3 UUDT service primitive parameters
8.5.3.1 Service primitive data types
UUDT messages are exchanged directly between the application layer and the data link layer.
8
  © ISO 2022 – All rights reserved

---------------------- Page: 14 ----------------------
ISO 14229-3:2022(E)
The service primitive data types derive from ISO 14229-2.
REQ 7.11 UDSonCAN – ReadDataByPeriodicIdentifier – General UUDT service primitive pa-
rameters
The data type definitions and the parameters Mtype, TA, SA, Length, Data, and Result shall be implemented
as specified in ISO 14229-2.
8.5.3.2 UUDT specific parameters
The parameter A_UUTAtype is UUDT-specific and is a configuration attribute to the A_TA parameter. It is
used to encode the UUDT communication model used by the communicating peer entities.
REQ 7.12 UDSonCAN – ReadDataByPeriodicIdentifier – Specific UUDT service primitive pa-
rameters
The A_UUTAtype parameter shall be of data type Enum (see ISO 14229-2) and is used to identify the UUDT
target address type.
Range:
[A_UUTAtype #1: physical addressing, UUDT classical base frame format (CBFF), 11-bit CAN identifier,
A_UUTAtype #2: physical addressing, UUDT FD base frame format (FBFF), 11-bit CAN identifier,
A_UUTAtype #3: physical addressing, UUDT classical extended frame format (CEFF), 29-bit CAN
identifier,
A_UUTAtype #4: physical addressing, UUDT FD extended frame format (FEFF), 29-bit CAN identifier]
8.5.4 UUDT message format
8.5.4.1 General
A UUDT A_PDU consists of three fields.
REQ 7.13 UDSonCAN – ReadDataByPeriodicIdentifier – UUDT message
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.