道路车辆 基于因特网协议的诊断通信（DoIP） 第2部分：传输协议与网络层服务

ICS43.040.10

CCST36

中华人民共和国国家标准

GB/TXXXXX—XXXX

道路车辆基于因特网协议的诊断通信

（DoIP）第2部分：传输协议与网络层服务

Roadvehicles—DiagnosticcommunicationoverInternetProtocol(DoIP)

—Part2:Transportprotocolandnetworklayerservices

（送审稿）

（ISO13400-2:2019，MOD）

（征求意见稿）

完成时间：2022.3.23

在提交反馈意见时，请将您知道的相关专利连同支持性文件一并附上。

GB/TXXXXX—XXXX

前言

本文件按照GB/T1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定

起草。

本文件是GB/TXXXXX《道路车辆基于因特网协议的诊断通信》的第2部分。GB/TXXXXX已经

发布了以下部分：

——第2部分：传输协议与网络层服务；

——第3部分：基于IEEE802.3有线车辆接口；

——第4部分：基于以太网的高速数据链路连接器。

本文件修改采用ISO13400-2:2019《道路车辆基于因特网协议的诊断通信第2部分：传输协议与

网络层服务》。

本文件与ISO13400-2:2019的技术差异及其原因如下：

——增加了缩略语“PDU”和“OTA”（见4.2），以提高文件易用性。

——在“推荐DoIP实体采用表15中定义的参数值”中，将“DoIP实体可在大概2秒内配置其IP地址”

修改为“DoIP实体可在大概7秒内配置其IP地址”，将“可在7秒后完成IP地址的配置”修改为“可在2

秒后完成IP地址的配置”（见），修改后的定时参数与表15的参数是一致匹配的。

——在“有效载荷类型根据报文内容被分组”中将“节点管理（XX1616）”更改为“0XXX16”

（见9.2），已适应我国的技术条件、提高可操作性。

本文件做了下列编辑性改动：

——删除国际标准的前言；

——将国际标准中表述自身的“本部分”或“本标准”改为“本文件”；

——修改国际标准的引言；

——规范性引用文件由国际标准替换为修改采用的国家标准。

请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。

本文件由中华人民共和国工业和信息化部提出。

本文件由全国汽车标准化技术委员会（SAC/TC114）归口。

本文件起草单位：

本文件主要起草人：

4

GB/TXXXXX—XXXX

引言

随着服务器内存大小的增加、更新软件数量的增加以及这些控制单元、连接网络和总线技术提供的

功能数量的增加，其复杂性和速度已达到类似于计算机网络的水平。

GB/TXXXXX的所有部分是为了定义在IP通信链路上实施的车辆诊断系统的通用要求。GB/T

XXXXX的目的是描述一个标准化的车辆接口，该接口：

——将车载网络技术与客户端DoIP实体车辆接口要求分离，以实现长期稳定的外部车辆通信接口；

——利用现有的标准来定义可用于诊断通信以及制造商特定用例的长期稳定的先进通信标准；

——通过使用现有的适配层，可以很容易地适应新的物理层和数据链路层，包括有线和无线连接；

——允许车辆内部和车辆外部DoIP实体的连接。

GB/TXXXXX由4部分构成：

——第1部分：一般信息和使用案例定义。规定了客户端DoIP实体与服务端DoIP实体之间的车

辆诊断的一般信息和使用案例定义，旨在为系列文件提供引言。

——第2部分：传输协议与网络层服务。规定了客户端DoIP实体使用底层协议栈的要求，并且采

用安全和非安全的诊断通信要求，旨在说明客户端DoIP实体与服务端DoIP实体连接与通信

过程。

——第3部分：基于IEEE802.3有线车辆接口。详细介绍了基于IEEE802.3100BASE-TX的物理

层和数据链路层的车载通信接口和测试设备要求，旨在提供标准的物理连接接口。

——第4部分：基于以太网的高速数据链路连接器。规定了车辆连接器的功能要求，旨在统一外部

连接器。

图1说明了基于DoIP的车辆诊断通信框架与OSI模型的关系：

——车辆诊断通信框架，由GB/T40822组成。

——表示层，例如特定于车辆制造商(VM)或ISO22901ODX。

——OSI底层框架，由GB/TXXXXX.3和GB/TXXXXX.4组成。

2

GB/TXXXXX—XXXX

