道路車輛 基于因特網(wǎng)協(xié)議的診斷通信（DoIP） 第2部分：傳輸協(xié)議與網(wǎng)絡層服務

ICS43.040.10

CCST36

中華人民共和國國家標準

GB/TXXXXX—XXXX

道路車輛基于因特網(wǎng)協(xié)議的診斷通信

（DoIP）第2部分：傳輸協(xié)議與網(wǎng)絡層服務

Roadvehicles—DiagnosticcommunicationoverInternetProtocol(DoIP)

—Part2:Transportprotocolandnetworklayerservices

（送審稿）

（ISO13400-2:2019，MOD）

（征求意見稿）

完成時間：2022.3.23

在提交反饋意見時，請將您知道的相關專利連同支持性文件一并附上。

GB/TXXXXX—XXXX

前言

本文件按照GB/T1.1—2020《標準化工作導則第1部分：標準化文件的結構和起草規(guī)則》的規(guī)定

起草。

本文件是GB/TXXXXX《道路車輛基于因特網(wǎng)協(xié)議的診斷通信》的第2部分。GB/TXXXXX已經(jīng)

發(fā)布了以下部分：

——第2部分：傳輸協(xié)議與網(wǎng)絡層服務；

——第3部分：基于IEEE802.3有線車輛接口；

——第4部分：基于以太網(wǎng)的高速數(shù)據(jù)鏈路連接器。

本文件修改采用ISO13400-2:2019《道路車輛基于因特網(wǎng)協(xié)議的診斷通信第2部分：傳輸協(xié)議與

網(wǎng)絡層服務》。

本文件與ISO13400-2:2019的技術差異及其原因如下：

——增加了縮略語“PDU”和“OTA”（見4.2），以提高文件易用性。

——在“推薦DoIP實體采用表15中定義的參數(shù)值”中，將“DoIP實體可在大概2秒內配置其IP地址”

修改為“DoIP實體可在大概7秒內配置其IP地址”，將“可在7秒后完成IP地址的配置”修改為“可在2

秒后完成IP地址的配置”（見），修改后的定時參數(shù)與表15的參數(shù)是一致匹配的。

——在“有效載荷類型根據(jù)報文內容被分組”中將“節(jié)點管理（XX1616）”更改為“0XXX16”

（見9.2），已適應我國的技術條件、提高可操作性。

本文件做了下列編輯性改動：

——刪除國際標準的前言；

——將國際標準中表述自身的“本部分”或“本標準”改為“本文件”；

——修改國際標準的引言；

——規(guī)范性引用文件由國際標準替換為修改采用的國家標準。

請注意本文件的某些內容可能涉及專利。本文件的發(fā)布機構不承擔識別專利的責任。

本文件由中華人民共和國工業(yè)和信息化部提出。

本文件由全國汽車標準化技術委員會（SAC/TC114）歸口。

本文件起草單位：

本文件主要起草人：

4

GB/TXXXXX—XXXX

引言

隨著服務器內存大小的增加、更新軟件數(shù)量的增加以及這些控制單元、連接網(wǎng)絡和總線技術提供的

功能數(shù)量的增加，其復雜性和速度已達到類似于計算機網(wǎng)絡的水平。

GB/TXXXXX的所有部分是為了定義在IP通信鏈路上實施的車輛診斷系統(tǒng)的通用要求。GB/T

XXXXX的目的是描述一個標準化的車輛接口，該接口：

——將車載網(wǎng)絡技術與客戶端DoIP實體車輛接口要求分離，以實現(xiàn)長期穩(wěn)定的外部車輛通信接口；

——利用現(xiàn)有的標準來定義可用于診斷通信以及制造商特定用例的長期穩(wěn)定的先進通信標準；

——通過使用現(xiàn)有的適配層，可以很容易地適應新的物理層和數(shù)據(jù)鏈路層，包括有線和無線連接；

——允許車輛內部和車輛外部DoIP實體的連接。

GB/TXXXXX由4部分構成：

——第1部分：一般信息和使用案例定義。規(guī)定了客戶端DoIP實體與服務端DoIP實體之間的車

輛診斷的一般信息和使用案例定義，旨在為系列文件提供引言。

——第2部分：傳輸協(xié)議與網(wǎng)絡層服務。規(guī)定了客戶端DoIP實體使用底層協(xié)議棧的要求，并且采

用安全和非安全的診斷通信要求，旨在說明客戶端DoIP實體與服務端DoIP實體連接與通信

