ISO 11992-4:2005

INTERNATIONAL ISO
STANDARD 11992-4
First edition
2005-07-15

Road vehicles — Interchange of digital
information on electrical connections
between towing and towed vehicles —
Part 4:
Diagnostics
Véhicules routiers — Échange d'informations numériques sur les
connexions électriques entre véhicules tracteurs et véhicules tractés —
Partie 4: Diagnostics




Reference number
ISO 11992-4:2005(E)
©
ISO 2005

---------------------- Page: 1 ----------------------
ISO 11992-4:2005(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


©  ISO 2005
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing 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 2005 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 11992-4:2005(E)
Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions. 1
4 Syntax applied. 2
5 Diagnostic application specification . 2
5.1 General. 2
5.2 Basic diagnostics . 2
5.3 Enhanced diagnostics. 3
5.4 Client and server state diagrams . 3
6 Application layer specification. 7
6.1 General. 7
6.2 Application layer functions. 7
6.3 Application layer services . 10
6.4 Application layer protocol . 22
7 Presentation layer specification. 27
8 Session layer specification. 27
9 Transport layer specification. 27
10 Network layer specification . 27
10.1 General. 27
10.2 Network layer functions . 27
10.3 Network layer services. 30
10.4 Network layer protocol. 34
11 Data link layer specification . 42
11.1 General. 42
11.2 Data link layer service parameter. 42
12 Physical layer specification. 43
Annex A (normative) Addresses.44
Annex B (normative) Basic diagnostic service parameters . 46
Annex C (informative) Trailer message routing example. 65
Annex D (normative) CAN identifier and frame format . 67
Bibliography . 68

© ISO 2005 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 11992-4:2005(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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
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.
ISO 11992-4 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
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 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: Diagnostics
iv © ISO 2005 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 11992-4:2005(E)
Introduction
ISO 11992 has been established in order to define the data interchange between road vehicles and their
[4]
towed vehicles using a Controller Area Network (CAN) serial data link as specified in ISO 11898 .
The description of this part of ISO 11992 is based on the Open Systems Interconnection (OSI) Basic
[2] [3]
Reference Model in accordance with ISO/IEC 7498 (and ISO/IEC 10731 ), which structures
communication systems into seven layers.
When mapped on this model, the communication system specified by ISO 11992 is broken down into:
Layer 7
Application layer for brakes and running gear.
Application layer for equipment other than brakes and running gear.
Application layer for diagnostics.
Layer 3
Network layer for diagnostics.
Layer 2
Data link layer for all communication types.
Layer 1
Physical layer for all communication types.
Table 1 — Applicability and relationship between International Standards
Normal communication Diagnostic communication
Applicability
Equipment other than brakes
Brakes and running gear All applications
and running gear
Layer 7: ISO 11992-4
ISO 11992-2 ISO 11992-3
Application layer ISO 14229-1
Layer 6:
No functions specified for this layer.
Presentation layer
Layer 5:
No functions specified for this layer.
Session layer
Layer 4:
No functions specified for this layer.
Transport layer
Layer 3: ISO 11992-4
No functions specified for this layer.
Network layer ISO 15765-2
Layer 2:
ISO 11992-1
Data link layer
Layer 1:
ISO 11992-1
Physical layer

© ISO 2005 – All rights reserved v

---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 11992-4:2005(E)

Road vehicles — Interchange of digital information on electrical
connections between towing and towed vehicles —
Part 4:
Diagnostics
1 Scope
This part of ISO 11992 specifies the data communication for diagnostic purposes on a serial data link between
a road vehicle and its towed vehicle(s).
This part of ISO 11992 is applicable to road vehicles of a maximum authorized total mass greater than
3 500 kg.
2 Normative references
The following referenced documents are indispensable for the application 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 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, 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, 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: Specification and requirements
ISO 15765-2, Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part 2: 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 and
ISO 15765-2 apply.
© ISO 2005 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO 11992-4:2005(E)
4 Syntax applied
For the description of services and service parameters of this part of ISO 11992, the following syntax is used:
Name: Type Parameter name and type specification
Name Mandatory parameter value
Parameter name representing a set of mandatory parameter values
[Name] Optional parameter value
[] Parameter name representing a set of optional parameter values
{Name 1;Name 2} List of mandatory parameter values
{;} List of parameter names representing sets of mandatory parameter values
[;] List of parameter names representing sets of optional parameter values
{|} Parameter names selection list representing sets of mandatory parameter
values
[|] Parameter names selection list representing sets of optional parameter
values
Name.req Service request primitive
Name.ind Service indication primitive
Name.rsp Service response primitive
Name.rsp- Service negative response primitive
Name.rsp+ Service positive response primitive
Name.con Service confirmation primitive
Name.con- Service negative confirmation primitive
Name.con+ Service positive confirmation primitive
5 Diagnostic application specification
5.1 General
The diagnostic applications are divided into basic diagnostic applications and enhanced diagnostic
applications.
Functions, services and protocols of the layers 1 to 4 shall be identical for basic diagnostics and enhanced
diagnostics.
5.2 Basic diagnostics
The purpose of the basic diagnostics is to provide vehicle-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.
2 © ISO 2005 – All rights reserved

---------------------- Page: 7 ----------------------
ISO 11992-4:2005(E)
5.3 Enhanced diagnostics
The support and the conditions under which enhanced diagnostic functions and services are provided are
manufacturer-specific. It is the responsibility of the manufacturer to secure a server against unauthorized
access and to guarantee performance and safe operation in all operation modes allowing enhanced
diagnostics.
5.4 Client and server state diagrams
5.4.1 General
The client and server state diagrams describe the diagnostic service processing of the client and server
application entity.
5.4.2 Client service primitives handling
The client service primitives handling shall be as specified in Figure 1 and Figure 2.
Client states while processing a diagnostic service shall be as specified in Table 2, events resulting in a client
state change shall be as specified in Table 3.

Figure 1 — Client service state diagram — Service request with physical server target address
© ISO 2005 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO 11992-4:2005(E)

Figure 2 — Client service state diagram — Service request with functional server target address
Table 2 — Client state description
Client state Description
AS Any client state in which a service request can take place.
WS Client state while waiting for a confirmation from the server.
a) Following a service request with a physical server target address:
client state after the reception of a negative confirmation from the server.
NCS
b) Following a service request with a functional server target address:
client state if no positive service confirmation has been received.
PCS Client state after the reception of a positive confirmation from a server.
ES Client state for error handling, e.g. in case of a time out condition.
4 © ISO 2005 – All rights reserved

