ISO 11992-4:2014

INTERNATIONAL ISO
STANDARD 11992-4
Second edition
2014-05-01
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 2014
© ISO 2014
All rights reserved. Unless otherwise specified, 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
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2014 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 2
5 General definitions . 3
5.1 Conventions . 3
5.2 Network components . 3
5.3 Use case definitions . 3
5.4 Diagnostic applications. 4
5.5 Vehicle network architecture . 5
5.6 Diagnostic communication channels . 6
6 Unified diagnostic services implementation . 7
6.1 General . 7
6.2 Overview on diagnostic services . 7
6.3 Non-applicable or restricted services . 8
6.4 Basic diagnostic services . 9
6.5 Enhanced diagnostic services .12
7 Application layer requirements .12
7.1 Application layer services .12
7.2 Application layer protocol .12
7.3 Timing definition .13
8 Presentation layer requirements .14
9 Session layer requirements .14
10 Transport layer requirements.14
10.1 General .14
10.2 Transport layer service parameters .14
11 Network layer requirements.15
11.1 General .15
11.2 Message routing .15
11.3 Establishing, maintaining, and terminating of connections .16
11.4 Diagnostic communication channels (DCC).16
11.5 Mixed addressing network layer service parameter .17
11.6 Subnet addressing network layer service parameter.18
11.7 Network layer protocol timing .22
12 Data link layer requirements
...............................................................................................................................................................22
12.1 General .22
12.2 Mapping for mixed addressing .22
12.3 Mapping for subnet addressing .23
13 Physical layer requirements .23
Annex A (normative) Basic diagnostic service parameters .24
Annex B (normative) Address definitions .29
Annex C (informative) Message routing examples.31
Bibliography .35
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 on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical Barriers
to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical
and electronic equipment.
This second edition cancels and replaces the first edition (ISO 11992-4:2005), which has been technically
revised. It also incorporates ISO 11992-4:2005/Cor1:2006.
ISO 11992 consists of the following parts, under the general title Road vehicles — Interchange of digital
information on electrical connections between towing and towed vehicles:
— Part 1: Physical layer and data-link layers
— Part 2: Application layer for brakes and running gear
— Part 3: Application layer for equipment other than brakes and running gear
— Part 4: Diagnostic communication
iv © ISO 2014 – All rights reserved