過程。

——第3部分：基于IEEE802.3有線車輛接口。詳細介紹了基于IEEE802.3100BASE-TX的物理

層和數(shù)據(jù)鏈路層的車載通信接口和測試設備要求，旨在提供標準的物理連接接口。

——第4部分：基于以太網(wǎng)的高速數(shù)據(jù)鏈路連接器。規(guī)定了車輛連接器的功能要求，旨在統(tǒng)一外部

連接器。

圖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章節(jié)

UDSonIP(基于IP的統(tǒng)一診斷服務)

應用層服務接口

OSI第7層GB/T40822

應用層第4~6章節(jié)

應用層

表示層標準

車輛制造商規(guī)定或

OSI第6層ISO22901ODX

表示層

上層服務接口

OSI第5層GB/T40822第7章節(jié)

會話層會話層服務

會話層服務接口

傳輸層服務接口

GB/TXXXXX.2DoIP

OSI第4層

第2部分：傳輸協(xié)議和網(wǎng)絡層服務

傳輸層

安全傳輸層協(xié)議（TLS）

傳輸控制協(xié)議（TCP）

用戶數(shù)據(jù)報協(xié)議（UDP）

因特網(wǎng)協(xié)議（IP）

OSI第3層

網(wǎng)絡層數(shù)據(jù)鏈路層服務接口

OSI第2層數(shù)據(jù)鏈路層服務接口

數(shù)據(jù)鏈路層GB/TXXXXX.3DoIP

第3部分：基于IEEE802.3有線車輛接口

OSI第1層

物理層

OSI底層框架

圖1根據(jù)OSI模型DoIP文檔參考

圖2從功能角度說明了車輛網(wǎng)絡架構示意圖。

3

GB/TXXXXX—XXXX

車輛網(wǎng)絡

ECU1ECUI

ECU2ECUII

...

...

ECUnECUn

客戶端2

(測試設備)

車輛子網(wǎng)絡車輛子網(wǎng)絡

DoIP邊緣DoIP邊緣

節(jié)點...節(jié)點網(wǎng)絡節(jié)點1...DoIP節(jié)點

網(wǎng)關1網(wǎng)關m

基于IP的網(wǎng)絡

外部網(wǎng)絡基于IP的網(wǎng)絡

激活線客戶端1網(wǎng)絡節(jié)點

網(wǎng)絡節(jié)點2

(測試設備)...n

圖2車輛網(wǎng)絡架構示意圖（功能視圖）

本文件由一個或多個DoIP實體實施，具體取決于車輛的網(wǎng)絡架構。圖2顯示了客戶端1（外部客

戶端），它連接到DoIP邊緣節(jié)點和車輛內部網(wǎng)絡中的客戶端2（內部客戶端）。如果沒有額外說明，

無論它們連接到哪個網(wǎng)絡，假定客戶端DoIP實體的行為相同。

在本文件中，為需求分配了“X.DoIP-yyy”形式的唯一編號，以便于跟蹤和參考需求。編號表達式中

參數(shù)含義為：

——X：OSI層數(shù)；

——DoIP-yyy：需求序號；

——OSI層縮寫：[8=APP（應用），7=AL（應用層），6=PL（表示層），5=SL（會話層），4=TL

（傳輸層），3=NL（網(wǎng)絡層），2=DLL（數(shù)據(jù)鏈路層），1=PHY（物理層），0=SPP]

注：本文檔中的需求沒有按順序編號，因為在文檔開發(fā)過程中各個需求的順序發(fā)生了變化。

4

GB/TXXXXX—XXXX

道路車輛基于因特網(wǎng)協(xié)議的診斷通信（DoIP）第2部分：傳輸協(xié)議

與網(wǎng)絡層服務

1范圍

本文件規(guī)定了客戶端DoIP實體與使用因特網(wǎng)協(xié)議（IP）、傳輸控制協(xié)議（TCP）以及用戶數(shù)據(jù)報協(xié)

議（UDP）并安裝在車輛內的服務器之間進行安全的和非安全的診斷通信要求。該要求包括定義車輛網(wǎng)

關要求（例如，集成到現(xiàn)有計算機網(wǎng)絡）與測試設備要求（例如，檢測并與車輛建立通信）。

本文件規(guī)定了在網(wǎng)絡中檢測車輛的功能，并在各種車輛狀態(tài)下與車輛網(wǎng)關及其子模塊進行通信的功