ISO7498-1,车辆诊断通信框架通信使用案例标准

ISO/IEC10731

使用案例特定标准

GB/T40822第10章节

UDSonIP(基于IP的统一诊断服务)

应用层服务接口

OSI第7层GB/T40822

应用层第4~6章节

应用层

表示层标准

车辆制造商规定或

OSI第6层ISO22901ODX

表示层

上层服务接口

OSI第5层GB/T40822第7章节

会话层会话层服务

会话层服务接口

传输层服务接口

GB/TXXXXX.2DoIP

OSI第4层

第2部分：传输协议和网络层服务

传输层

安全传输层协议（TLS）

传输控制协议（TCP）

用户数据报协议（UDP）

因特网协议（IP）

OSI第3层

网络层数据链路层服务接口

OSI第2层数据链路层服务接口

数据链路层GB/TXXXXX.3DoIP

第3部分：基于IEEE802.3有线车辆接口

OSI第1层

物理层

OSI底层框架

图1根据OSI模型DoIP文档参考

图2从功能角度说明了车辆网络架构示意图。

3

GB/TXXXXX—XXXX

车辆网络

ECU1ECUI

ECU2ECUII

...

...

ECUnECUn

客户端2

(测试设备)

车辆子网络车辆子网络

DoIP边缘DoIP边缘

节点...节点网络节点1...DoIP节点

网关1网关m

基于IP的网络

外部网络基于IP的网络

激活线客户端1网络节点

网络节点2

(测试设备)...n

图2车辆网络架构示意图（功能视图）

本文件由一个或多个DoIP实体实施，具体取决于车辆的网络架构。图2显示了客户端1（外部客

户端），它连接到DoIP边缘节点和车辆内部网络中的客户端2（内部客户端）。如果没有额外说明，

无论它们连接到哪个网络，假定客户端DoIP实体的行为相同。

在本文件中，为需求分配了“X.DoIP-yyy”形式的唯一编号，以便于跟踪和参考需求。编号表达式中

参数含义为：

——X：OSI层数；

——DoIP-yyy：需求序号；

——OSI层缩写：[8=APP（应用），7=AL（应用层），6=PL（表示层），5=SL（会话层），4=TL

（传输层），3=NL（网络层），2=DLL（数据链路层），1=PHY（物理层），0=SPP]

注：本文档中的需求没有按顺序编号，因为在文档开发过程中各个需求的顺序发生了变化。

4

GB/TXXXXX—XXXX

道路车辆基于因特网协议的诊断通信（DoIP）第2部分：传输协议

与网络层服务

1范围

本文件规定了客户端DoIP实体与使用因特网协议（IP）、传输控制协议（TCP）以及用户数据报协

议（UDP）并安装在车辆内的服务器之间进行安全的和非安全的诊断通信要求。该要求包括定义车辆网

关要求（例如，集成到现有计算机网络）与测试设备要求（例如，检测并与车辆建立通信）。

本文件规定了在网络中检测车辆的功能，并在各种车辆状态下与车辆网关及其子模块进行通信的功

能。这些功能被划分为强制与可选两大类。

本文件规定了以下强制（必选）功能：

——车辆网络集成（IP地址分配）；

——车辆通告与车辆发现；

——车辆基本状态信息获取（如诊断电源模式）；

——连接建立（例如，并行通信尝试），连接维持与车辆网关控制；

——车辆子模块的数据进出路由；

——错误处理（例如，物理网络断开）。

本文件规定了以下可选功能：

——DoIP实体状态监控；

——传输层安全协议（TLS）；

——DoIP实体防火墙性能。

2规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，

仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本

文件。

ISO/IEC7498-1-1994信息处理系统开放系统互连第1部分：基本参考模式（Information

technology—OpenSystemsInterconnection—BasicReferenceModel:TheBasicModel）

注：GB/T9387.1-1998信息技术开放系统互连基本参考模型第1部分:基本模型(ISO/IEC7498-1:1994，IDT)

ISO13400-3道路车辆基于因特网协议的诊断通信第3部分：基于IEEE802.3有线车辆接口

[Roadvehicles—DiagnosticcommunicationoverInternetProtocol(DolP)—Part3:Wiredvehicle

interfacebasedonIEEE802.3]

注：GB/TXXXXX.3-XXXX基于因特网协议的诊断通信第3部分：基于IEEE802.3有线车辆接口(ISO

13400-3:2016，MOD)

