ISO 11992-4:2023

INTERNATIONAL ISO
STANDARD 11992-4
Third edition
2023-04
Road vehicles — Interchange of digital
information on electrical connections
between towing and towed vehicles —
Part 4:
Diagnostic communication
Véhicules routiers — Échange d'informations numériques sur
les connexions électriques entre véhicules tracteurs et véhicules
tractés —
Partie 4: Communication de diagnostic
Reference number
© ISO 2023
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 .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms.2
4.1 Symbols . 2
4.2 Abbreviated terms . 2
5 Conventions . 2
6 Vehicle network architecture .3
7 Non OSI-layer-related technical requirements overview . 4
8 Abstract service primitive interface (ASP) definition . 5
8.1 ASP – A_Data.req, A_Data.ind, and A_Data.con service primitive interface . 5
8.2 ASP – Service interface parameters . 6
8.2.1 General . 6
8.2.2 ASP – Data type definitions . 7
8.2.3 ASP – Mtype, message type . 7
8.2.4 ASP – TAtype, target address type . 7
8.2.5 ASP – AE, address extension . 7
8.2.6 ASP – TA, target address . 7
8.2.7 ASP – SA, source address . 7
8.2.8 ASP – Length, length of PDU. 8
8.2.9 ASP – PDU, protocol data unit . 8
8.2.10 ASP – Result, result . 8
9 Application .8
9.1 APP – Addressing of requested information . 8
9.2 APP – Data identifier (DID) definition . 8
9.3 APP – DTC field definition . 9
9.4 APP – DTC functional unit definition. 9
9.5 APP – Negative response code (NRC). 10
9.6 APP – Communication profile (ComProfile) . 10
10 OSI-layers-related technical requirements overview .11
11 Application layer .12
11.1 AL – Diagnostic services overview .12
11.2 AL – CommunicationControl . 13
11.3 AL – ReadDataByIdentifier . 13
11.4 AL – ReadDtcInformation . 14
11.4.1 AL – General . 14
11.4.2 AL – Applicable ReadDtcInformation service subFunctions . . 14
11.5 AL – Application layer communication profile (ComProfile) . 14
12 Presentation layer .14
13 Session layer .14
13.1 SL – Service primitive interface parameter definition . 14
13.2 SL – S_Data.req, S_Data.ind, and S_Data.con service interface . 14
13.3 SL – Service primitive interface AL to SL parameter mapping . 15
13.4 SL – Session layer communication profile (ComProfile) . 15
14 Transport layer .15
14.1 TL – USDT service primitive interface parameter definition . 15
iii
14.2 TL – T_Data.req, T_Data.ind, and T_Data.con service interface .15
14.3 TL – Service primitive interface SL to TL parameter mapping . 16
14.4 TL – Transport protocol . 16
14.5 TL – Transport layer communication profile (ComProfile) . 16
15 Network layer .16
15.1 NL – Service primitive interface parameter definition . 16
15.2 NL – N_Data.req, N_Data.ind, and N_Data.con service interface . 17
15.3 NL – Service primitive interface TL to NL parameter mapping . 17
15.4 NL – Network layer services . 17
15.5 NL – Network layer communication profile (ComProfile) . 17
15.6 NL – Diagnostic CAN identifier configuration . 18
15.7 NL – Dynamic network address assignment . 19
15.7.1 NL – General . 19
15.7.2 NL – Address assignment of TTN_1 and TTN_3 . 19
15.7.3 NL – Address assignment of TTN_2 and TTN_4 . 20
15.8 NL – Static network address assignment . 20
15.8.1 NL – General . 20
15.8.2 NL – Address assignment of gateway application, IVN_1, and IVN_2 .20
15.8.3 NL – Server address assignment of IVN_1 and IVN_2 .20
15.9 NL – Gateway N_PDU routing .20
15.9.1 NL – General . 20
15.9.2 NL – Network address translation . 21
15.10 NL – Diagnostic communication port (DCP) . 25
16 Data link layer .25
16.1 DL – Service primitive interface parameter definition . 25
16.2 DL – L_Data.req, L_Data.ind, and L_Data.con service interface . 25
16.3 DL – Service primitive interface NL to DL parameter mapping . 26
16.4 DL – CAN data frame . 26
16.5 DL – Data link layer communication profile (ComProfile). 26
17 Physical layer .26
Annex A (normative) Network address assignment .28
Bibliography .30
iv
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 ww.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 11992-4:2014), which has been
technically revised.
The main changes are as follows:
— introduction of requirement structure with numbering and name;
— introduction of application requirements;
— introduction of OSI layers related requirements;
— clarification on gateway network address translation (deleted subnet addressing subclause).
A list of all parts in the ISO 11992 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
Introduction
The ISO 11992 series specifies the interchange of digital information between road vehicles with a
maximum authorised total mass greater than 3 500 kg, and towed vehicles, including communication
between towed vehicles in terms of parameters and requirements of the lower OSI layers (physical and
data link layer) of the electrical connection used to connect the electrical and electronic systems.
This document is structured according to 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 application layer protocol and data link
layer framework requirements specified/referenced in the ISO 11992 series are structured according
to Figure 1.
Figure 1 illustrates a simplified communication framework:
— vehicle normal communication framework,
— vehicle diagnostic communication framework,
— vehicle-specific use case framework, and
— vehicle lower-layers framework.
The vehicle normal communication framework is composed of ISO 11992-2 and ISO 11992-3.
The vehicle diagnostic communication framework is composed of ISO 14229-1, ISO 14229-2, ISO 14229-3
and this document.
The vehicle-specific use case framework is composed of this document, ISO 22901-1 or vehicle
manufacturer-specific diagnostic data definition.
Figure 1 — ISO documents reference according to the OSI model
vi
INTERNATIONAL STANDARD ISO 11992-4:2023(E)
Road vehicles — Interchange of digital information
on electrical connections between towing and towed
vehicles —
Part 4:
Diagnostic communication
1 Scope
This document specifies diagnostic application requirements and OSI-layer related communication
profiles to ensure the interchange of digital information between towing and towed vehicles with a
maximum authorized total mass greater than 3 500 kg.
The conformance and interoperability test plans are not part of this document.
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 11992-1, Road vehicles — Interchange of digital information on electrical connections between towing
and towed vehicles — Part 1: Physical and data-link layers
ISO 11992-2:2023, Road vehicles — Interchange of digital information on electrical connections between
towing and towed vehicles — Part 2: Application layer for brakes and running gear
ISO 11992-3:2021, Road vehicles — Interchange of digital information on electrical connections between
towing and towed vehicles — Part 3: Application layer for equipment other than brakes and running gear
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 14229-3, Road vehicles — Unified diagnostic services (UDS) — Part 3: Unified diagnostic services on
CAN implementation (UDSonCAN)
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
SAE J1939-21, Data Link Layer
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 11992-1, ISO 14229-1,
ISO 14229-2, ISO 14229-3 and the following 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/
3.1
mandatory
M
keyword indicating an item that is required to be implemented as defined in this document to claim
compliance with this document
[SOURCE: ISO/IEC 14776-113:2002, 3.3.3, modified — The word “standard” has been replaced by
“document”.]
4 Symbols and abbreviated terms
4.1 Symbols
— empty table cell or feature undefined
4.2 Abbreviated terms
CEFF classical extended frame format
ComProfile communication profile
Cvt convention
DA destination address (see SAE J1939-21)
DP data page (see SAE J1939-21)
ECU electronic control unit
EDP extended data page (see SAE J1939-21)
GW gateway
M mandatory
NAT network address translation
P priority (see SAE J1939-21)
PDU protocol data unit
PF PDU format (see SAE J1939-21)
PGN parameter group number (see SAE J1939-21)
PS PDU specific: destination address or group extension (see SAE J1939-21)
USDT unacknowledged segmented data transfer
VIN vehicle identification number
5 Conventions
This document is based on the conventions used in ISO 14229-1 and the underlying OSI Service
Conventions (ISO/IEC 10731) as they apply for diagnostic services.
These conventions specify the interactions between the service user and the service provider. The
information is passed between the service user and the service provider by the service primitives,
which can convey parameters.
6 Vehicle network architecture
Figure 2 shows a possible road train configuration.
Key
1 towing vehicle 0
2 towed vehicle 1
3 towed vehicle 2 (dolly)
4 towed vehicle 3
Figure 2 — Example of a possible road train configuration
Figure 3 shows the vehicle network architecture. The external client 0.0 (external test equipment)
connects to the vehicle's diagnostic connector.
The gateway 0.0 of vehicle 0 connects the in-vehicle network(s) (Figure 3, key a), which is (are)
comprised of, e.g. network(s) Figure 3, keys 4 and 5 with an internal client 0.0 and servers (0.1 to 0.A). It
also connects vehicle 0 to the gateway 1.0 of vehicle 1 with a logical communication link Figure 3, key 2
based on ISO 11992-2 and Figure 3, key 3 based on ISO 11992-3.
Gateway 1.0 of vehicle 1 connects the in-vehicle network(s) (Figure 3, key a), which is (are) comprised
of, e.g. network(s) Figure 3, keys 4 and 5 with servers (1.1 to 1.B). It also connects vehicle 1 to the
gateway 2.0 (3.0, 4.0, 5.0) of vehicle 2 (3, 4, 5) with a logical communication link Figure 3, key 2 based
on ISO 11992-2 and Figure 3, key 3 based on ISO 11992-3.
Key
1 external diagnostic connection: ISO 11898 CAN, ISO 13400 Ethernet
2 ISO 11992-2 messages on ISO 11992-1 communication link
3 ISO 11992-3 messages on ISO 11992-1 communication link
4 ISO 11992-2 messages on ISO 11992-1 communication link
5 ISO 11992-3 messages on ISO 11992-1 communication link
a
In-vehicle network(s): e.g. ISO 11992-2, ISO 11992-3, the ISO 17987 series, the ISO 20794 series, ISO/IEC/
IEEE 8802.3, discrete connection.
Figure 3 — Logical vehicle network architecture
The diagnostic communication addressing scheme is initiated from the client (external or internal) to
one (physical: point to point addressing) or multiple (functional: one to many addressing) servers.
There is no mechanism specified in this document to synchronise multiple clients.
7 Non OSI-layer-related technical requirements overview
Tables 1 and 2 provide an overview about non OSI-layer-related technical requirements and associated
requirement numbers.
Table 1 — Abstract service primitive interface-related technical requirements overview
ASP#.REQ# Technical requirement title
0 Abstract service primitive interface (ASP) definition
0.1 ASP – A_Data.req, A_Data.ind, and A_Data.con service primitive interface
0.2 ASP – Abstract service primitive interface parameters
0.3 ASP – Applicable A_Data service interface parameters
0.4 ASP – Data type definitions
0.5 ASP – Mtype, message type
0.6 ASP – TAtype, target address type
0.7 ASP – AE, address extension
TTabablele 1 1 ((ccoonnttiinnueuedd))
ASP#.REQ# Technical requirement title
0.8 ASP – TA, target address
0.9 ASP – SA, source address
0.10 ASP – Length, length of PDU
0.11 ASP – PDU, protocol data unit
0.12 ASP – Result, result
Table 2 — Application-related technical requirements overview
APP#.REQ# Technical requirement title
8 Application
8.1 APP – Data identifier (DID) definition
8.2 APP – DTC field definition
8.3 APP – DTC functional unit definition
8.4 APP – Negative response code (NRC)
8.5 APP – Communication profile (ComProfile)
8 Abstract service primitive interface (ASP) definition
8.1 ASP – A_Data.req, A_Data.ind, and A_Data.con service primitive interface
The definitions in this document follow the abstract service primitive interface definition in the
ISO 14229-1 specification.
REQ 0.1 ASP – A_Data.req, A_Data.ind, and A_Data.con service primitive interface
The A_Data.req, A_Data.ind, and A_Data.con abstract service primitive interface shall be implemented
as specified in ISO 14229-1.
The service interface defines the service and parameter mapping to the application and the lower OSI
layers.
Figure 4 shows the A_Data.req (request), A_Data.ind (indication) and A_Data.con (confirmation)
service interface.
Key
t time
1 service access point
2 read back from N-layer service provider
Figure 4 — A_Data.req, A_Data.ind, and A_Data.con service interface
8.2 ASP – Service interface parameters
8.2.1 General
The abstract service primitive interface parameters are used by the management of the OSI-layers.
REQ 0.2 ASP – ISO 14229-1 service interface parameters
The service primitive interface parameters shall be implemented as specified in ISO 14229-1.