能。這些功能被劃分為強制與可選兩大類。

本文件規(guī)定了以下強制（必選）功能：

——車輛網(wǎng)絡集成（IP地址分配）；

——車輛通告與車輛發(fā)現(xiàn)；

——車輛基本狀態(tài)信息獲?。ㄈ缭\斷電源模式）；

——連接建立（例如，并行通信嘗試），連接維持與車輛網(wǎng)關控制；

——車輛子模塊的數(shù)據(jù)進出路由；

——錯誤處理（例如，物理網(wǎng)絡斷開）。

本文件規(guī)定了以下可選功能：

——DoIP實體狀態(tài)監(jiān)控；

——傳輸層安全協(xié)議（TLS）；

——DoIP實體防火墻性能。

2規(guī)范性引用文件

下列文件中的內容通過文中的規(guī)范性引用而構成本文件必不可少的條款。其中，注日期的引用文件，

僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適用于本

文件。

ISO/IEC7498-1-1994信息處理系統(tǒng)開放系統(tǒng)互連第1部分：基本參考模式（Information

technology—OpenSystemsInterconnection—BasicReferenceModel:TheBasicModel）

注：GB/T9387.1-1998信息技術開放系統(tǒng)互連基本參考模型第1部分:基本模型(ISO/IEC7498-1:1994，IDT)

ISO13400-3道路車輛基于因特網(wǎng)協(xié)議的診斷通信第3部分：基于IEEE802.3有線車輛接口

[Roadvehicles—DiagnosticcommunicationoverInternetProtocol(DolP)—Part3:Wiredvehicle

interfacebasedonIEEE802.3]

注：GB/TXXXXX.3-XXXX基于因特網(wǎng)協(xié)議的診斷通信第3部分：基于IEEE802.3有線車輛接口(ISO

13400-3:2016，MOD)

ISO/IEC/IEEE8802-3信息技術系統(tǒng)間的電信和信息交換局域網(wǎng)和城市區(qū)域網(wǎng)具體需求第

3部分：以太網(wǎng)標準（Informationtechnology—Telecommunicationsandexchangebetween

informationtechnologysystems—Requirementsforlocalandmetropolitanareanetworks—

Specificrequirements—Part3:StandardforEthernet）

5

GB/TXXXXX—XXXX

IETFRFC768用戶數(shù)據(jù)報協(xié)議（UserDatagramProtocol）

IETFRFC791:1981因特網(wǎng)協(xié)議—DARPA因特網(wǎng)互聯(lián)程序—協(xié)議規(guī)范(InternetProtocol—DARPA

InternetProgram—ProtocolSpecification)

IETFRFC792網(wǎng)絡控制報文協(xié)議—DARPA因特網(wǎng)互聯(lián)程序—協(xié)議規(guī)范(InternetControlMessage

Protocol—DARPAInternetProgram—ProtocolSpecification)

IETFRFC793傳輸控制協(xié)議—DARPA因特網(wǎng)互聯(lián)程序—協(xié)議規(guī)范(TransmissionControl

Protocol—DARPAInternetProgram—ProtocolSpecification)

IETFRFC826以太網(wǎng)地址解析協(xié)議(AnEthernetAddressResolutionProtocol)

IETFRFC1122因特網(wǎng)主機需求—通信層(RequirementsforInternetHosts—Communication

Layers)

IETFRFC2131動態(tài)主機配置協(xié)議(DynamicHostConfigurationProtocol)

IETFRFC2132DHCP可選項和BOOTP供應商擴展(DHCPOptionsandBOOTPVendorExtensions)

IETFRFC2460互聯(lián)網(wǎng)協(xié)議第六版（IPv6）規(guī)范[InternetProtocol,Version6

(IPv6)—Specification]

IETFRFC2375IPv6組播地址分配(IPv6MulticastAddressAssignments)

IETFRFC3315Ipv6動態(tài)主機配置協(xié)議（DHCPv6）[DynamicHostConfigurationProtocolforIPv6

(DHCPv6)]

IETFRFC3484互聯(lián)網(wǎng)協(xié)議第六版（IPv6）默認地址選擇[DefaultAddressSelectionforInternet

Protocolversion6(IPv6)]

IETFRFC3927IPv4本地鏈路地址動態(tài)配置(DynamicConfigurationofIPv4Link-Local

Addresses)

IETFRFC4291IPv6尋址架構IP(Version6AddressingArchitecture)