ISO/IEC/IEEE8802-3信息技术系统间的电信和信息交换局域网和城市区域网具体需求第

3部分：以太网标准（Informationtechnology—Telecommunicationsandexchangebetween

informationtechnologysystems—Requirementsforlocalandmetropolitanareanetworks—

Specificrequirements—Part3:StandardforEthernet）

5

GB/TXXXXX—XXXX

IETFRFC768用户数据报协议（UserDatagramProtocol）

IETFRFC791:1981因特网协议—DARPA因特网互联程序—协议规范(InternetProtocol—DARPA

InternetProgram—ProtocolSpecification)

IETFRFC792网络控制报文协议—DARPA因特网互联程序—协议规范(InternetControlMessage

Protocol—DARPAInternetProgram—ProtocolSpecification)

IETFRFC793传输控制协议—DARPA因特网互联程序—协议规范(TransmissionControl

Protocol—DARPAInternetProgram—ProtocolSpecification)

IETFRFC826以太网地址解析协议(AnEthernetAddressResolutionProtocol)

IETFRFC1122因特网主机需求—通信层(RequirementsforInternetHosts—Communication

Layers)

IETFRFC2131动态主机配置协议(DynamicHostConfigurationProtocol)

IETFRFC2132DHCP可选项和BOOTP供应商扩展(DHCPOptionsandBOOTPVendorExtensions)

IETFRFC2460互联网协议第六版（IPv6）规范[InternetProtocol,Version6

(IPv6)—Specification]

IETFRFC2375IPv6组播地址分配(IPv6MulticastAddressAssignments)

IETFRFC3315Ipv6动态主机配置协议（DHCPv6）[DynamicHostConfigurationProtocolforIPv6

(DHCPv6)]

IETFRFC3484互联网协议第六版（IPv6）默认地址选择[DefaultAddressSelectionforInternet

Protocolversion6(IPv6)]

IETFRFC3927IPv4本地链路地址动态配置(DynamicConfigurationofIPv4Link-Local

Addresses)

IETFRFC4291IPv6寻址架构IP(Version6AddressingArchitecture)

IETFRFC4443因特网协议第六版（IPv6）网络控制报文协议（ICMPv6）规范[InternetControl

MessageProtocol(ICMPv6)fortheInternetProtocolVersion6(IPv6)Specification]

IETFRFC4702动态主机配置协议完全限定域名[TheDynamicHostConfigurationProtocol

(DHCP)ClientFullyQualifiedDomainName(FQDN)Option]

IETFRFC4861IPv6邻居发现协议[NeighborDiscoveryforIPversion6(IPv6)]

IETFRFC4862IPv6无状态地址自动配置(IPv6StatelessAddressAutoconfiguration)

IETFRFC5246传输层安全协议1.2[TheTransportLayerSecurity(TLS)ProtocolVersion1.2]

IETFRFC8446:2018传输层安全协议1.3[TheTransportLayerSecurity(TLS)ProtocolVersion

1.3]

3术语和定义

ISO/IEC7498-1界定的以及下列术语和定义适用于本文件。

3.1

诊断电源模式diagnosticpowermode

抽象的车辆内部电源供应状态，该状态影响车内网络上所有ECU的诊断功能，并识别允许诊断通信

的所有网关子网络上所有ECU的状态。

注：目的是为客户端DoIP实体提供信息，包括是否可以在连接的车辆上执行诊断，或车辆是否需要进入不同的诊

断电源模式（即需要技术人员交互）。本文件定义了如下状态：“未准备好”（部分基于DoIP的服务端可通信

或全部基于DoIP的服务端均不可通信），“已准备好”（所有基于DoIP的服务端均可通信），以及“不支持”

（不支持诊断电源模式信息的诊断请求报文）。

6

GB/TXXXXX—XXXX

3.2

DoIP边缘节点DoIPedgenode

车内主机（3.4），在此处符合GB/TXXXXX.3的以太网激活线所在终端，以及外部网络中的第一个

节点或主机的链路所在终端。

[来源：GB/TXXXXX.3-XXXX，定义3.1.2，有修改]

3.3

DoIP实体证书DoIPentitycertificate

证书由中间证书颁发机构（3.5）发放至DoIP实体，用以TLS握手过程中提供给客户端DoIP实体

进行验证其真实性。

3.4

主机host

连接到基于IP网络的节点

3.5