---------------------- Page: 9 ----------------------
ISO 11992-4:2005(E)
Table 3 — Client event description
Client event Description
Tas1.1 Transmit .req The client transmits an service request with a physical server target address.
Tas1.2 Transmit .req The client transmits an service request with a functional server target address.
Following a service request with a physical server target address:
the client receives a negative service confirmation with the response code
Tws1.1 Receive .con-
'Request correctly received - response pending'.
The client shall then reset the time outs and enter the WS state again.
Following a service request with a functional server target address:
the client receives a positive service confirmation.
Tws1.2 Receive .con+
The client shall then process the positive service confirmation and enter the WS
state again.
Following a service request with a physical server target address:
the service request has been rejected, a corresponding negative
Tws2.1 Receive .con-
service confirmation with a response code has been received.
The client shall then change to the NCS state.
Following a service request with a functional server target address:
the time ACT1 for the reception of the first service confirmation has expired and
Tws2.2 ACT1 expired
no positive service confirmation has been received.
The client shall then change to the NCS state.
Following a service request with a physical server target address:
the service has been executed, a positive service confirmation, i.e. the
Tws3.1 Receive .con+
result of the service, has been received.
The client shall then change to the PCS state.
Following a service request with a functional server target address the time ACT3.2
for the reception of consecutive service confirmations has expired and at least one
Tws3.2 ACT3.2 expired
positive service confirmation has been received.
The client shall then change to the PCS state.
An error condition, e.g. a time out condition, is signalled to the client.
Tes1 Error.ind
The client shall then change to the ES state for error handling.
NOTE Negative service responses with a response code 10 , 11 or 12 shall not be sent by a server in case of a service
16 16 16
request with a functional server target address.
Any diagnostic service.
5.4.3 Server service primitives handling
The server diagnostic service primitives handling shall be as specified in Figure 3.
Server states while processing a diagnostic service shall be as specified in Table 4, events resulting in a
server state change shall be as specified in Table 5.
Table 4 — Server state description
Server state Description
AS Any server state in which the reception of a service indication can take place.
PS Server state while processing a service.
PCS Server state after the diagnostic service has been executed.
ES Server state error handling, e.g. after reaching a time out condition.
© ISO 2005 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO 11992-4:2005(E)