IETFRFC4443因特網(wǎng)協(xié)議第六版（IPv6）網(wǎng)絡控制報文協(xié)議（ICMPv6）規(guī)范[InternetControl

MessageProtocol(ICMPv6)fortheInternetProtocolVersion6(IPv6)Specification]

IETFRFC4702動態(tài)主機配置協(xié)議完全限定域名[TheDynamicHostConfigurationProtocol

(DHCP)ClientFullyQualifiedDomainName(FQDN)Option]

IETFRFC4861IPv6鄰居發(fā)現(xiàn)協(xié)議[NeighborDiscoveryforIPversion6(IPv6)]

IETFRFC4862IPv6無狀態(tài)地址自動配置(IPv6StatelessAddressAutoconfiguration)

IETFRFC5246傳輸層安全協(xié)議1.2[TheTransportLayerSecurity(TLS)ProtocolVersion1.2]

IETFRFC8446:2018傳輸層安全協(xié)議1.3[TheTransportLayerSecurity(TLS)ProtocolVersion

1.3]

3術語和定義

ISO/IEC7498-1界定的以及下列術語和定義適用于本文件。

3.1

診斷電源模式diagnosticpowermode

抽象的車輛內部電源供應狀態(tài)，該狀態(tài)影響車內網(wǎng)絡上所有ECU的診斷功能，并識別允許診斷通信

的所有網(wǎng)關子網(wǎng)絡上所有ECU的狀態(tài)。

注：目的是為客戶端DoIP實體提供信息，包括是否可以在連接的車輛上執(zhí)行診斷，或車輛是否需要進入不同的診

斷電源模式（即需要技術人員交互）。本文件定義了如下狀態(tài)：“未準備好”（部分基于DoIP的服務端可通信

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

（不支持診斷電源模式信息的診斷請求報文）。

6

GB/TXXXXX—XXXX

3.2

DoIP邊緣節(jié)點DoIPedgenode

車內主機（3.4），在此處符合GB/TXXXXX.3的以太網(wǎng)激活線所在終端，以及外部網(wǎng)絡中的第一個

節(jié)點或主機的鏈路所在終端。

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

3.3

DoIP實體證書DoIPentitycertificate

證書由中間證書頒發(fā)機構（3.5）發(fā)放至DoIP實體，用以TLS握手過程中提供給客戶端DoIP實體

進行驗證其真實性。

3.4

主機host

連接到基于IP網(wǎng)絡的節(jié)點

3.5

中間證書頒發(fā)機構intermediatecertificateauthority

IntermediateCA

頒發(fā)后續(xù)證書至其他中間證書頒發(fā)機構或DoIP實體。

3.6

中間證書intermediatecertificate

存儲在客戶端DoIP實體本地或在身份驗證過程中與端節(jié)點證書一同提供以完成信任鏈。

3.7

無效的源地址invalidsourceaddress

為客戶端DoIP實體預留的地址范圍外的源地址

3.8

邏輯地址logicaladdress

識別診斷應用層實體的地址

3.9

網(wǎng)絡節(jié)點networknode

連接到基于IP的網(wǎng)絡（例如，以太網(wǎng)），并使用IP通信，但不支持基于DoIP協(xié)議的節(jié)點。

注：某些網(wǎng)絡節(jié)點可能也與車輛子網(wǎng)絡（3.14）連接，但由于不支持DoIP協(xié)議，所以這些網(wǎng)絡節(jié)點不是DoIP網(wǎng)關。

因此，這些網(wǎng)絡節(jié)點不會與遵循DoIP的客戶端有交互（如響應外部請求）。

3.10

根證書頒發(fā)機構rootcertificateauthority

頒發(fā)根證書的機構

注：發(fā)放中間證書（3.6）以允許中間證書頒發(fā)機構（3.5）進一步發(fā)放證書。

3.11

根證書rootcertificate

由根證書頒發(fā)機構（3.10）創(chuàng)建并用作信任錨的證書。

注：所有想要驗證終端節(jié)點證書的實體（例如，來自DoIP實體）安全地存儲和使用根證書，以及信任鏈中的所有

必要的中間證書（3.6）。

3.12

7

GB/TXXXXX—XXXX

套接字socket

在IETFRFC147定義的唯一標識，該標識用于在網(wǎng)絡上發(fā)送或接收信息

3.13

未知源地址unknownsourceaddress

未在連接表內列出的地址

3.14

車輛子網(wǎng)絡vehiclesub-network