Introduction
This part of ISO 11992 has been established in order to define the implementation of a diagnostic data
interchange between a commercial vehicle and its towed vehicle(s), including communication between
towed vehicles, using a Controller Area Network (CAN) data link according to ISO 11992-1 and based on
the definitions for unified diagnostic services and their implementation on CAN given in the ISO 14229
and ISO 15765 document series.
To achieve this, the document is based on the Open Systems Interconnection (OSI) Basic Reference
Model, in accordance with ISO/IEC 7498-1 and ISO/IEC 10731, which structures the 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) based on this document are broken into the following layers
according to Table 1:
— application layer (layer 7), based on ISO 11992-4, ISO 14229-1, and ISO 14229-3;
— presentation layer (layer 6), vehicle manufacturer/system supplier specific or ISO 22901, ODX;
— session layer services (layer 5), based on ISO 11992-4 and ISO 14229-2;
— transport layer services (layer 4), based on ISO 11992-4 and ISO 15765-2;
— network layer services (layer 3), based on ISO 11992-4 and ISO 15765-2;
— data link layer (layer 2), specified in ISO 11898-1;
— physical layer (layer 1), specified in ISO 11992-1.
This document does not include any redundant information of the documents listed in this introduction.
It focuses on
— additional requirements specific to the implementation of UDS on an ISO 11992 network and
— specific restrictions in the implementation of UDS on an ISO 11992 network.
In case of any contradictions, the definitions given in this document take precedence.
Table 1 — International Standards applicable to the OSI layers
Applicability OSI seven layers Diagnostics services on the communication between the com-
mercial vehicles and their towed vehicles
seven layers application (layer 7) ISO 11992-4, ISO 14229-1, ISO 14229-3
according to
presentation (layer 6) vehicle manufacturer specific or ISO 22901
ISO/IEC 7498-1
and ISO/ session (layer 5) ISO 11992-4, ISO 14229-2
IEC 10731
transport (layer 4) ISO 11992-4, ISO 15765-2
network (layer 3) ISO 11992-4, ISO 15765-2
data link (layer 2) ISO 11898-1
physical (layer 1) ISO 11992-1
INTERNATIONAL STANDARD ISO 11992-4:2014(E)
Road vehicles — Interchange of digital information
on electrical connections between towing and towed
vehicles —
Part 4:
Diagnostic communication
1 Scope
This part of ISO 11992 specifies the diagnostic communication over a CAN between the towing and
towed vehicle(s) of a commercial vehicle and its trailer(s), according to ISO 11992-2 or ISO 11992-3,
which allows a diagnostic tester (client) to control diagnostic functions in an on-vehicle ECU (server)
embedded in a road vehicle using the communication gateways between the vehicles.
It defines the data link layer’s specific implementation of the unified diagnostic communication
requirements, mainly given in the ISO 14229 and ISO 15765 document series by additional requirements
and restrictions specific to the implementation of UDS on an ISO 11992 network.
This part of ISO 11992 does not apply to any non-diagnostic message transmission use of the
communication data link between two ECUs.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. 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 14229-1:2013, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and
requirements
ISO 14229-2:2013, Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
ISO 14229-3:2012, Road vehicles — Unified diagnostic services (UDS) — Part 3: Unified diagnostic services
on CAN implementation (UDSonCAN)
ISO 15031-6, Road vehicles — Communication between vehicle and external equipment for emissions-
related diagnostics — Part 6: Diagnostic trouble code definitions
ISO 15765-1:2011, Road vehicles — Diagnostic communication over Controller Area Networks (DoCAN) —
Part 1: General information and use case definition
ISO 15765-2:2011, Road vehicles — Diagnostic communication over Controller Area Networks (DoCAN) —
Part 2: Transport protocol and network layer services
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, ISO 15765-1, and ISO 15765-2 apply.
4 Symbols and abbreviated terms
For the purposes of this International Standard, the following abbreviated terms apply.
A_AE application layer address extension
A_Mtype application layer message type
A_SA application layer source address
A_TA application layer target address
BS block size
CAN Controller Area Network
CAN-ID CAN identifier
Cvt convention
DCC diagnostic communication channel
DID data identifier
DLC data length code
DP data page
DTC Diagnostic Trouble Code
ECU Electronic Control Unit
EDP extended data page
FS flow status
N_AE network layer address extension
N_AI network layer address information
N_SA network layer source address
N_TA network layer target address
N_TAtype network layer target address type
N_WFTmax network layer maximum number of wait frames
N_Subnet width of the subnet mask used for subnet addressing
P priority
PDU Protocol Data Unit
PF parameter format
PGN parameter group number
PS parameter specific
SID service identifier
STmin separation time
2 © ISO 2014 – All rights reserved