REQ 0.3 ASP – Applicable A_Data service interface parameters
The A_Data abstract service primitives shall use the service primitive parameters as specified in Table 3.
Table 3 — A_Data abstract service primitive parameters
ASP parameter .req .ind .con Description
A_Mtype
X X — message type [RDiagMixAddr]: remote diagnostics mixed address-
ing
A_AI[TAtype]
X X X target address type [functional, physical]
A_AI[SA]
X X X source address
A_AI[TA]
X X X target address
A_AI[AE]
X X X address extension
A_Length
X X — length of PDU
A_Data
X X — A_PDU data
A_Result
— X X result of service primitive interface execution
8.2.2 ASP – Data type definitions
REQ 0.4 ASP – Data type definitions
The data types shall be in accordance to:
— Enum: 8-bit enumeration,
— Unsigned Byte: 8-bit unsigned numeric value,
— Unsigned Word: 16-bit unsigned numeric value,
— Unsigned Long: 32-bit unsigned numeric value,
— Byte Array: sequence of 8-bit aligned data,
— Bit String: 8-bit binary coded.
8.2.3 ASP – Mtype, message type
REQ 0.5 ASP – Mtype, message type
The Mtype parameter shall be of data type Enum and shall be used to identify the message type and range
of address information included in a service call.
Range: [RDiagMixAddr]
8.2.4 ASP – TAtype, target address type
REQ 0.6 ASP – TAtype, target address type
The TAtype parameter shall be of data type Enum and shall be used to identify the target address type
to be used with the request address.
Range: [physical, functional]
8.2.5 ASP – AE, address extension
REQ 0.7 ASP – AE, address extension
The AE parameter shall be of data type Unsigned Word and shall be used to extend the available address
range for large networks and to encode both, sending and receiving network layer entities of sub-networks
other than the local network where the communication takes place. AE is only part of the addressing
information if Mtype is set to remote diagnostics (RDiagMixAddr).
Range: [0000 to FFFF ]
16 16
8.2.6 ASP – TA, target address
REQ 0.8 ASP – TA, target address
The TA parameter shall be of data type Unsigned Word and shall contain the target address of the node.
Range: [0000 to FFFF ]
16 16
8.2.7 ASP – SA, source address
REQ 0.9 ASP – SA, source address
The SA parameter shall be of data type Unsigned Word and shall contain the source address of the node.
Range: [0000 to FFFF ]
16 16
8.2.8 ASP – Length, length of PDU
REQ 0.10 ASP – Length, length of PDU
The Length parameter shall be of data type Unsigned Byte and shall contain the length of the PDU to
be transmitted/received.
Range: [00 to FF ]
16 16
8.2.9 ASP – PDU, protocol data unit
REQ 0.11 ASP – PDU, protocol data unit
The PDU parameter shall be of data type Byte Array and shall contain the message data (PDU) content
of the request or response message to be transmitted/received.
Range: [00 to FF ]
16 16
8.2.10 ASP – Result, result
REQ 0.12 ASP – Result, result
The Result parameter shall be of data type Bit String and shall contain the status relating to the
outcome of a service execution (request field and response field sequence). If two or more errors are
discovered at the same time, then the application layer entity shall set the appropriate error bit in the
Result parameter.
Range: [OK, Err_AL_Length, Err_TL_PCI_Type, Err_TL_PCI_SF_DL_Value, Err_NL_AddrFmt, Err_DLL_Byte]
The result OK shall be issued to the service user when the service execution is successfully completed.
The OK shall be issued to a service user on both the sender and receiver side.
The ERR_. shall be issued to the service user when an error is detected by a lower layer (provider).
The ERR_. shall be issued to the service user on both, the sender and receiver side.
9 Application
9.1 APP – Addressing of requested information
The functional addressing by towed vehicles may be supported.
9.2 APP – Data identifier (DID) definition
The diagnostic DID(s) are used by the client to request information elements associated to the DID
number.
REQ 8.1 APP – Data identifier (DID) definition
A server/ECU on the ISO 11992 network shall follow the DID(s) as specified in Table 4.
The definition of the DID is specified in ISO 14229-1.
Table 4 — Data Identifier (DID) definition
DID value Definition Cvt
F001 NetworkConfigurationData – BrakesAndRunningGearTrailerRemoteAddress M
F002 NetworkConfigurationData – GeneralPurposeTrailerRemoteAddress M
F00F Supported data identifiers M
F18D SupportedFunctionalUnits M
F190 VIN M
TTabablele 4 4 ((ccoonnttiinnueuedd))
DID value Definition Cvt
F197 SystemNameOrEngineType M
9.3 APP – DTC field definition
The DTC field contains additional information related to a reported DTC.
REQ 8.2 APP – DTC field definition
A server/ECU on the ISO 11992 network shall follow the DTC field definition as specified in Table 5.
Table 5 — DTC field definition
Field name Definition Cvt
DTCSeverity This field contains severity information of a given DTC, as specified in ISO 14229- M
1.
DTCClass This field contains class information of a given DTC and shall be set to 0 0000 . M
DTCFunctionalUnit This field contains the functional unit identifier of a given DTC, as specified in M
Table 6.
DTCFormatIdentifier This field contains the ISO_11992-4_DTCFormat of a given DTC, as specified in M
ISO 14229-1.
DTCRecord This field contains the base DTC number in the DTCRecord [high byte, middle M
byte], as specified in ISO 14229-1.
DTCFailure type This field contains the failure type information of a given DTC in the DTCRecord M
[low byte], as specified in ISO 14229-1.
StatusOfDTC This field contains the status flags of a given DTC, as specified in ISO 14229-1. M
9.4 APP – DTC functional unit definition
The DTC functional unit provides information about the electronic system/device the reported DTC
belongs to.
REQ 8.3 APP – DTC functional unit definition
A server/ECU on the ISO 11992 network shall follow the DTC functional unit as specified in Table 6.
Table 6 — DTC functional unit definition
DTC functional unit name Functional unit identifier
Telematics (GPS, GSM) 00
General braking 01
ABS 02
EBS 03
Stability support 04
Retarder 05
Tyre 06
Suspension 07
Axle 08
Lift axle 09
Steering axle 0A
General body application 0B
Lights 0C
TTabablele 6 6 ((ccoonnttiinnueuedd))
DTC functional unit name Functional unit identifier
Power take-off 0D
Back-up assistance (rear obstacle detection, camera, etc.) 0E
Security 0F
Loading ramp application (lift, ramp control, etc.) 10
Temperature control (cooler, heater) 11
Temperature recorder 12
Auxiliary power unit 13
Local (towing, towed) vehicle communication 14
On-board diagnostic/data recorder 15
Towing vehicle power supply 16
Towed vehicle battery power supply 17
Hitch (towed vehicle coupling) 18
Towing vehicle to towed vehicle communication (ISO 11992) 19
Reserved 20 to FE
16 16
Manufacturer specific FF
9.5 APP – Negative response code (NRC)
The diagnostic NRC(s) specifies the reason for a diagnostic service request to be rejected by a server.
REQ 8.4 APP – Negative response code (NRC)
A server/ECU on the ISO 11992 network shall follow the NRCs as specified in Table 7.
The NRCs specified in this document are a subset of the specification in ISO 14229-1. The definitions of
the NRCs in Table 7 are specified in ISO 14229-1.
Table 7 — Negative response codes (NRC)
NRC value Definition Cvt
10 GeneralReject M
11 ServiceNotSupported M
12 SubFunctionNotSupported M
21 BusyRepeatRequest M
31 RequestOutOfRange M
78 RequestCorrectlyReceived-ResponsePending M
9.6 APP – Communication profile (ComProfile)
REQ 8.5 APP – Communication profile (ComProfile)
The application(s) in the server/ECU utilizing the ISO 11992 network shall follow the application timing
parameters as specified in Table 8 and the parameter as specified in Table 9.
Table 8 — Application timing ComProfile parameters
Parameter Minimum value Maximum value Definition
[ms] [ms]
t 0 50
see ISO 14229-2
P2_Server
Δt 0 200
see ISO 14229-2
P2
TTabablele 8 8 ((ccoonnttiinnueuedd))
Parameter Minimum value Maximum value Definition
[ms] [ms]
t 250 —
see ISO 14229-2
P2_Client
t 0 5 000
see ISO 14229-2
P2*_Server
t 5 200 —
see ISO 14229-2
P2*_Client
Table 9 — Application message ComProfile parameter
Parameter Minimum Maximum Definition
value value
C 01 FF
application protocol data unit (message) length
A_PDU_Length 16 16
10 OSI-layers-related technical requirements overview
Table 10 provides an overview about OSI-layers-related technical requirements and associated
requirement numbers.
Table 10 — OSI-layers-related technical requirements overview
OSI#.REQ# Technical requirement title
7 Application layer
7.1 AL – UDSonCAN-specific requirements
7.2 AL – No UDSonCAN-specific requirements
7.3 AL – Not supported requirement
7.6 AL – Applicable ReadDtcInformation service subFunctions
7.7 AL – Application layer communication profile (ComProfile)
6 Presentation layer
--- No requirement statement in this document.
5 Session layer
5.1 SL – Service primitive interface parameter definition
5.2 SL – S_Data.req, S_Data.ind, and S_Data.con service interface
5.3 SL – Service primitive interface AL to SL parameter mapping
5.4 SL – Session layer communication profile (ComProfile)
4 Transport layer
4.1 TL – USDT service primitive interface parameter definition
4.2 TL – T_Data.req, T_Data.ind, and T_Data.con service interface
4.3 TL – Service primitive interface SL to TL parameter mapping
4.4 TL – Transport protocol
4.5 TL – Transport layer communication profile (ComProfile)
3 Network layer
3.1 NL – Service primitive interface parameter definition
3.2 NL – N_Data.req, N_Data.ind, and N_Data.con service interface
3.3 NL – Service primitive interface TL to NL parameter mapping
3.4 NL – Network layer services
3.5 NL – Network layer communication profile (ComProfile)
3.6 NL – Diagnostic CAN identifier configuration
3.7 NL – Dynamic network address assignment – NL – address assignment of TTN_1 and TTN_3
TTabablele 1 100 ((ccoonnttiinnueuedd))
OSI#.REQ# Technical requirement title
3.8 NL – Dynamic network address assignment – NL – address assignment of TTN_2 and TTN_4
3.9 NL – Static network address assignment – NL – address assignment of gateway application,
IVN_1, and IVN_2
3.10 NL – Static network address assignment – NL – server address assignment of IVN_1 and
IVN_2
3.11 NL – Network address translation – from GW TTN_1 to GW TTN_3 and GW TTN_2 to GW
TTN_4
3.12 NL – Network address translation – from GW TTN_1/TTN_2 to server on IVN_1/IVN_2
3.13 NL – Network address translation – server address mapping
3.14 NL – Network address translation – from GW IVN_1/IVN_2 to GW TTN_1/TTN_2
3.15 NL – Network address translation – from GW TTN_3 to GW TTN_1 and GW TTN_4 to GW
TTN_2
3.16 NL – Diagnostic communication port (DCP)
2 Data link layer
2.1 DL – Service primitive interface parameter definition
2.2 DL – L_Data.req, L_Data.ind, and L_Data.con service interface
2.3 DL – Service primitive interface NL to DL parameter mapping
2.4 DL – CAN data frame – extended frame format
2.5 DL – CAN data frame – CAN remote frame
2.6 DL – Data link layer communication profile (ComProfile)
1 Physical layer
1.1 PHY – ISO 11992-1
11 Application layer
11.1 AL – Diagnostic services overview
The purpose of Table 11 is to reference ISO 14229-1, ISO 14229-2 and ISO 14229-3 services as they are
applicable for this document. Table 11 contains the applicable diagnostic services.
REQ 7.1 AL – UDSonCAN specific requirements
Services that are marked “UDSonCAN-specific requirements” (ISO 14229-3) shall be implemented as
specified in the referenced subclause number in accordance with Table 11 "Reference" column.