非直接與基于IP的網(wǎng)絡相連接的車輛網(wǎng)絡

注：來自及傳向車內子網(wǎng)絡的數(shù)據(jù)，僅能經(jīng)由所連接的DoIP網(wǎng)關進行傳輸。

4符號和縮略語

4.1符號

下列符號適用于本文件。

<d>：有效載荷長度，單位為字節(jié)。

<k>：為了與一個或多個客戶端DoIP實體并行的1至K個TLS安全的連接，DoIP實體需要支持的

并行DoIPTLSTCP會話的數(shù)量。

<m>：為了連接一個或多個DoIP實體，客戶端DoIP實體需要支持的并行DoIPTCP會話的數(shù)量。

<n>：為了與一個或多個客戶端DoIP實體并行的1至N個連接，DoIP實體需要支持的并行DoIPTCP

會話的數(shù)量。

<u>,<v>：車輛子網(wǎng)上獨立服務端的數(shù)量

<w>：車輛網(wǎng)絡上獨立DoIP網(wǎng)關的數(shù)量

<x>：獨立的車內網(wǎng)絡節(jié)點數(shù)量

<y>：車輛網(wǎng)絡中獨立的DoIP節(jié)點數(shù)量

<z>：獨立的車輛外部網(wǎng)絡節(jié)點數(shù)量

4.2縮略語

下列縮略語適用于本文件。

AL：應用層（applicationlayer）

Alt：可替代，備選（alternative）

APP：應用（application）

ARP：地址解析協(xié)議（addressresolutionprotocol）

ASCII：美國信息交換標準代碼（Americanstandardcodeforinformationinterchange）

Auto-MDI(X)：自動介質相關接口交叉（automaticmedium-dependentinterfacecrossover）

CA：證書授權（certificateauthority）

CAN：控制器局域網(wǎng)（controllerareanetwork）

CF：連續(xù)幀（consecutiveframe）

DHCP：動態(tài)主機配置協(xié)議（dynamichostcontrolprotocol）

DLL：數(shù)據(jù)鏈路層（datalinklayer）

DNS：域名系統(tǒng)（domainnamesystem）

DoIP：基于IP的診斷通信（diagnosticcommunicationoverinternetprotocol）

EID：實體標識（entityidentification）

FF：首幀（firstframe）

GID：組標識（groupidentification）

GUI：圖形用戶界面（graphicaluserinterface）

GW：網(wǎng)關（gateway）

8

GB/TXXXXX—XXXX

IANA：因特網(wǎng)編號管理局（Internetassignednumbersauthority）

ICMP：網(wǎng)絡控制報文協(xié)議（Internetcontrolmessageprotocol）

IETFRFC：互聯(lián)網(wǎng)工程任務組請求注釋（InternetEngineeringTaskForceRequestforComments）

IP：因特網(wǎng)協(xié)議（Internetprotocol）

IPv4：因特網(wǎng)協(xié)議第4版（見IETFRFC791）[Internetprotocolversion4(seeIETFRFC791)]

IPv6：因特網(wǎng)協(xié)議第6版（見IETFRFC2460）[Internetprotocolversion6(seeIETFRFC2460)]

MAC：介質訪問控制（mediaaccesscontrol）

MSC：消息序列圖（messagesequencechart）

MTU：最大傳輸單元（maximumtransportunit）

NDP：鄰居發(fā)現(xiàn)協(xié)議（neighbourdiscoveryprotocol）

NL：網(wǎng)絡層（networklayer）

OSI：開放系統(tǒng)互連（opensystemsinterconnection）

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

PKI：公鑰基礎設施（publickeyinfrastructure）

PDU：協(xié)議數(shù)據(jù)單元（protocoldataunit）

SA：源地址（sourceaddress）

SDU：服務數(shù)據(jù)單元（servicedataunit）

SF：單幀（singleframe）

SPN：可疑參數(shù)編號（suspectparameternumber）

SPP：服務原語參數(shù)（serviceprimitiveparameter）

TA：目標地址（targetaddress）

TCP：傳輸控制協(xié)議（transmissioncontrolprotocol）

TL：傳輸層（transportlayer）

TLS：傳輸層安全協(xié)議（transportlayersecurity）

UDP：用戶數(shù)據(jù)報協(xié)議（userdatagramprotocol）

VIN：車輛識別代號（見ISO3779）[vehicleidentificationnumber(seeISO3779)]

VM：車輛制造商（vehiclemanufacturer）