中间证书颁发机构intermediatecertificateauthority

IntermediateCA

颁发后续证书至其他中间证书颁发机构或DoIP实体。

3.6

中间证书intermediatecertificate

存储在客户端DoIP实体本地或在身份验证过程中与端节点证书一同提供以完成信任链。

3.7

无效的源地址invalidsourceaddress

为客户端DoIP实体预留的地址范围外的源地址

3.8

逻辑地址logicaladdress

识别诊断应用层实体的地址

3.9

网络节点networknode

连接到基于IP的网络（例如，以太网），并使用IP通信，但不支持基于DoIP协议的节点。

注：某些网络节点可能也与车辆子网络（3.14）连接，但由于不支持DoIP协议，所以这些网络节点不是DoIP网关。

因此，这些网络节点不会与遵循DoIP的客户端有交互（如响应外部请求）。

3.10

根证书颁发机构rootcertificateauthority

颁发根证书的机构

注：发放中间证书（3.6）以允许中间证书颁发机构（3.5）进一步发放证书。

3.11

根证书rootcertificate

由根证书颁发机构（3.10）创建并用作信任锚的证书。

注：所有想要验证终端节点证书的实体（例如，来自DoIP实体）安全地存储和使用根证书，以及信任链中的所有

必要的中间证书（3.6）。

3.12

7

GB/TXXXXX—XXXX

套接字socket

在IETFRFC147定义的唯一标识，该标识用于在网络上发送或接收信息

3.13

未知源地址unknownsourceaddress

未在连接表内列出的地址

3.14

车辆子网络vehiclesub-network

非直接与基于IP的网络相连接的车辆网络

注：来自及传向车内子网络的数据，仅能经由所连接的DoIP网关进行传输。

4符号和缩略语

4.1符号

下列符号适用于本文件。

<d>：有效载荷长度，单位为字节。

<k>：为了与一个或多个客户端DoIP实体并行的1至K个TLS安全的连接，DoIP实体需要支持的

并行DoIPTLSTCP会话的数量。

<m>：为了连接一个或多个DoIP实体，客户端DoIP实体需要支持的并行DoIPTCP会话的数量。

<n>：为了与一个或多个客户端DoIP实体并行的1至N个连接，DoIP实体需要支持的并行DoIPTCP

会话的数量。

<u>,<v>：车辆子网上独立服务端的数量

<w>：车辆网络上独立DoIP网关的数量

<x>：独立的车内网络节点数量

<y>：车辆网络中独立的DoIP节点数量

<z>：独立的车辆外部网络节点数量

4.2缩略语

下列缩略语适用于本文件。

AL：应用层（applicationlayer）

Alt：可替代，备选（alternative）

APP：应用（application）

ARP：地址解析协议（addressresolutionprotocol）

ASCII：美国信息交换标准代码（Americanstandardcodeforinformationinterchange）

Auto-MDI(X)：自动介质相关接口交叉（automaticmedium-dependentinterfacecrossover）

CA：证书授权（certificateauthority）

CAN：控制器局域网（controllerareanetwork）

CF：连续帧（consecutiveframe）

DHCP：动态主机配置协议（dynamichostcontrolprotocol）

DLL：数据链路层（datalinklayer）

DNS：域名系统（domainnamesystem）

DoIP：基于IP的诊断通信（diagnosticcommunicationoverinternetprotocol）

EID：实体标识（entityidentification）

FF：首帧（firstframe）

GID：组标识（groupidentification）

GUI：图形用户界面（graphicaluserinterface）

GW：网关（gateway）

8

GB/TXXXXX—XXXX

IANA：因特网编号管理局（Internetassignednumbersauthority）

ICMP：网络控制报文协议（Internetcontrolmessageprotocol）

IETFRFC：互联网工程任务组请求注释（InternetEngineeringTaskForceRequestforComments）

IP：因特网协议（Internetprotocol）

IPv4：因特网协议第4版（见IETFRFC791）[Internetprotocolversion4(seeIETFRFC791)]

IPv6：因特网协议第6版（见IETFRFC2460）[Internetprotocolversion6(seeIETFRFC2460)]

MAC：介质访问控制（mediaaccesscontrol）

MSC：消息序列图（messagesequencechart）

MTU：最大传输单元（maximumtransportunit）

NDP：邻居发现协议（neighbourdiscoveryprotocol）

NL：网络层（networklayer）