Figure 3 — Server state diagram
6 © ISO 2005 – All rights reserved

---------------------- Page: 11 ----------------------
ISO 11992-4:2005(E)
Table 5 — Server event description
Event Description
Tas1 Receive .ind The server receives any service.indication.
The service execution time AST1max has expired.
AST1max expired the server shall then send a negative service response with the response code
Tws1
Transmit .res- 'Request correctly received - response pending' and change back to the PS state to
proceed the service execution.
The server receives a service indication, while service is in progress.
the server shall reject the service if service ≠ service and send a
Received .ind
negative response with response code "Busy - Repeat Request". If service =
Tws2
Respond .res±
service , the server shall send a negative service response with response code
"Request Correctly Received - Response Pending".
The server shall then enter again the PS state to proceed the service execution.
Following a service request with a physical server target address:
Service execution
the server rejects the service request.
Tws3.1 not completed
The server shall then send a negative service response with a corresponding
Respond .res-
response code and change to the AS state.
Service execution Following a service request with a functional server target address:
Tws3.2
not completed the server rejects the service request.
No response The server shall then send no response code and change to the AS state.
The server sends a positive service response.
Service execution
the service has been executed.
Tws4 completed
The server shall then transmit a positive service response, i.e. the service
Respond .res+
results, and shall change again to the PCS state.
An error condition is indicated to the server, e.g. a time out condition.
Tes1 Error.ind
The server changes to the ES state for error handling.
NOTE Negative service responses with a response code 10 , 11 or 12 shall not be sent by a server in case of a service
16 16 16
request with a functional server target address.
Any first diagnostic service.
Any second diagnostic service.
6 Application layer specification
6.1 General
The application layer function, service and protocol specifications comply with ISO 14229-1. In case of
differences, the specifications of this part of ISO 11992 shall have precedence.
For the diagnostic communication between road vehicles and their towed vehicles, the restrictions described
in this clause apply additionally.
6.2 Application layer functions
6.2.1 General
The application layer provides functions for the execution of the vehicle diagnostics. These functions are used
by client and server applications requesting the respective application layer services.
6.2.2 Processing of diagnostic services requests and responses
Diagnostic service requests from the client application and diagnostic service responses from the server
application shall be processed according to the service identifier. The diagnostic data shall be encoded as an
application layer protocol data unit (A_PDU). The A_PDU shall be transmitted to the respective application
layer peer entity by requesting services of the layers beneath the application layer.
© ISO 2005 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO 11992-4:2005(E)
6.2.3 Processing of diagnostic service indications and confirmations
Diagnostic data shall be received as an A_PDU from the layers beneath the application layer. If the received
A_PDU is addressed to one of the local server or client application, the received A_PDU shall be decoded and
processed according to the diagnostic service identifier and delivered to the server or client application as a
service indication or confirmation.
6.2.4 Determination of network layer service parameters
Network layer service parameters are determined by the application layer service type, i.e. ClientIdentifier,
ServerIdentifier, ServiceIdentifier and ServiceParameter. In addition the specified parameters Priority and
ReservedBit shall be used.
NOTE As no specific functions have been specified for the presentation, session and transport layer, the PDUs of
these layers are identical to the respective application layer PDUs.
6.2.5 Application layer protocol timing supervision
The peer application layer entities communicating shall supervise the specified timing and shall take the
respective actions in case a specified time out expires.
6.2.6 Server and client addressing
6.2.6.1 Vehicle network architecture
Towed vehicle server and client applications shall be addressed and identified by means of remote network
addressing. The physical sub-networks between towing and towed vehicles are part of the local motor vehicle
network and share the same address range. The address type of the target address (TA) and of the remote
address (RA) in the case of encoding a remote target address shall be identified by the target address type
(TA_Type).
Figure 4 shows an example of the vehicle network architecture.