XOR：異或（exclusiveor）

5一致性

本文件遵循適用于診斷服務的OSI服務公約（ISO/IEC10731）中的約定。

6DoIP簡介

6.1概述

本章給出了一個簡明的DoIP會話標準工作流示例。為盡可能對DoIP的新讀者有幫助，本章不會提及

在DoIP會話期間可能發(fā)生的異常和錯誤。本章解釋了兩種可能的網(wǎng)絡環(huán)境：網(wǎng)絡連接和直接連接。圖示

提供了一種針對適合的DoIP會話所包含的DoIP組件、機制和序列的更好的理解方式。

由于在直接連接和網(wǎng)絡連接兩種場景中僅連接和車輛發(fā)現(xiàn)（見7.4）存在差異，因此在圖11中對這

兩種場景DoIP會話的相同部分作了描述。

6.2連接建立和車輛發(fā)現(xiàn)

6.2.1直接連接場景

在無網(wǎng)絡基礎設施的直接連接場景中，為直接將車輛與客戶端DoIP實體連接起來，客戶端DoIP實體

或服務端DoIP實體的以太網(wǎng)控制器可以使用“交叉”以太網(wǎng)電纜，或者支持Auto-MDI(X)。

9

GB/TXXXXX—XXXX

假設無DHCP服務器的場景，即使已經(jīng)發(fā)起DHCP流程，DHCP流程也不會成功。相反，本地有效的IP

地址將由自動配置機制決定，并被配置給兩個相關的接口。

一旦獲取到的IP地址配置給DoIP實體的接口，DoIP實體將通過車輛通告報文（見7.4）廣播其車輛

識別代號（VIN）、實體識別碼（EID）、組識別碼（GID）和邏輯地址。該報文會被廣播（UDP）三次，

并且該報文的目的端口為UDP_DISCOVERY。

依據(jù)客戶端DoIP實體是否能夠及時地配置TCP/IP通信，來接收初始的車輛通告報文，客戶端DoIP

實體可以使用車輛識別請求報文來輪詢車輛。由于一些操作系統(tǒng)只在DHCP失敗后才啟動Auto-IP機制，

所以Auto-IP機制可能在客戶端DoIP實體上有延遲。由于服務端DoIP實體同時啟動這兩種機制，可能其

IP配置會快速完成，且客戶端DoIP實體將不會接收到初始的車輛通告報文。

圖3描述了在直接連接場景中的連接和車輛發(fā)現(xiàn)。

客戶端DoIP實體服務端DoIP實體

物理連接

Auto-IP/DHCP請求

Auto-IP/DHCP請求

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

可選的車輛發(fā)現(xiàn)

[客戶端已

車輛通告報文（3x）

經(jīng)可達]

[客戶端未接收到初始的車輛通告報文]

車輛識別請求

車輛識別響應

圖3在直接連接場景中的連接和車輛發(fā)現(xiàn)

6.2.2網(wǎng)絡連接場景

在網(wǎng)絡連接場景中，連接和車輛發(fā)現(xiàn)過程略有不同。與網(wǎng)絡的物理連接無需立即同步。因此，用于

TCP/IP連接接口配置和訪問的時間點可能會有顯著差異。

在特定的網(wǎng)絡場景中，可以有多個車輛發(fā)送車輛通告報文。如果車輛的DoIP實體未發(fā)送車輛通告

報文，客戶端DoIP實體可以通過發(fā)送車輛識別請求報文進行輪詢車輛通告報文。

圖4描述了在網(wǎng)絡連接場景中的連接和車輛發(fā)現(xiàn)。

10

GB/TXXXXX—XXXX

客戶端DoIP實體網(wǎng)絡服務器DoIP實體

物理連接物理連接

Auto-IP/DHCP請求

Auto-IP/DHCP請求

DHCP響應

DHCP響應

車輛通告（3x）

可選的車輛發(fā)現(xiàn)

車輛通告（）

3x[客戶端已可達]

[客戶端未接收到初始車輛通告]

車輛識別請求

車輛識別請求

車輛識別響應

車輛識別響應

圖4在網(wǎng)絡連接場景中的連接和車輛發(fā)現(xiàn)(車輛通告報文)

6.2.3車內測試場景（可選的）

使用車內測試設備的場景，例如OTA軟件更新或者遠程診斷。車內測試設備可以取消DHCP或者AutoIP