OSI：开放系统互连（opensystemsinterconnection）

OTA：空中下载(over-the-air)

PKI：公钥基础设施（publickeyinfrastructure）

PDU：协议数据单元（protocoldataunit）

SA：源地址（sourceaddress）

SDU：服务数据单元（servicedataunit）

SF：单帧（singleframe）

SPN：可疑参数编号（suspectparameternumber）

SPP：服务原语参数（serviceprimitiveparameter）

TA：目标地址（targetaddress）

TCP：传输控制协议（transmissioncontrolprotocol）

TL：传输层（transportlayer）

TLS：传输层安全协议（transportlayersecurity）

UDP：用户数据报协议（userdatagramprotocol）

VIN：车辆识别代号（见ISO3779）[vehicleidentificationnumber(seeISO3779)]

VM：车辆制造商（vehiclemanufacturer）

XOR：异或（exclusiveor）

5一致性

本文件遵循适用于诊断服务的OSI服务公约（ISO/IEC10731）中的约定。

6DoIP简介

6.1概述

本章给出了一个简明的DoIP会话标准工作流示例。为尽可能对DoIP的新读者有帮助，本章不会提及

在DoIP会话期间可能发生的异常和错误。本章解释了两种可能的网络环境：网络连接和直接连接。图示

提供了一种针对适合的DoIP会话所包含的DoIP组件、机制和序列的更好的理解方式。

由于在直接连接和网络连接两种场景中仅连接和车辆发现（见7.4）存在差异，因此在图11中对这

两种场景DoIP会话的相同部分作了描述。

6.2连接建立和车辆发现

6.2.1直接连接场景

在无网络基础设施的直接连接场景中，为直接将车辆与客户端DoIP实体连接起来，客户端DoIP实体

或服务端DoIP实体的以太网控制器可以使用“交叉”以太网电缆，或者支持Auto-MDI(X)。

9

GB/TXXXXX—XXXX

假设无DHCP服务器的场景，即使已经发起DHCP流程，DHCP流程也不会成功。相反，本地有效的IP

地址将由自动配置机制决定，并被配置给两个相关的接口。

一旦获取到的IP地址配置给DoIP实体的接口，DoIP实体将通过车辆通告报文（见7.4）广播其车辆

识别代号（VIN）、实体识别码（EID）、组识别码（GID）和逻辑地址。该报文会被广播（UDP）三次，

并且该报文的目的端口为UDP_DISCOVERY。

依据客户端DoIP实体是否能够及时地配置TCP/IP通信，来接收初始的车辆通告报文，客户端DoIP

实体可以使用车辆识别请求报文来轮询车辆。由于一些操作系统只在DHCP失败后才启动Auto-IP机制，

所以Auto-IP机制可能在客户端DoIP实体上有延迟。由于服务端DoIP实体同时启动这两种机制，可能其

IP配置会快速完成，且客户端DoIP实体将不会接收到初始的车辆通告报文。

图3描述了在直接连接场景中的连接和车辆发现。

客户端DoIP实体服务端DoIP实体

物理连接

Auto-IP/DHCP请求

Auto-IP/DHCP请求

Auto-IP接口配置Auto-IP接口配置

可选的车辆发现

[客户端已

车辆通告报文（3x）

经可达]

[客户端未接收到初始的车辆通告报文]

车辆识别请求

车辆识别响应

图3在直接连接场景中的连接和车辆发现

6.2.2网络连接场景

在网络连接场景中，连接和车辆发现过程略有不同。与网络的物理连接无需立即同步。因此，用于

TCP/IP连接接口配置和访问的时间点可能会有显著差异。

在特定的网络场景中，可以有多个车辆发送车辆通告报文。如果车辆的DoIP实体未发送车辆通告

报文，客户端DoIP实体可以通过发送车辆识别请求报文进行轮询车辆通告报文。

图4描述了在网络连接场景中的连接和车辆发现。

10

GB/TXXXXX—XXXX

客户端DoIP实体网络服务器DoIP实体

物理连接物理连接

Auto-IP/DHCP请求

Auto-IP/DHCP请求

DHCP响应

DHCP响应

车辆通告（3x）

可选的车辆发现

车辆通告（）

3x[客户端已可达]

[客户端未接收到初始车辆通告]

车辆识别请求

车辆识别请求

车辆识别响应

车辆识别响应