REQ 7.2 AL – No UDSonCAN-specific requirements
Services specified in Table 11 that are marked “No UDSonCAN-specific requirements” (ISO 14229-3)
shall follow ISO 14229-1, ISO 14229-2 and ISO 14229-3 with no additional restrictions.

REQ 7.3 AL – Not supported requirement
Services specified in Table 11 that are marked “Not supported” shall not be implemented.
Table 11 — 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 UDSonCAN-specific requirements see 11.2
TesterPresent No UDSonCAN-specific requirements —
Authentication Not supported —
SecuredDataTransmission No UDSonCAN-specific requirements —
ControlDTCSetting No UDSonCAN-specific requirements —
ResponseOnEvent Not supported —
LinkControl Not supported —
Data transmission ReadDataByIdentifier UDSonCAN-specific requirements see 11.3
ReadMemoryByAddress No UDSonCAN-specific requirements —
ReadScalingDataByIdentifier No UDSonCAN-specific requirements —
ReadDataByPeriodicIdentifier Not supported —
DynamicallyDefineDataIdenti- No UDSonCAN-specific requirements —
fier
WriteDataByIdentifier No UDSonCAN-specific requirements —
WriteMemoryByAddress No UDSonCAN-specific requirements —
Stored data trans- ReadDTCInformation UDSonCAN-specific requirements see 11.4
mission
ClearDiagnosticInformation UDSonCAN-specific requirements —
Input/output InputOutputControlByIdentifier No UDSonCAN-specific requirements —
control
Remote activation RoutineControl No UDSonCAN-specific requirements —
of routine
Upload/download RequestDownload No UDSonCAN-specific requirements —
RequestUpload No UDSonCAN-specific requirements —
TransferData No UDSonCAN-specific requirements —
RequestTransferExit No UDSonCAN-specific requirements —
RequestFileTransfer No UDSonCAN-specific requirements —
11.2 AL – CommunicationControl
The CommunicationControl service is used to enable/disable normal communication on the network.
REQ 7.4 AL – CommunicationControl
The disabling of normal communication on the ISO 11992-2 network during normal operating condi-
tions, e.g. driving, between towing and towed vehicles shall not be permitted.
11.3 AL – ReadDataByIdentifier
The ReadDataByIdentifier service is used to retrieve static and dynamic data for diagnostic purposes.
REQ 7.5 AL – ReadDataByIdentifier
The number of dataIdentifiers (DIDs) in a ReadDataByIdentifier request message shall be limited to
one DID.
11.4 AL – ReadDtcInformation
11.4.1 AL – General
The ReadDtcInformation service allows a client to read the status of the server’s resident DTC
information from any server or group of servers on a vehicle's network, as specified in ISO 14229-1.
11.4.2 AL – Applicable ReadDtcInformation service subFunctions
The ReadDtcInformation service supports the following subFunctions.
REQ 7.6 AL – Applicable ReadDtcInformation service subFunctions
Each client and server shall support the ReadDtcInformation service with the following subFunctions,
as specified in ISO 14229-1:
— retrieve the number of DTCs matching a client-defined severity mask:
reportType = reportNumberOfDTCBySeverityMaskRecord;
— retrieve the list of DTCs matching a client-defined severity mask record:
reportType = reportDTCBySeverityMaskRecord;
— retrieve the severity information for a client-defined DTC:
reportType = reportSeverityInformationOfDTC.
Other subFunctions, as specified in ISO 14229-1, can be supported.
11.5 AL – Application layer communication profile (ComProfile)
REQ 7.7 AL – Application layer communication profile (ComProfile)
The application layer in the server/ECU utilizing the ISO 11992 network shall follow the application
layer timing parameters as specified in Table 12.
Table 12 — Application layer timing ComProfile parameters
Parameter Definition Minimum value
...