ISO 13400-2:2019/Amd 1:2023

INTERNATIONAL ISO
STANDARD 13400-2
Second edition
2019-12
AMENDMENT 1
2023-07
Road vehicles — Diagnostic
communication over Internet Protocol
(DoIP) —
Part 2:
Transport protocol and network layer
services
AMENDMENT 1
Véhicules routiers — Communication de diagnostic au travers du
protocole internet (DoIP) —
Partie 2: Protocole de transport et services de la couche réseau
AMENDEMENT 1
Reference number
ISO 13400-2:2019/Amd.1:2023(E)
© ISO 2023

---------------------- Page: 1 ----------------------
ISO 13400-2:2019/Amd.1:2023(E)
COPYRIGHT PROTECTED DOCUMENT
© 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
  © ISO 2023 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 13400-2:2019/Amd.1:2023(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.
A list of all parts in the ISO 13400 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.
iii
© ISO 2023 – All rights reserved

---------------------- Page: 3 ----------------------
ISO 13400-2:2019/Amd.1:2023(E)
Road vehicles — Diagnostic communication over Internet
Protocol (DoIP) —
Part 2:
Transport protocol and network layer services
AMENDMENT 1

6.2.5
Replace description with this text.
For a secured TCP connection, the TLS dedicated TCP_DATA port is used. As for the unsecured DoIP
session case, the first step in order to initiate a secure TLS connection between the client DoIP entity
and the DoIP entity, is to open a TLS socket (destination port is TLS TCP_DATA). This is done prior
to any message exchange. Therefore, a DoIP entity provides the resources to handle the incoming
communication request (e.g. socket resources). The DoIP entity provides sufficient resources to handle
the specified number of concurrently supported DoIP sessions secured with TLS () (see [DoIP-159]).
If more than connection attempts arrive at the same time, it is possible that no more resources are
available and the connection attempt is refused (because there are no longer any sockets in
the listening state because of DoIP protocol handling).
A vehicle manufacturer may choose to implement k+1 TLS data sockets, where the additional socket is
used to reject a routing activation with routing activation response code 01 .
16
If a k+1 TLS data socket is not implemented, no DoIP routing activation response code 01 can be
16
responded when all k concurrently supported DoIP sessions are already in use. In this case, the
additional connection will be rejected on the TCP level already.

7.7, Table 12
Replace Table 12 with this table.
Table 12 — DoIP timing and communication parameters
Timing parameter Description Client Server
t
This timeout specifies the time that the cli- Minimum Recommended
A_DoIP_Ctrl
ent DoIP entity waits for a response to a pre- timeout: 2 s ECU Performance
viously sent UDP message. This includes the Response time:
time to wait and collect multiple responses 1 600 ms
to a previous broadcast (UDP only).
t
This timeout specifies the time that the Minimum Recommended
A_DoIP_Routing_Activation
client DoIP entity waits for a response to a timeout: 2 s ECU Performance
previously sent routing activation request Response time:
on a TCP_DATA socket. 1 600 ms
1
© ISO 2023 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 13400-2:2019/Amd.1:2023(E)
TTabablele 1 122 ((ccoonnttiinnueuedd))
Timing parameter Description Client Server
t
This timing parameter specifies the initial N/A Random time:
A_DoIP_Announce_Wait
time that a DoIP entity waits until it re- 0 to 500 ms
sponds to a vehicle identification request
and the time that a DoIP entity waits until it
transmits a vehicle announcement message
after a valid IP address is configured.
The value of this timing parameter shall be
determined randomly between the mini-
mum and the maximum value.
t
This timing parameter specifies the time N/A Delay time:
A_DoIP_Announce_Interval
between the vehicle announcement messag- 500 ms
es that are sent by the DoIP entities after a
valid IP address has been configured.
t
This parameter specifies the number of N/A Repetition:
A_DoIP_Announce_Num
vehicle-announcement messages, which are 3 times
sent by the DoIP entity, after the configura-
tion of a valid IP address.
t
This is the time between receipt of the last Minimum ECU performance
A_DoIP_Diagnostic_Message
byte of a DoIP diagnostic message and the timeout: 2 s response time:
transmission of the confirmation ACK or 50 ms
NACK.
After the timeout has elapsed, the request
or the response shall be considered lost and
the request may be repeated.
t
This timeout specifies the time of inactivity N/A Timeout: 300 s
T_TCP_General_Inactivity
on a TCP_DATA socket (no data received or
sent) before it is closed by the DoIP entity.
t
This timeout specifies the time of inactivity N/A Timeout: 2 s
T_TCP_Initial_Inactivity
directly after a TCP_DATA socket is estab-
lished. After the specified time without
routing activation, the TCP_DATA socket is
closed by the DoIP entity.
t
This timeout specifies the time that a DoIP Client perfor- Timeout: 500 ms
T_TCP_Alive_Check
entity waits for an alive check response mance time:
after having written an alive check request 300 ms
on the TCP_DATA socket. Thus, the timer
elapses if the underlying TCP stack is unable
to deliver the alive check request message.
t
This timeout is defined as the time between Timeout: 2 s N/A
A_Processing_Time
transmission from the client DoIP entity
of DoIP messages that require no response
message but may need some time to be
processed. Thus, the client DoIP entity shall
wait for at least A_Processing_Time before
sending another request to the same DoIP
entity.
t
This is a per vehicle offboard sided timer. Timeout: 5 s N/A
A_Vehicle_Discovery_Timer
This timer specifies the time a vehicle can
take to perform the VIN/GID synchroniza-
tion between all DoIP entities.
The vehicle discovery timer may only be
started when a vehicle announcement/ vehi-
cle identification response message contain-
ing a VIN/GID sync status code “incomplete”
(10 ) and a valid VIN or GID is received by
16
the client DoIP entity.
2
  © ISO 2023 – All rights reserved

---------------------- Page: 5 ----------------------
ISO 13400-2:2019/Amd.1:2023(E)

9.2, Table 16
Replace Table 16 with this table.
Table 16 — Generic DoIP header structure
Item Pos. Len. Description Values
Protocol 0 1 Identifies the protocol version of DoIP packets. 00 : reserved
16
version
01 : ISO/DIS 13400-2:2010
16
02 : ISO 13400-2:2012
16
03 : ISO 13400-2:2019
16
04 : ISO 13400-2:2019/Amd1
16
05 to FE : reserved by this
16 16
document
FF : default value for vehicle
16
identification request messages
Inverse 1 1 Contains the bit-wise inverse value of the Equals the
protocol protocol version, which is used in conjunction XOR FF (e.g. FE for protocol
16 16
version with the DoIP protocol version as a protocol version 01 ).
16
verification pattern to ensure that a correctly
formatted DoIP message is received.
Payload 2 2 Contains information about how to interpret See Table 17 for a complete list of
type the data following the generic DoIP header (e.g. currently specified payload type
(GH_PT) gateway command, diagnostic message, etc.). values.
Payload 4 4 Contains the length of the DoIP message payload 0 to 4 294 967 295 bytes
length in bytes (i.e. excluding the generic DoIP header
(GH_PL) bytes).
Some payload types do not require any addi-
tional parameters (payload length is 0), some
require a fixed DoIP message length while oth-
ers allow for dynamic length DoIP messages.
Payload 8 … The payload type specific message content —
type starts here.
specific
This implies that, for example, byte position 0
message
of the payload type-specific part of the message
content
means byte position 8 in the context of the over-
all DoIP message.

9.2, Table 17
Replace Table 17 with this table.
Table 17 — Overview of DoIP application layer payload types
Payload type See Support DoIP Port and protocol
value name GW nodes
0000
Generic DoIP header negative 9.3 M M UDP_DISCOVERY
16
acknowledge
UDP_TEST_EQUIPMENT_REQUEST
TCP_DATA
0001
Vehicle identification request 7.4 M M UDP_DISCOVERY
16
message
3
© ISO 2023 – All rights reserved

---------------------- Page: 6 ----------------------
ISO 13400-2:2019/Amd.1:2023(E)
TTabablele 1 177 ((ccoonnttiinnueuedd))
Payload type See Support DoIP Port and protocol
value name GW nodes
0002
Vehicle identification request 7.4 O O UDP_DISCOVERY
16
message with EID
0003
Vehicle identification request 7.4 M M UDP_DISCOVERY
16
message with VIN
0004
Vehicle announcement message/ 7.4 M M UDP_DISCOVERY
16
vehicle identification response
UDP_TEST_EQUIPMENT_REQUEST
message
0005 TCP_DATA
Routing activation request 12.5 M M
16
0006 TCP_DATA
Routing activation response 12.5 M M
16
0007 TCP_DATA
Alive check request 9.6 M M
16
0008 TCP_DATA
Alive check response 9.6 M M
16
0009
reserved by this document
16
to
4000
16
4001 UDP_DISCOVERY
DoIP entity status request 7.6 O O
16
4002 UDP_TEST_EQUIPMENT_REQUEST
DoIP entity status response 7.6 O O
16
4003 UDP_DISCOVERY
16 Diagnostic power mode informa- 7.5 M M
tion request
4004 UDP_TEST_EQUIPMENT_REQUEST
Diagnostic power mode informa- 7.5 M M
16
tion response
4005
reserved by this document
16
to
8000
16
8001 TCP_DATA
Diagnostic message 9.5 M M
16
8002 TCP_DATA
16 Diagnostic message positive 9.5 M M
acknowledgement
8003 TCP_DATA
Diagnostic message negative 9.5 M M
16
acknowledgement
8004 TCP_DATA
Periodic diagnostic message 9.7 O O
16
8005
reserved by this document
16
to
8FFF
16
9000
see 11.4
16
to
9FFF
16
A000
reserved by this document
16
to
EFFF
16
F000
Reserved for manufacturer-spe- — O O —
16
to
cific use
FFFF
16

9.2, Figure 16
Replace Figure 16 with this figure.
4
  © ISO 2023 – All rights reserved

---------------------- Page: 7 ----------------------
ISO 13400-2:2019/Amd.1:2023(E)
Figure 16 — DoIP generic header handler

9.2
5
© ISO 2023 – All rights reserved

---------------------- Page: 8 ----------------------
ISO 13400-2:2019/Amd.1:2023(E)
Replace REQ 7.DoIP-041 AL with the following.
REQ 7.DoIP-041 AL – DoIP entity does not match generic DoIP header structure
Each DoIP entity shall send a generic DoIP header negative acknowledge message with NACK code set to 00 if
16
the protocol version or inverse protocol version (synchronization pattern) does not match the format specified
in Table 16 or if the protocol version is not supported by the DOIP entity.

9.4, NOTE 1
Replace NOTE 1 with the following:
NOTE 1 Table 20 shows the IPv6 variant. For IPv4, Limited Broadcast is used instead of Multicast.

9.5, title
Replace "AL diagnostic message and diagnostic message acknowledgement" with "AL – Payload type
definition and acknowledgement".
9.5, first paragraph
Replace with the following:
This subclause specifies the message format that allows for the optional transmission of internal
transport layer status service primitive information to a DoIP client. This transport layer status
message covers the standard transport layer services primitives useful to the DoIP client including T_
Data.confirm, T_DataSOM.indication, and T_Data.indication. If this payload type is utilized, a DoIP client
has the ability to determine when a gatewayed message has completed transmission on the target
network (or aborted due to an error), when a segmented response has started on the target network,
and when a segmented response has aborted due to an error on the target network. DoIP clients are
not required to process this payload type if supported by a DoIP entity. If a DoIP client does support
processing this payload type, it may implement substantially faster timeouts depending upon the
details of the target network.
9.5
Replace REQ 7.DoIP-064 AL with the following:
REQ 7.DoIP-064 AL – DoIP entity status message structure
Each DoIP entity shall support the status message structure as specified in Table 21 for incoming (i.e. requests)
and outgoing (i.e. responses) diagnostic messages.

9.7
Add the following new subclause.
9.7  AL – Periodic response message
This subclause specifies the periodic response message structure of the DoIP message that is used. The
periodic response messages are utilized by the TCP_DATA socket handler.
REQ 7.DoIP-189 AL – DoIP periodic response message structure
For DoIP entities that use payload type 8004 , each DoIP entity shall support the periodic response message
16
structure as specified in Table 31.

6
  © ISO 2023 – All rights reserved

---------------------- Page: 9 ----------------------
ISO 13400-2:2019/Amd.1:2023(E)
Insert new Tables 29-31.
Table 29 — Payload type periodic response message structure
Item Pos. Len. Description Values Cvt
Protocol ver- 0 1 see Table 16 see Table 16 M
sion
Inverse proto- 1 1 see Table 16 see Table 16 M
col version
Payload type 2 2 see Table 16 see Table 16 M
(GH_PT)
Payload length 4 4 see Table 16 see Table 16 M
(GH_PL)
Source address 8 2 Contains the logical address of the sender see Table 13 M
(SA) of a diagnostic message (e.g. the client DoIP
entity address).
Target address 10 2 Contains the logical address of the receiver see Table 13 M
(TA) of a diagnostic message (e.g. a specific serv-
er DoIP entity on the vehicle’s networks).
User data 1 to 9 12 9 Contains the actual timestamp of the user See Table 30 M
data 12 to 12 + k.
0002 to FFFF
User data 10 21 2 Contains the periodic respo
...