图4在网络连接场景中的连接和车辆发现(车辆通告报文)

6.2.3车内测试场景（可选的）

使用车内测试设备的场景，例如OTA软件更新或者远程诊断。车内测试设备可以取消DHCP或者AutoIP

动态分配IP地址，通过使用静态IP地址分配，从而实现最小化的接口启动时间。在这种场景下车内IP

接口仍然使用车辆通告。

6.2.4非安全的DoIP会话

步骤“添加车辆到列表”（见图5）未包含在本文件中，因此，该步骤非强制，甚至非必需。但在

前一步骤中广播的车辆通告报文可能会以某种方式被处理。例如，车辆会以某种方式告知“就绪”，或

基于当前车辆DoIP会话可用这个信息来启动自动化流程。

虽然在网络连接场景中，客户端和DoIP实体间仍有网络设备，但在两个通信端点间在逻辑上是直接

通信的。因此，在图5中未显示“网络”。

为了初始化客户端DoIP实体和车内DoIP实体间的连接，第一步应打开一个套接字（目的端口为

TCP_DATA）。该步骤必须在任何报文交换前完成。因此，DoIP实体必须提供资源来处理到达的通信请求

（例如，套接字资源）。DoIP实体必须提供足够的资源来处理指定数量的套接字，即能处理并行的DoIP

会话数量（<n>）加一个额外的套接字（见DoIP-002）。若超过<n+1>个连接尝试同时到达，可能无更多

资源可用，且第<n+2>个连接尝试将被拒绝（是因为没有任何套接字处于监听状态，而不是由于DoIP协

议处理的原因）。

一旦套接字被建立，一些初始化步骤会被执行。分配和启动初始非激活定时器（见12.6.3）和常规

非激活定时器（见12.6.2）。此外，通过将连接状态设置为“初始化”(见)，必须确保无路由

11

GB/TXXXXX—XXXX

激活请求报文外的其他数据被路由或者处理。所有后续报文通过该TCP_DATA套接字来交换。在基于安全

的TLS通信和相应的TCP_DATATLS套接字（见6.2.5）场景中，DoIP实体应用也会应用此连接处理行为。

为在初始连接上激活路由，客户端向DoIP实体发送路由激活请求报文（见12.5.2）。若客户端DoIP

实体是满足要求的，且已注册的连接少于<n>，则会终止相应的初始定时器，并且假设不需要额外的认

证或确认或者安全的TLS连接，则套接字状态变为“已注册[路由激活]”。此时可以路由或处理有效的

DoIP报文（例如，DoIP诊断报文），这将通过肯定路由激活响应报文通知客户端DoIP实体。常规非激活

定时器将重启并保持激活状态。

DoIP实体在接收任何类型的数据时，首先调用DoIP报头处理程序。若有效载荷包含诊断报文（通过

通用DoIP报头中的有效载荷类型800116标识，见9.5），则调用诊断报文处理程序来处理该有效载荷。

当诊断报文到达时，在报文成功通过诊断报文处理程序后，应立即向调用的客户端DoIP实体发送

DoIP确认（确认应答），实际上报文已经通过了相应的内部路由机制，但还没有被DoIP网关处理或者转

发到最终的非DoIP服务端。

对于符合GB/T40822的诊断报文载荷，目标服务端DoIP实体将发送诊断响应返回给客户端DoIP实

体。该行为由DoIP报文封装的相应诊断协议来描述，因此而不在本文件的范围内。

当客户端DoIP实体不再需要连接，应总是通过TCP/IP协议机制关闭连接。DoIP实体对该连接启动终

止程序。该终止程序将释放相应的资源，以便该套接字可用于新的连接。若连接未关闭，则资源应在常

规非激活定时器超时或在线检查执行后释放。

图5描述了非安全DoIP会话的示例。

12

GB/TXXXXX—XXXX

客户端DoIP实体服务端DoIP实体车辆非DoIP服务端

操作者

连接和车辆发现（网络连接和直接连接）

增加车辆到列表

创建TCP_DATA套接字

创建套接字

选择车辆

连接TCP_DATA套接字

初始化连接

路由激活请求

常规DoIP报头处理程序

路由激活处理程序

路由激活响应

指示成功连接

循环诊断会话

请求

诊断报文

常规DoIP报头处理程序

DoIP诊断报文处理程序

DoIP诊断响应

（确认应答）诊断请求

诊断响应