5 General definitions
5.1 Conventions
This International Standard is based on the conventions used in ISO 14229-1 and the underlying OSI
Service Conventions (ISO/IEC 10731:1994) 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.
5.2 Network components
5.2.1 Diagnostic network
The diagnostic network, as a whole, contains all clients and servers that can communicate with each
other on the different vehicles of a road train, as well as the diagnostic gateways between the vehicles.
5.2.2 Diagnostic subnetwork
All the clients and servers of a subnetwork are connected to the same vehicle’s diagnostic network.
Subnetworks are separated by the gateways between the vehicles.
5.2.3 Diagnostic gateway
A diagnostic gateway is a node in the network that is physically connected to two (or more) subnetworks
and has the ability to transfer diagnostic messages between the subnetworks.
5.3 Use case definitions
5.3.1 General
This section lists the individual use cases that will be covered by the diagnostic communication over the
ISO 11992 protocol at the following areas:
— vehicle/ECU engineering (development);
— vehicle/ECU manufacturing (production plant, assembly line);
— service (dealership, aftermarket repair shop);
— retrieval of information between connected vehicles.
The following use cases are supported by the communication protocol.
5.3.2 Use case 1 — Driver information
Driver information specifies the use case to enable an in-vehicle information retrieval system at the
commercial vehicle to qualify the readiness of the towed vehicle(s).
In this case, usually an information-retrieval entity is installed in the commercial vehicle that gets data
from the various ECUs located in the road train, including the towed vehicle(s), and forwards relevant
information about the roadworthiness of the road train to the driver.
5.3.3 Use case 2 — Vehicle inspection and repair
Vehicle inspection and repair specifies the use case to enable external test equipment connected to the
road train to qualify the readiness of any vehicle and to perform vehicle diagnostic fault tracing as part
of a repair.
In this case, usually the external test equipment is connected to the commercial vehicle and requests
data from the road train that can be qualified to determine the readiness of the vehicle(s) or to perform
vehicle diagnostic fault tracing as part of a repair.
5.3.4 Use case 3 — ECU/vehicle software reprogramming
ECU/vehicle software reprogramming specifies the use case to reprogram the ECU(s) of a towed vehicle
through its data communication channel.
In this case, usually the external programming equipment is connected to the commercial vehicle or
directly to a towed vehicle and uses diagnostic communication to (re)program or configure ECU(s)
located in the towed vehicle.
5.3.5 Use case 4 — ECU/vehicle assembly line inspection and repair
ECU/vehicle assembly line inspection and repair specifies the use case to enable an external test system
connected to a towed vehicle to support the assembly line inspection and repair of the towed vehicle’s
ECU systems.
In this case, usually the external test equipment is connected to the commercial vehicle or directly to
the towed vehicle and uses diagnostic services to determine the readiness of the vehicle(s) or to perform
vehicle diagnostic fault tracing as part of a repair.
5.3.6 Use case 5 — Multipurpose data transfer between vehicles
Multipurpose data transfer between vehicles specifies the use case to enable the ECU(s) in any vehicle of
the road train to retrieve information from other vehicle’s ECU(s).
In this case, an ECU can use diagnostic services to retrieve information from another ECU for various
purposes.
5.4 Diagnostic applications
The diagnostic applications are divided into two types.
— Basic diagnostics:
The purpose of the basic diagnostics is to provide the vehicle’s independent identification and
diagnostic information. All basic diagnostic functions and services shall be provided under all
operation conditions in the default diagnostic session without the need for specific access rights.
— Enhanced diagnostics:
The support and the conditions, under which the enhanced diagnostic functions and services
are provided, are manufacturer/system-supplier specific. It is in the responsibility of the
manufacturer/system supplier to secure a server against unauthorized access and to ensure
performance and safe operation in all operation modes allowing enhanced diagnostics.
The functions, services, and protocols of the OSI layers 1 to 4 shall be identical for basic diagnostics and
enhanced diagnostics. For OSI layers 5 to 7, the implementation of the functions, services, and protocols
are varying according to the definitions given in this document.
4 © ISO 2014 – All rights reserved

5.5 Vehicle network architecture
This document supports the diagnostic communication between a commercial vehicle and its towed
vehicles as illustrated in Figure 1.
Key
1 truck/commercial vehicle
2 trailer/towed vehicle #1
3 dolly/towed vehicle #2
4 trailer/towed vehicle #3
Figure 1 — Example of a possible road train configuration
Subnet definitions shall be as follows.
— The commercial vehicle’s logical network shall expand over
— all servers and clients located at the commercial vehicle and
— the towed vehicle gateways.
— The physical network segments between each towing and towed vehicle shall be part of the local
logical network of the commercial vehicle and share the logical addressing scheme of the commercial
vehicle.
— Each towed vehicle shall implement its own local logical network(s) with its own addressing scheme.
— Server and client entities that are not located at the same logical network shall be addressed and
identified by means of remote network addressing.
Details about the used addressing scheme are given in Clause 11 (Network layer requirements).
Figure 2 shows an example of the vehicle network architecture.
Figure 2 — Vehicle network architecture example
5.6 Diagnostic communication channels
This document specifies the diagnostic requests sent from any of the vehicles to any other vehicle of a
road train. For the communication between those vehicles, defined diagnostic communication channels
(DCC) shall be used as specified in Clause 11.
The defined communication channels shall be used as follows.
— For the communication between a client located in the commercial vehicle network and a server
located in a towed vehicle, network DCC11, DCC12, DCC21, and DCC22 shall be used.
— For the communication between a client located in a towed vehicle network and a server located
elsewhere in the road train, DCCX shall be used.
The address mapping between the vehicle networks shall be implemented in the gateway entities and
is specified in this document. Address mapping at the vehicle’s local networks is left open to the system
builder. Examples that are more detailed are given in Annex C.
EXAMPLE Diagnostic communication between a client (test equipment) located at the commercial vehicle
and a server (ECU) located at towed vehicle #1.
An example is given in Figure 3 and Table 2.
Figure 3 — Application layer address mapping example
6 © ISO 2014 – All rights reserved

