Powered by Google www.ChineseStandard.net Database: 189760 (15 Jun 2024)

GB/T 43258.2-2023 PDF in English

GB/T 43258.2-2023 (GB/T43258.2-2023, GBT 43258.2-2023, GBT43258.2-2023)
Standard IDContents [version]USDSTEP2[PDF] delivered inName of Chinese StandardStatus
GB/T 43258.2-2023English1205 Add to Cart 0-9 seconds. Auto-delivery. Road vehicles -- Diagnostic communication over Internet Protocol (DoIP) -- Part 2: Transport protocol and network layer services Valid

PDF Preview

Standards related to: GB/T 43258.2-2023

GB/T 43258.2-2023: PDF in English (GBT 43258.2-2023)

GB/T 43258.2-2023
ICS 43.040.10
CCS T 36
Road vehicles - Diagnostic communication over Internet
Protocol (DoIP) - Part 2: Transport protocol and network
layer services
(ISO 13400-2:2019, MOD)
Issued by: State Administration for Market Regulation;
Standardization Administration of the People’s Republic of China.
Table of Contents
Foreword ... 4
Introduction ... 6
1 Scope ... 9
2 Normative references ... 10
3 Terms and definitions ... 11
4 Symbols and abbreviated terms ... 14
4.1 Symbols ... 14
4.2 Abbreviated terms ... 14
5 Conformance ... 16
6 DoIP introduction ... 16
6.1 General information ... 16
6.2 Connection establishment and vehicle discovery ... 17
6.3 Vehicle network integration ... 22
6.4 Communication examples using message sequence charts ... 23
6.5 IP-based vehicle communication protocol — General information ... 23
7 Application (APP) requirements ... 24
7.1 APP implementation of DoIP requirements ... 24
7.2 APP data transmission order ... 24
7.3 APP DoIP entity synchronization of a vehicle’s GID ... 24
7.4 APP vehicle identification and announcement request message ... 27
7.5 APP diagnostic power mode information request and response ... 34
7.6 APP DoIP entity status information request and response ... 34
7.7 APP timing and communication parameters ... 35
7.8 APP logical addressing ... 37
7.9 APP communication environments and recommended timings ... 38
7.10 APP DoIP entity functional requirements ... 38
8 Service interface ... 39
8.1 General ... 39
8.2 Service primitive parameters (SPP) ... 40
8.3 SPP DoIP layer service interface ... 42
9 Application layer (AL) ... 44
9.1 AL dynamic host control protocol (DHCP) ... 44
9.2 AL generic DoIP protocol message structure ... 50
9.3 AL handling of UDP packets and TCP data ... 56
9.4 AL supported payload types over TCP and UDP ports ... 56
9.5 AL diagnostic message and diagnostic message acknowledgement ... 57
9.6 AL alive check request and alive check response ... 62
10 Transport layer security (TLS) ... 63
10.1 TLS secure diagnostic communication ... 63
10.2 TLS DoIP application profile ... 66
11 Transport layer (TL) ... 68
11.1 TL transmission control protocol (TCP) ... 68
11.2 TL user datagram protocol (UDP)... 71
11.3 TL handling of UDP messages ... 75
12 Network layer (NL) ... 75
12.1 NL internet protocol (IP) ... 75
12.2 NL IPv4 address resolution protocol (ARP) ... 76
12.3 NL IPv6 neighbour discovery protocol (NDP) ... 77
12.4 NL internet control message protocol (ICMP) ... 77
12.5 NL IP-based vehicle communication protocol ... 78
12.6 NL socket handling ... 84
13 Data link layer (DLL) ... 92
13.1 DLL general ... 92
13.2 DLL MAC-layer ... 92
Bibliography ... 93
This document is drafted in accordance with the rules provided in GB/T 1.1-2020
Directives for standardization - Part 1: Rules for the structure and drafting of
standardizing documents.
This document is part 2 of GB/T 43258 Road vehicles - Diagnostic communication over
Internet Protocol (DoIP). The following parts have been issued for GB/T 43258:
— Part 2: Transport protocol and network layer services;
— Part 3: Wired vehicle interface based on IEEE 802.3;
— Part 4: Ethernet-based high-speed data link connector.
This document adopts ISO 13400-2:2019 Road vehicles - Diagnostic communication
over Internet Protocol (DoIP) - Part 2: Transport protocol and network layer services
by modification.
The technical differences between this document and ISO 13400-2:2019, and the causes
for these differences are as follows:
— USE the normatively referenced GB 16735 to replace ISO 3779 (see Table 4 and
Table 5), to adapt to the technical conditions in China and to improve operability;
— ADD the symbol < k> (see 4.1), to improve the usability of the document;
— ADD the abbreviated terms AutoIP, PDU and OTA, and DELETE the unused
abbreviated term FMI (see 4.2), to improve the usability of the document;
— CHANGE “the DoIP entity has an IP address configured in approximately two
seconds” to “the DoIP entity has an IP address configured in approximately seven
seconds”, and CHANGE “an IP address is configured after approximately seven
seconds” to “an IP address is configured after approximately two seconds” (see, so that the timing parameters are consistent with those in Table 15;
— CHANGE “node management (××1616)” to “0×××16” (see 9.2), to adapt to the
technical conditions in China and improve the operability;
— CHANGE “Response by the DoIP gateway” to “Response by the DoIP entity” (see
Table 48), to improve the technical application flexibility.
Please note that some of the contents of this document may involve patents. The issuing
organization of this document is not responsible for identifying patents.
This document was proposed by the Ministry of Industry and Information Technology
of the People's Republic of China.
Road vehicles - Diagnostic communication over Internet
Protocol (DoIP) - Part 2: Transport protocol and network
layer services
1 Scope
This document specifies the requirements for secured and unsecured diagnostic
communication between client DoIP entity and server(s) installed in the vehicle using
Internet protocol (IP) as well as the transmission control protocol (TCP) and user
datagram protocol (UDP). This includes the definition of vehicle gateway requirements
(e.g., for integration into an existing computer network) and test equipment (client DoIP
entity) requirements (e.g., to detect and establish communication with a vehicle).
This document specifies features that are used to detect a vehicle in a network and
enable communication with the vehicle gateway as well as with its sub-components
during the various vehicle states. These features are separated into two types:
mandatory and optional.
This document specifies the following mandatory features:
— vehicle network integration (IP address assignment);
— vehicle announcement and vehicle discovery;
— vehicle basic status information retrieval (e.g., diagnostic power mode);
— connection establishment (e.g., concurrent communication attempts), connection
maintenance and vehicle gateway control;
— data routing to and from the vehicle's sub-components;
— error handling (e.g., physical network disconnect).
This document specifies the following optional features:
— DoIP entity status monitoring;
— transport layer security (TLS);
— DoIP entity firewall capabilities.
announcement message broadcast in the previous step is processed in some way. For
example, the vehicle somehow indicates to be “ready” or an automated process is
initiated based on the information that a vehicle is now available for a DoIP session.
Although in the networked scenario there is still the networking equipment between the
client and the DoIP entity, the communication is now logically directly between the two
communication endpoints. Thus, no network is shown in Figure 5.
The first step in order to initiate a connection between the client DoIP entity and the
DoIP entity in the vehicle is to open a socket (destination port is 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 (< n>) plus one extra socket (see DoIP-002). If more than < n + 1>
connection attempts arrive at the same time, it is possible that no more resources are
free and the < n + 2nd> connection attempt is refused (because there are no longer any
sockets in the listening state because of DoIP protocol handling).
Once a socket is established, some initializing steps are performed. An initial inactivity
timer (see 12.6.3) and a general inactivity timer (see 12.6.2) is assigned and started.
Additionally, it is necessary to ensure that no arriving data, except the routing activation
request message, is routed or processed by setting the connection state to “initialize”
(see All subsequent messages are exchanged through this TCP_DATA socket.
This connection handling is also applied by the DoIP entity in case of secure TLS-based
communication and the corresponding TCP_DATA TLS socket (see 6.2.5).
To activate routing on the initialized connection, the client sends a routing activation
request message (see 12.5) to the DoIP entity. If the client DoIP entity is eligible and if
there are fewer than < n> active connections registered, the corresponding initial timer
is stopped and – assuming that no additional authentication or confirmation or secure
TLS connection is required – the socket state changes to “registered [routing active]”.
Now valid DoIP messages (e.g., DoIP diagnostic messages) are routed or processed.
This is reported to the client DoIP entity by a positive routing activation response
message. The general inactivity timer is restarted and remains active.
When receiving any kind of data, the DoIP entity first calls the DoIP header handler. If
the payload consists of a diagnostic message (identified through the payload type 800116
in the generic DoIP header, see 9.5), the diagnostic message handler is called to process
the payload.
When a diagnostic message arrives, the DoIP confirmation is sent to the calling client
DoIP entity immediately after the message has successfully passed the diagnostic
message handler (confirmation acknowledgement), in essence the message has passed
through the corresponding internal routing mechanism but has not yet been processed
by the DoIP gateway or forwarded to the final non DoIP server.
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.