诊断响应

响应

退出

关闭TCP_DATA套接字

关闭套接字

终止DoIP会话

图5非安全DoIP会话示例

6.2.5安全的（TLS）DoIP会话

对于安全的TCP连接，使用TLS专用的TCP_DATA端口。对于安全DoIP会话场景，为了初始化客户端DoIP

实体和车内DoIP实体间的安全的TLS连接，第一步应打开一个TLS套接字（目的端口为TLSTCP_DATA）。

该步骤必须在任何报文交换前完成。因此，DoIP实体必须提供资源来处理到达的通信请求（例如，套接

字资源）。DoIP实体提供足够的资源来处理指定数量的套接字，即能处理并行的TLS安全的DoIP会话数

量（<k>）加1个额外套接字（见DoIP-159）。若超过<k+1>个连接尝试同时到达，可能无更多资源可用，

13

GB/TXXXXX—XXXX

且第<k+2>个连接尝试将被拒绝（是因为没有任何套接字处于监听状态，而不是由于DoIP协议处理的原

因）。

一旦套接字被建立，客户端DoIP实体和DoIP实体都将会按照TLS协议规定的握手初始化步骤执行。

在TLS成功完成握手之后，所有后续报文将通过这个TLSTCP_DATA套接字进行交换（例如，路由激活和

DoIP诊断报文）。

图6描述了使用TLS保护的DoIP会话示例。

客户端DoIP实体服务端DoIP实体车辆非DoIPECU

操作者

连接和车辆发现（网连和直连）

增加车辆到列表

创建TLSTCP_DATA套接字

创建套接字

选择车辆

连接TLSTCP_DATA套接字

初始化连接

TLS握手（简化）TLS握手（ClientHello）

TLS握手成功（完成）

安全TLS通信路由激活请求

常规DoIP报头处理程序

路由激活处理程序

路由激活响应

指示成功连接

循环诊断会话

请求

诊断报文

常规DoIP报头处理程序

DoIP诊断报文处理程序

DoIP诊断响应

（确认应答）诊断请求

诊断响应

诊断响应

响应

退出

TCP关闭

关闭套接字

终止DoIP会话

图6使用TLS保护的DoIP会话示例

14

GB/TXXXXX—XXXX

当客户端DoIP实体不再需要安全的TCP连接，应始终通过TLS和TCP/IP协议机制关闭连接（见示例TLS

1.2RFC5246:2008,7.2.1,TLS1.3RFC8446:2018,6.1）。DoIP实体应该清除当前会话中的任何TLS

相关的信息，使相应的资源可用，以便该TLS套接字可用于新的连接。

6.3车辆网络集成

6.3.1车辆识别

车辆识别规定了如何发现车辆及其DoIP实体，并与其网络上的IP地址关联起来。车辆通常是由其VIN

来识别。在制造或售后环境中，在同一车辆上可能安装多个DoIP实体，但此时尚未配置车辆特定的VIN。

为了将新安装和未配置的DoIP实体与车辆相关联，可用GID来代替VIN。

6.3.2单个网络中多台车辆

本章节给出了一个序列示例，通过该序列，外部客户端DoIP实体可以将同一网络内全部连接车辆

的服务端DoIP实体进行识别和分组。

图7显示了由客户端DoIP实体执行的简化标识序列的示例。当车辆已连接到DoIP网络且完成IP

地址分配时（见图5），DoIP实体在等待A_DoIP_Announce_Wait时间后发送车辆通告报文。

若客户端DoIP实体稍晚连接到DoIP网络，应通过广播车辆识别请求来触发车辆通告/识别响应。

所有车辆的服务端DoIP实体在A_DoIP_Ctrl时间内响应车辆识别请求。

若客户端DoIP实体接收车辆通告/车辆识别并包含VIN/GID同步状态为未完成的报文（1016），这

意味着VIN或GID与车辆中的所有服务端DoIP实体不同步，客户端DoIP实体将启动该车辆的车辆发现

定时器（由VIN/GID主节点在其车辆通告/车辆识别响应中给定的VIN/GID来标识）。

该机制允许VIN/GID主节点在某些实体需要更多时间同步VIN/GID时通知客户端DoIP实体。当车辆发

现定时器超时，将向所有这些DoIP实体发送另一个车辆识别请求，这些DoIP实体在最初的车辆通告/识

别响应中报告VIN/GID无效。