動態(tài)分配IP地址，通過使用靜態(tài)IP地址分配，從而實現(xiàn)最小化的接口啟動時間。在這種場景下車內IP

接口仍然使用車輛通告。

6.2.4非安全的DoIP會話

步驟“添加車輛到列表”（見圖5）未包含在本文件中，因此，該步驟非強制，甚至非必需。但在

前一步驟中廣播的車輛通告報文可能會以某種方式被處理。例如，車輛會以某種方式告知“就緒”，或

基于當前車輛DoIP會話可用這個信息來啟動自動化流程。

雖然在網(wǎng)絡連接場景中，客戶端和DoIP實體間仍有網(wǎng)絡設備，但在兩個通信端點間在邏輯上是直接

通信的。因此，在圖5中未顯示“網(wǎng)絡”。

為了初始化客戶端DoIP實體和車內DoIP實體間的連接，第一步應打開一個套接字（目的端口為

TCP_DATA）。該步驟必須在任何報文交換前完成。因此，DoIP實體必須提供資源來處理到達的通信請求

（例如，套接字資源）。DoIP實體必須提供足夠的資源來處理指定數(shù)量的套接字，即能處理并行的DoIP

會話數(shù)量（<n>）加一個額外的套接字（見DoIP-002）。若超過<n+1>個連接嘗試同時到達，可能無更多

資源可用，且第<n+2>個連接嘗試將被拒絕（是因為沒有任何套接字處于監(jiān)聽狀態(tài)，而不是由于DoIP協(xié)

議處理的原因）。

一旦套接字被建立，一些初始化步驟會被執(zhí)行。分配和啟動初始非激活定時器（見12.6.3）和常規(guī)

非激活定時器（見12.6.2）。此外，通過將連接狀態(tài)設置為“初始化”(見)，必須確保無路由

11

GB/TXXXXX—XXXX

激活請求報文外的其他數(shù)據(jù)被路由或者處理。所有后續(xù)報文通過該TCP_DATA套接字來交換。在基于安全

的TLS通信和相應的TCP_DATATLS套接字（見6.2.5）場景中，DoIP實體應用也會應用此連接處理行為。

為在初始連接上激活路由，客戶端向DoIP實體發(fā)送路由激活請求報文（見12.5.2）。若客戶端DoIP

實體是滿足要求的，且已注冊的連接少于<n>，則會終止相應的初始定時器，并且假設不需要額外的認

證或確認或者安全的TLS連接，則套接字狀態(tài)變?yōu)椤耙炎訹路由激活]”。此時可以路由或處理有效的

DoIP報文（例如，DoIP診斷報文），這將通過肯定路由激活響應報文通知客戶端DoIP實體。常規(guī)非激活

定時器將重啟并保持激活狀態(tài)。

DoIP實體在接收任何類型的數(shù)據(jù)時，首先調用DoIP報頭處理程序。若有效載荷包含診斷報文（通過

通用DoIP報頭中的有效載荷類型800116標識，見9.5），則調用診斷報文處理程序來處理該有效載荷。

當診斷報文到達時，在報文成功通過診斷報文處理程序后，應立即向調用的客戶端DoIP實體發(fā)送

DoIP確認（確認應答），實際上報文已經(jīng)通過了相應的內部路由機制，但還沒有被DoIP網(wǎng)關處理或者轉

發(fā)到最終的非DoIP服務端。

對于符合GB/T40822的診斷報文載荷，目標服務端DoIP實體將發(fā)送診斷響應返回給客戶端DoIP實

體。該行為由DoIP報文封裝的相應診斷協(xié)議來描述，因此而不在本文件的范圍內。

當客戶端DoIP實體不再需要連接，應總是通過TCP/IP協(xié)議機制關閉連接。DoIP實體對該連接啟動終

止程序。該終止程序將釋放相應的資源，以便該套接字可用于新的連接。若連接未關閉，則資源應在常

規(guī)非激活定時器超時或在線檢查執(zhí)行后釋放。

圖5描述了非安全DoIP會話的示例。

12

GB/TXXXXX—XXXX

客戶端DoIP實體服務端DoIP實體車輛非DoIP服務端

操作者

連接和車輛發(fā)現(xiàn)（網(wǎng)絡連接和直接連接）

增加車輛到列表

創(chuàng)建TCP_DATA套接字

創(chuàng)建套接字

選擇車輛

連接TCP_DATA套接字

初始化連接

路由激活請求

常規(guī)DoIP報頭處理程序

路由激活處理程序

路由激活響應