Table 2 — Application layer address mapping example
Message A_SA A_TA A_AE
The test equipment sends a remote diagnostic request message. 241 200 62
The gateway at the client side receives the message and forwards it onto the CAN 241 200 62
network between the towing and towed vehicles.
The gateway at the server side receives the message and forwards it onto the server’s 1 62 241
vehicle local bus.
The remote server receives the message and sends back a diagnostic response. 62 1 241
The gateway at the server side receives the message and forwards it onto the CAN 200 241 62
network between the towing and towed vehicles.
The gateway at the client side receives the message and forwards it onto the client’s 200 241 62
vehicle local bus.
6 Unified diagnostic services implementation
6.1 General
This clause defines how the diagnostic services as defined in ISO 14229-1 apply to the diagnostics on
ISO 11992. For each applicable service, the applicable sub-function and data parameters are defined.
6.2 Overview on diagnostic services
The purpose of Table 3 is to reference all unified diagnostic services, as they are applicable for an
implementation of UDS on ISO 11992. The table contains the sum of all applicable services. Certain
applications using this document can restrict the number of useable services and can categorize them in
certain application areas/diagnostic sessions (default session, extended session, etc.).
Table 3 — Overview of applicable ISO 14229-1 Unified Diagnostic Services
Diagnostic service name SID Specification Document refer-
(ISO 14229-1) value ence
Diagnostic and Communication Management Functional Unit
DiagnosticSessionControl 10 No specific requirements —
ECUReset 11 No specific requirements —
SecurityAccess 27 No specific requirements —
CommunicationControl 28 Restricted use 6.3
TesterPresent 3E No specific requirements —
AccessTimingParameters 83 Not supported 6.3
SecuredDataTransmission 84 No specific requirements —
ControlDTCSetting 85 No specific requirements —
ResponseOnEvent 86 Not supported 6.3
LinkControl 87 Not supported 6.3
Data Transmission Functional Unit
ReadDataByIdentifer 22 Data link layer specific definitions exist 6.4.3
ReadMemoryByAddress 23 No specific requirements —
ReadScalingDataByIdentifier 24 No specific requirements —
ReadDataByPeriodicIdentifier 2A Not supported 6.3
DynamicallyDefineDataIdentifier 2C No specific requirements —
WriteDataByIdentifier 2E No specific requirements —
WriteMemoryByAddress 3D No specific requirements —
Stored Data Transmission Functional Unit
ReadDTCInformation 19 Data link layer specific definitions exist 6.4.2
ClearDiagnosticInformation 14 Data link layer specific definitions exist 6.4.2
Input/output Control Functional Unit
InputOutputControlByIdentifier 2F No specific requirements —
Remote Activation Of Routine Functional Unit
RoutineControl 31 No specific requirements —
Upload/Download Functional Unit
RequestDownload 34 No specific requirements —
RequestUpload 35 No specific requirements —
TransferData 36 No specific requirements —
RequestTransferExit 37 No specific requirements —
6.3 Non-applicable or restricted services
The following services are not applicable for the implementation on ISO 11992 and are not within the
scope of this document or can be used under restrictions.
— CommunicationControl
Disabling the normal communication specified in ISO 11992-2 between towing and towed vehicles
[5]
is not permitted due to the requirements given by UNECE Regulation 13.
8 © ISO 2014 – All rights reserved