Figure 4 — Vehicle network architecture example
8 © ISO 2005 – All rights reserved

---------------------- Page: 13 ----------------------
ISO 11992-4:2005(E)
6.2.6.2 Towing to towed vehicle .Request and .Indication
For a diagnostic service request transmitted from a towing vehicle to a towed vehicle, the address parameters
of the service primitives have the following meaning:
SA =
TA =
RA =
TA_type = {
|

}
See Annex A.
NOTE TA_type identifies the TA and the RA target address type.
6.2.6.3 Towed to towing vehicle .Response and .Confirmation
For a diagnostic service response transmitted from a towed vehicle to a towing vehicle, the address
parameters of the service primitives have the following meaning:
SA =
TA =
RA =
TA_type =
NOTE TA_type identifies only the TA target address type.
6.2.6.4 Towed to towing vehicle .Request and .Indication
For a diagnostic service request transmitted from a towed vehicle to a towing vehicle, the address parameters
of the service primitives have the following meaning:
SA =
TA =
RA =
TA_type = {
|

}
NOTE TA_type identifies only the TA target address type.
© ISO 2005 – All rights reserved 9

---------------------- Page: 14 ----------------------
ISO 11992-4:2005(E)
6.2.6.5 Towing to towed vehicle .Response and .Confirmation
For a diagnostic service response transmitted from a towing vehicle to a towed vehicle, the address
parameters of the service primitives have the following meaning:
SA =
TA =
RA =
TA_type =
NOTE TA_type identifies the TA and RA target address type.
6.3 Application layer services
6.3.1 General
This subclause specifies the application layer services for diagnostics.
6.3.2 Application layer service parameters
6.3.2.1 General
This subclause specifies the general application layer service parameter and the respective parameter format.
Service specific parameters are specified in 6.3.4.
6.3.2.2 Source address (SA)
The parameter source address (SA) contains the client or server source address. It represents the physical
location of a client or server on the local network.
SA = {
|

}
6.3.2.3 Target address (TA)
The parameter target address (TA) contains the client or server target address. It represents the physical
location of a client or server or a functional group of servers on the local network. The target address type is
determined by the parameter TA_type.
TA = {
|
|

}
6.3.2.4 Target address type (TA_type)
The parameter target address type (TA_type) determines the address type of the target address TA and the
remote address RA, in the case that the remote address corresponds to a target address.
TA_type = {
|

}
10 © ISO 2005 – All rights reserved

---------------------- Page: 15 ----------------------
ISO 11992-4:2005(E)
6.3.2.5 Remote address (RA)
The remote address (RA) contains the remote addresses of servers or clients on a remote network.
Depending on the respective application layer primitive, RA represents either a remote target address or a
remote source address.
RA = {
|
|
|

}
6.3.2.6 ServiceParameter
ServiceParameter is a record which contains the respective service parameters of the service primitive.
ServiceParameter = {
< request service parameter>|
< positive response service parameter>|
< negative response service parameter>
}
request service parameters are those following the request service identifier.
positive response service parameters are those following the positive
response service identifier.
negative response service parameters are those following the negative response service
identifier.
6.3.3 Application layer service data units (A_SDU)
The application layer service data units (A_SDU) of the diagnostic service primitives have the following
formats:
.Request = {
;
;
;
;
< request service identifier>;
< request service parameter>
}
.Indication = < .Request>
.Response = {
;
;
;
;
< response service identifier>;
< response servic
...