指示成功連接

循環(huán)診斷會話

請求

診斷報文

常規(guī)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實體提供足夠的資源來處理指定數(shù)量的套接字，即能處理并行的TLS安全的DoIP會話數(shù)

量（<k>）加1個額外套接字（見DoIP-159）。若超過<k+1>個連接嘗試同時到達，可能無更多資源可用，

13

GB/TXXXXX—XXXX

且第<k+2>個連接嘗試將被拒絕（是因為沒有任何套接字處于監(jiān)聽狀態(tài)，而不是由于DoIP協(xié)議處理的原

因）。

一旦套接字被建立，客戶端DoIP實體和DoIP實體都將會按照TLS協(xié)議規(guī)定的握手初始化步驟執(zhí)行。

在TLS成功完成握手之后，所有后續(xù)報文將通過這個TLSTCP_DATA套接字進行交換（例如，路由激活和

DoIP診斷報文）。

圖6描述了使用TLS保護的DoIP會話示例。

客戶端DoIP實體服務端DoIP實體車輛非DoIPECU

操作者

連接和車輛發(fā)現(xiàn)（網(wǎng)連和直連）

增加車輛到列表

創(chuàng)建TLSTCP_DATA套接字

創(chuàng)建套接字

選擇車輛

連接TLSTCP_DATA套接字

初始化連接

TLS握手（簡化）TLS握手（ClientHello）

TLS握手成功（完成）

安全TLS通信路由激活請求

常規(guī)DoIP報頭處理程序

路由激活處理程序

路由激活響應

指示成功連接

循環(huán)診斷會話

請求

診斷報文

常規(guī)DoIP報頭處理程序

DoIP診斷報文處理程序

DoIP診斷響應

（確認應答）診斷請求

診斷響應

診斷響應

響應

退出

TCP關閉

關閉套接字

終止DoIP會話

圖6使用TLS保護的DoIP會話示例

14

GB/TXXXXX—XXXX

當客戶端DoIP實體不再需要安全的TCP連接，應始終通過TLS和TCP/IP協(xié)議機制關閉連接（見示例TLS

1.2RFC5246:2008,7.2.1,TLS1.3RFC8446:2018,6.1）。DoIP實體應該清除當前會話中的任何TLS

相關的信息，使相應的資源可用，以便該TLS套接字可用于新的連接。

6.3車輛網(wǎng)絡集成

6.3.1車輛識別

車輛識別規(guī)定了如何發(fā)現(xiàn)車輛及其DoIP實體，并與其網(wǎng)絡上的IP地址關聯(lián)起來。車輛通常是由其VIN

來識別。在制造或售后環(huán)境中，在同一車輛上可能安裝多個DoIP實體，但此時尚未配置車輛特定的VIN。

為了將新安裝和未配置的DoIP實體與車輛相關聯(lián)，可用GID來代替VIN。

6.3.2單個網(wǎng)絡中多臺車輛

本章節(jié)給出了一個序列示例，通過該序列，外部客戶端DoIP實體可以將同一網(wǎng)絡內全部連接車輛

的服務端DoIP實體進行識別和分組。

圖7顯示了由客戶端DoIP實體執(zhí)行的簡化標識序列的示例。當車輛已連接到DoIP網(wǎng)絡且完成IP

地址分配時（見圖5），DoIP實體在等待A_DoIP_Announce_Wait時間后發(fā)送車輛通告報文。

若客戶端DoIP實體稍晚連接到DoIP網(wǎng)絡，應通過廣播車輛識別請求來觸發(fā)車輛通告/識別響應。

所有車輛的服務端DoIP實體在A_DoIP_Ctrl時間內響應車輛識別請求。

若客戶端DoIP實體接收車輛通告/車輛識別并包含VIN/GID同步狀態(tài)為未完成的報文（1016），這

意味著VIN或GID與車輛中的所有服務端DoIP實體不同步，客戶端DoIP實體將啟動該車輛的車輛發(fā)現(xiàn)

定時器（由VIN/GID主節(jié)點在其車輛通告/車輛識別響應中給定的VIN/GID來標識）。

該機制允許VIN/GID主節(jié)點在某些實體需要更多時間同步VIN/GID時通知客戶端DoIP實體。當車輛發(fā)

現(xiàn)定時器超時，將向所有這些DoIP實體發(fā)送另一個車輛識別請求，這些DoIP實體在最初的車輛通告/識

別響應中報告VIN/GID無效。