— AccessTimingParameter
This service is not applicable as there is no use case on a CAN-based system.
— ResponseOnEvent
This service is not supported as there is no specification given for the communication between the
gateways for that type of communication.
— LinkControl
This service shall not be supported during the communication between the towing and towed
vehicles as it is not supported by a data link based on ISO 11992-1.
— ReadDataByPeriodicIdentifier
This service is not supported as there is no specification given for the communication between the
gateways for that type of communication.
6.4 Basic diagnostic services
6.4.1 Services
Within the scope of basic diagnostic services, the following diagnostic services shall be supported:
— ReadDTCInformation, as specified in 6.4.2;
— ReadDataByIdentifier, as defined in 6.4.3.
The diagnostic services specification includes tables that list the diagnostic services and respective
service primitive parameters. For all services and service primitive parameters, the presence is specified
by the convention values (Cvt) in Table 4.
Table 4 — Diagnostic service primitive parameter conventions
Cvt Name Description
M Mandatory The service or service primitive parameter has to be present.
C Conditional The service or service primitive parameter can be present, based on certain crite-
ria (e.g. due to a certain sub-function).
S Selection The service or service primitive parameter is mandatory (unless otherwise speci-
fied) and is a selection from a given list of services or service primitive param-
eters.
U User option The service or service primitive parameter can or cannot be present, depending
on the dynamic usage by the user.
NOTE A service identifier marked as mandatory does not imply that this service has to be supported.
6.4.2 ReadDTCInformation service
6.4.2.1 General description
This service allows a client to read the status of the server’s resident Diagnostic Trouble Code (DTC)
information from any server or group of servers within a vehicle, as defined in ISO 14229-1. Within the
scope of basic diagnostics, this service shall allow the client to do the following:
— retrieve the number of DTCs matching a client-defined severity mask;
— retrieve the list of DTCs matching a client-defined severity mask record;
— retrieve the severity information for a client-defined DTC.
Other sub-functions can be supported within the scope of enhanced diagnostics.
6.4.2.2 Request message sub-function definition
The server shall support the request and response service messages as defined in ISO 14229-1 for the
sub-functions listed in Table 5.
Table 5 — ReadDTCInformation sub-functions for basic diagnostics
Value Definition Cvt
07 reportNumberOfDTCBySeverityMaskRecord M
This parameter specifies that the server shall transmit to the client the number of
DTCs matching a client-defined severity mask record.
08 reportDTCBySeverityMaskRecord M
This parameter specifies that the server shall transmit to the client a list of DTCs and
corresponding statuses matching a client-defined severity mask record.
09 reportSeverityInformationOfDTC U
This parameter specifies that the server shall transmit to the client the severity
information of a specific DTC specified in the client request message.
6.4.2.3 Request and response message data parameter definition
The server shall support the definition of the message data parameter as given in ISO 14229-1 with the
implementation specific requirements given in Table 6.
10 © ISO 2014 – All rights reserved

Table 6 — Message data parameter definition
Definition
DTCAndSeverityRecord
This parameter record contains one or more groupings of DTCSeverity, DTCFunctionalUnit, DTCHigh-
Byte, DTCMiddleByte, DTCLowByte, and statusOfDTC of ISO 11992-4_DTCFormat with the details
given in A.3.
DTCFormatIdentifier
This 1-byte parameter value defines the format of a DTC reported by the server and shall have these
values:
— 0 to 2 (reserved by ISO 14229-1, not supported);
— 3 (ISO 11992–4_DTCFormat);
— 4 to 255 (reserved by ISO 14229-1, not supported).
DTCMaskRecord [DTCHighByte, DTCMiddleByte, DTCLowByte]
The decoding of the DTCHighByte, DTCMiddleByte, and DTCLowByte shall be according to this Inter-
national Standard’s specification. This format is identified by the DTCFormatIdentifier = ISO 11992-4_
DTCFormat.
Definitions are given in A.3.1.
DTCSeverityMaskRecord [DTCSeverityMask, DTCStatusMask]
DTCSeverityMaskRecord is a 2-byte value containing the DTCSeverityMask and the DTCStatusMask
as given A.3.2.
FunctionalGroupID
The FunctionalGroupID parameter shall be supported as given in A.3.5.
6.4.3 ReadDataByIdentifier service
6.4.3.1 General
This service shall be used to request information from a server identified by a dataIdentifier. Within the
scope of basic diagnostics, only one dataIdentifier shall be present in a request message.
6.4.3.2 Request message data parameter definition
The service parameter of the ReadDataByIdentifier service request shall be supported for basic
diagnostics as specified in Table 7 with the dataIdentifier specified in A.2.1.
Table 7 — ReadDataByIdentifier request parameters
A_Data byte Parameter name Cvt Value
#1 ReadDataByIdentifier request service identifier M 22
dataIdentifier[] = {
#2 Byte 1 (MSB) M 00 -FF
16 16
#3 Byte 2 (LSB)} M 00 -FF
16 16
6.4.3.3 Response message data parameter definition
The service parameter of the ReadDataByIdentifier service response shall be supported for basic
diagnostics as specified in Table 8 with the dataIdentifier and dataRecord as specified in A.2.1.
Table 8 — ReadDataByIdentifier positive response parameters
A_Data byte Parameter name Cvt Value
#1 ReadDataByIdentifier response service identifier M 62
dataIdentifier[] = {
#2 byte 1 (MSB) M 00 -FF
16 16
#3 byte 2 (LSB)} M 00 -FF
16 16
dataRecord[] = {
#4 data#1 M 00 -FF
16 16
: : : :
#(m-1)+4 data#m} U 00 -FF
16 16
6.5 Enhanced diagnostic services
Within the scope of enhanced diagnostics, all services defined to be applicable in 6.2 with the exclusions
given in 6.3 can be used as specified in ISO 14229-3.
7 Application layer requirements
7.1 Application layer services
The application layer services, as defined in ISO 14229-1 for client-server based systems, shall be used to
perform functions such as test, inspection, monitoring, diagnosis, or programming of on-board vehicle
servers.
7.2 Application layer protocol
The application layer protocol, as defined in ISO 14229-1, shall be used with the parameters defined in
Table 9 at peer entity networks.
12 © ISO 2014 – All rights reserved

Table 9 — Application layer parameters
Parameter Definition Data range
A_Mtype application layer message remote diagnostics
type
A_SA local address of the client any allowed client address except e.g. the specified
request
addresses given in Table B.1
A_SA local gateway address at any gateway address according to the definitions given in
response
the vehicle the server is Table B.3
located on
A_TA local gateway address at any gateway address according to the definitions given in
request
the vehicle the server is Table B.3
located on
A_TA local address of the client any allowed client address except e.g. the specified
response
addresses given in Table B.1
A_Length length of data to be trans- 0 to 255
mitted/received
A_AE remote address of the any allowed server address within the server’s vehicle
request
server network
A_AE remote address of the any allowed server address within the server’s vehicle
response
server network
7.3 Timing definition
7.3.1 General
This sub-clause specifies the parameters for the timing of messages and how they apply to a client and
a server.
7.3.2 Message timing parameter values
The message timing parameter values shall be in accordance with ISO 14229-2 and the additional
requirements specified in Table 10.
Table 10 — Message timing parameters
Timing Definition Minimum Maximum
parameter
ΔP2 The ΔP2 parameter is defined to be the worst-case system 0 ms 200 ms
network design-dependent message transmission delays, such
as delays introduced by the gateways between the towing and
towed vehicles and the busload arbitration delay.
P2 The P2 parameter is a performance requirement for the 0 ms 50 ms
server server
server/ECU to start with the response message after the recep-
tion of a request message.
PP22+Δ
P2 250 ms —
server,max max
client
P2* The P2* parameter is a performance requirement for the 0 ms 5 000 ms
server server
server to start with the response message after the transmis-
sion of a negative response message with the NRC RCRRP.
PP22* +Δ
P2* 5 200 ms —
server,max max
client
7.3.3 Unsolicited response messages
Unsolicited response messages are not applicable for this document.
8 Presentation layer requirements
The presentation layer requirements are in the responsibility of the vehicle manufacturer/system
supplier.
9 Session layer requirements
The session layer requirements are specified in ISO 14229-2.
10 Transport layer requirements
10.1 General
The transport layer specification is given in ISO 15765-2 with the following amendments. In case of
differences, the specifications of this part of ISO 11992 shall have precedence.
10.2 Transport layer service parameters
10.2.1 FirstFrame.DataLength (FF.DL)
The parameter FirstFrame.DataLength (FF.DL) determines the number of message data bytes of a
segmented multiframe message.
Table 11 — Definition of BS values
Value Description
0 to 6 invalid
16 16
7 to FF DataLength (DL) range: 7 to 255
16 16
FF to 3FF reserved by document
16 16
NOTE The USDT protocol on the CAN allows a maximum of 4 095 MessageData bytes. For the diagnostic
communication between the towing and towed vehicles, the length is limited to 255 bytes.
10.2.2 BlockSize (BS)
The parameter BlockSize (BS) shall be used by the peer entity of the receiving network layer in the flow
control frame to request the transmission of a maximum number of consecutive frames by the peer
entity of the sending network layer without an intermediate flow control frame.
Table 12 — Definition of BS values
Value Description
0 reserved by document
1 to 0F BlockSize (BS) range: 1 to 15
16 16
10 to FF reserved by document
16 16
The value BS = 0, i.e. no intermediate flow control frames, shall not be used.
14 © ISO 2014 – All rights reserved

10.2.3 SeparationTime (STmin)
The parameter SeparationTime (STmin) shall be used by the peer entity of the receiving network layer
in the FlowControl frame to request a minimum time gap between the transmissions of consecutive
frames from the peer entity of the sending network layer as defined in Table 13.
Table 13 — Definition of STmin values
Value Description
0 to 09 invalid
16 16
This range of values are not applicable and shall not be used.
0A to 7F SeparationTime (STmin) range: 10 ms to 127 ms
16 16
The units of STmin in the range 10 to 127 (0A – 7F ) are
16 16
absolute milliseconds (ms).
80 to FF reserved
16 16
This range of values is reserved by this part of ISO 11992.
10.2.4 FlowStatus (FS)
The FlowStatus (FS) shall be used by the receiving network layer peer entity in the FlowControl frame
to indicate to the sender whether it is ready to receive < BS > consecutive frames sent with a minimum
of < STmin > separation time.
Table 14 — Definition of FlowStatus values
Value Description
0000 continue to send (CTS)
0001 wait (WT)
0010 overflow
10.2.5 Maximum number of FC.Wait frame transmissions (N_WFTmax)
The local entity parameter’s maximum number of FC.Wait frame transmissions, N_WFTmax, defines the
allowed maximum number of consecutive FlowControl frames with FlowStatus set to wait.
Table 15 — Definition of N_WFTmax values
Value Description
0A N_WFTmax value: 10
16 10
11 Network layer requirements
11.1 General
This section specifies the network layer requirements on the ISO 11992 data link. Network layer
specification is given in ISO 15765-2 with the following amendments. In case of differences, the
specifications of this part of ISO 11992 shall have precedence.
11.2 Message routing
The network layer entities shall provide message routing functions to support the communication
between the servers and clients on the local networks of the commercial vehicle and towed vehicle(s).
Examples are given in Annex C.
11.3 Establishing, maintaining, and terminating of connections
For the diagnostic data transmission between the towing and towed vehicles, the following limitations
apply.
a) Multiframe (segmented) messages shall use point-to-point (one-to-one) connections with physical
addressing only.
b) Single-frame messages can use multipoint (one-to-n) connectionless transmission with functional
addressing or point-to-point (one-to-one) connections with physical addressing.
11.4 Diagnostic communication channels (DCC)
There are two network layer implementations specified to establish diagnostic communication channels
between peer entities.
a) Mixed addressing format using DCC11, DCC12, DCC21, and DCC22.
This is the format specified in the first edition of ISO 11992-4 and shall be used for the communication
between the client located in the commercial vehicle’s local network and the server located in the
towed vehicle’s remote network. It is identified by the following:
— the network target address, N_TA;
— the network source address, N_SA;
— the network address extension, N_AE;
— the parameters specified in Table 16.
b) Subnet addressing format using DCCX.
This format shall be used for the communication between the clients located in the towed vehicle’s
local network and the servers located either in the commercial vehicle’s local network or in another
towed vehicle’s local network. It is identified by the following:
— the network target address
...