道路車輛基于因特網協議的診斷通信第2部分：傳輸協議與網絡層服務Roadvehicles—Diagnosticcommunicati2023-11-27發布2023-11-27實施國家標準化管理委員會 12規范性引用文件 l3術語和定義 24符號和縮略語 44.1符號 44.2縮略語 45一致性 56DoIP簡介 56.1概述 56.2連接建立和車輛發現 66.3車輛網絡集成 6.4應用報文序列圖的通信示例 6.5基于IP的車輛通信協議——概述 7應用(APP)需求 7.2APP數據傳輸順序 7.3APPDoIP實體的車輛GID同步 7.4APP車輛識別和通告請求報文 7.5APP診斷電源模式信息請求和響應 217.6APPDoIP實體狀態信息請求和響應 7.7APP定時和通信參數 7.8APP邏輯尋址方式 7.9APP通信環境及推薦定時 7.10APPDoIP實體功能需求 8服務接口 8.1概述 8.2服務原語參數(SPP) 8.3SPPDoIP層服務接口 9應用層(AL) 9.1AL動態主機配置協議(DHCP) 9.2AL通用DoIP協議報文結構 IⅡ9.3ALUDP數據包和TCP數據的處理 9.4ALTCP和UDP端口上支持的有效載荷類型 9.5AL診斷報文和診斷報文應答 9.6AL在線檢查請求和在線檢查響應 10傳輸層安全(TLS) 10.1TLS安全診斷通信 10.2TLSDoIP應用文件 11傳輸層(TL) 11.1TL傳輸層控制協議(TCP) 11.2TL用戶數據報協議(UDP) 11.3TLUDP報文的處理 12網絡層(NL) 12.1NL網絡層協議(IP) 12.2NL地址解析協議(ARP) 12.3NLIPv6鄰居發現協議(NDP) 12.4NL因特網控制消息協議(ICMP) 12.6NL套接字處理 13DLL數據鏈路層(DLL) 參考文獻 Ⅲ本文件按照GB/T1.1—2020《標準化工作導則第1部分：標準化文件的結構和起草規則》的規定起草。本文件是GB/T43258《道路車輛基經發布了以下部分：——第2部分：傳輸協議與網絡層服務；——第3部分：基于IEEE802.3有線車輛接口；——第4部分：基于以太網的高速數據鏈路連接器。本文件修改采用ISO13400-2:2019《道路車輛基于因特網協議的診斷通信(DoIP)第2部分：本文件與ISO13400-2:2019的技術差異及其原因如下：——用規范性引用的GB16735替換了ISO3779(見表4和表5),以適應我國的技術條件，增加可——增加了符號<k>(見4.1),以提高文件易用性；——增加了縮略語AutoIP、PDU和OTA,刪除了未使用的縮略語FMI(見4.2),以提高文件易——將“DoIP實體可在大概2s內配置其IP地址”更改為“DoIP實體可在大概7s內配置其IP地址”,將“可在7s后完成IP地址的配置”更改為“可在2s后完成IP地址的配置”(見),修改后的定時參數與表15的參數是一致匹配的；(見9.2),以適應我國的技術條件、提高可操請注意本文件的某些內容可能涉及專利。本文件的發布機構不承擔識別專利的責任。本文件由中華人民共和國工業和信息化部提出。本文件由全國汽車標準化技術委員會(SAC/TC114)歸口。本文件起草單位：泛亞汽車技術中心有限公司、中國汽車技術研究中心有限公司、東軟集團(大連)長城汽車股份有限公司、中汽研(天津)汽車工程研究院有限公司、北京國家新能源汽車技術創新中心有市德賽西威汽車電子股份有限公司、國汽(北京)智能網聯汽車研究院有限公司、上海機動車檢測認證技術研究中心有限公司、思博倫通信科技(北京)有限公司、中國第一汽車集團有限公司、安徽江淮汽車集隨著服務器內存的增加、更新軟件數量的增加以及這些控制單元、連接網絡和總線技術提供的功能數量的增加，其復雜性和速度已達到類似于計算機網絡的水平。GB/T43258《道路車輛基于因特網協議的診斷通信(DoIP)》是為了定義在IP通信鏈路上實施的車輛診斷系統的通用要求。GB/T43258的目的是描述一個標準化的車輛接口，該接口：——將車載網絡技術與客戶端DoIP實體車輛接口要求分離，以實現長期穩定的外部車輛通信——利用現有的標準來定義可用于診斷通信以及制造商特定用例的長期穩定的先進通信標準；——通過使用現有的適配層，很容易地適應新的物理層和數據鏈路層，包括有線和無線連接；——允許車輛內部和車輛外部DoIP實體的連接。GB/T43258擬由4個部分構成。——第1部分：一般信息和使用案例定義。規定了客戶端DoIP實體與服務端DoIP實體之間的車輛診斷的一般信息和使用案例定義，旨在為系列文件提供引言。 第2部分：傳輸協議與網絡層服務。規定了客戶端DoIP實體使用底層協議棧的要求，并且采用安全和非安全的診斷通信要求，旨在說明客戶端DoIP實體與服務端DoIP實體連接與通信過程。——第3部分：基于IEEE802.3有線車輛接口。詳細介紹了基于IEEE802.3100BASE-TX的物理層和數據鏈路層的車載通信接口和測試設備要求，旨在提供標準的物理連接接口。——第4部分：基于以太網的高速數據鏈路連接器。規定了車輛連接器的功能要求，旨在統一外部連接器。圖1說明了基于DoIP的車輛診斷通信框架與OSI模型的關系：——車輛診斷通信框架由GB/T40822組成；——表示層，例如特定于車輛制造商(VM)或ISO22901ODX;——OSI底層框架由GB/T43258.3和GB/T43258VISO/IEC10731車輛診斷通信框架通信使用案例標準使用案例特定標準GB/T40822—2021第10章UDSonIP(基于IP的統一診斷服務)OSI第7層應用層OSI第6層表示層GB/T40822—2021第4章～第6章應用層應用層服務接口表示層標準車輛制造商規定或ISO22901ODXOSI第5層會話層上層服務接口GB/T40822—2021第7章會話層服務會話層服務接口OSI第4層傳輸層OSI第3層網絡層傳輸層服務接口GB/T43258.2DolP第2部分：傳輸協議與網絡層服務數據鏈路層服務接口OSI第2層數據鏈路層OSI第1層物理層數據鏈路層服務接口GB/T43258.3DolP第3部分：基于IEEE802.3有線車輛接口OSI底層框架圖2從功能角度說明了車輛網絡架構示意圖。VI******車輛網絡ECU1ECU2ECUn車輛子網絡DolP邊緣節點網關1ECUIECUⅡECUn車輛子網絡DoIP網關m基于IP的網絡客戶端2網絡節點1DolP節點基于IP的網絡激活線客戶端1(測試設備)***網絡節點n圖2車輛網絡架構示意圖(功能視圖)本文件由一個或多個DoIP實體實施，具體取決于車輛的網絡架構。圖2顯示了連接到DoIP邊緣節點的客戶端1(外部客戶端)和連接車輛內部網絡的客戶端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]。注：本文件中的需求沒有按順序編號，因為在本文件開發過程中各個需求的順序發生了變化。1道路車輛基于因特網協議的診斷通信第2部分：傳輸協議與網絡層服務本文件規定了客戶端DoIP實體與使用因特網協議(IP)、傳輸控制協議(TCP)以及用戶數據報協議(UDP)并安裝在車輛內的服務器之間進行安全的和非安全的診斷通信要求。該要求包括定義車輛網關要求(例如，集成到現有計算機網絡)與測試設備要求(例如，檢測并與車輛建立通信)。本文件規定了在網絡中檢測車輛的功能，并在各種車輛狀態下與車輛網關及其子模塊進行通信的功能。這些功能被劃分為必選與可選兩大類。本文件規定了以下必選功能：——車輛網絡集成(IP地址分配);——車輛通告與車輛發現；——車輛基本狀態信息獲取(如診斷電源模式);——連接建立(例如，并行通信嘗試),連接維持與車輛網關控制；——車輛子模塊的數據進出路由；本文件規定了以下可選功能：——DoIP實體狀態監控；——傳輸層安全協議(TLS);——DolP實體防火墻性能。2規范性引用文件下列文件中的內容通過文中的規范性引用而構成本文件必不可少的條款。其中，注日期的引用文件，僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本(包括所有的修改單)適用于GB/T9387.1—1998信息技術開放系統互連基本參考模型第1部分：基本模型(idtGB16735道路車輛車輛識別代號(VIN)ISO13400-3道路車輛基于因特網協議的診斷通信(DoIP)第3部分：基于IEEE802.3有線車輛接口[Roadvehicles—DiagnosticcommunicationoverInternetProtocol(DoIP)—Part3:Wiredve-注：GB/T43258.3—2023道路車輛基于因特網協議的診斷通信(DoIP)第3部分：基于IEEE802.3有線車輛ISO/IEC/IEEE8802-3系統間的電信和信息交換局域網和城市區域網第3部分：以太網標準(Telecommunicationsandexchangebetweeninformationtechnologysystems—Requirementsforlo-IETFRFC768用戶數據報協議(UserDatagramProtocol)2IETFRFC791因特網協議DARPA因特網互聯程序協議規范(InternetProtocol—DARPAInternetProgram—ProtocolSpecification)IETFRFC792網絡控制報文協議DARPA因特網互聯程序協議規范(InternetControlMessageProtocol—DARPAInternetProgram—ProtocolSpecification)IETFRFC793傳輸控制協議DARPA因特網互聯程序協議規范(TransmissionControlProtocol—DARPAInternetProgram—ProtocolSpecification)IETFRFC826以太網地址解析協議(AnEthernetAddressResolutionProtocol)IETFRFC1122因特網主機需求通信層(RequirementsforInternetHosts—CommunicationLayers)IETFRFC2131IETFRFC2132tensions)IETFRFC2375IETFRFC2460tion]IETFRFC3315IPv6(DHCPv6)]IETFRFC3484動態主機配置協議(DynamicHostConfigurationProtocol)DHCP可選項和BOOTP供應商擴展(DHCPOptionsandBOOTPVendorEx-IPv6組播地址分配(IPv6MulticastAddressAssignments)互聯網協議第六版(IPv6)規范[InternetProtocol,Version6(IPv6)—Specifica-IPv6動態主機配置協議(DHCPv6)[DynamicHostConfigurationProtocolfor互聯網協議第六版(IPv6)默認地址選擇[DefaultAddressSelectionforInternetProtocolversion6(IPv6)]IETFRFC3927IPv4本地鏈路地址動態配置(DynamicConfigurationofIPv4Link-LocalAd-dresses)IETFRFC4291IPv6尋址架構IP(Version6AddressingArchitecture)IETFRFC4443因特網協議第六版(IPv6)網絡控制報文協議(ICMPv6)規范[InternetControlMessageProtocol(ICMPv6)fortheInternetProtocolVersion6(IPv6)Specification]IETFRFC4492用于傳輸層安全性(TLS)的橢圓曲線加密(ECC)密碼套件[EllipticCurveCryp-tography(ECC)CipherSuitesforTransportLayerSecurity(TLS)]IETFRFC4702動態主機配置協議完全限定域名[TheDynamicHostConfigurationProtocol(DHCP)ClientFullyQualifiedDomainName(FQDN)Option]IETFRFC4861IPv6鄰居發現協議[NeighborDiscoveryforIPversion6(IPv6)]IETFRFC4862IPv6無狀態地址自動配置(IPv6StatelessAddressAutoconfiguration)IETFRFC5246傳輸層安全協議1.2[TheTransportLayerSecurity(TLS)ProtocolVersion1.2]GB/T9387.1—1998界定的以及下列術語和定義適用于本文件。診斷電源模式diagnosticpowermode抽象的車輛內部電源供應狀態，該狀態影響車內網絡上所有ECU的診斷功能，并識別允許診斷通信的所有網關子網絡上所有ECU的狀態。注：目的是為客戶端DoIP實體提供信息，包括是否能在連接的車輛上執行診斷，或車輛是否需要進入不同的診斷電源模式(即需要技術人員交互)。本文件定義了如下狀態：未準備好(部分基于DoIP的服務端可通信或全部基于DoIP的服務端均不可通信)、已準備好(所有基于DoIP的服務端均可通信),以及不支持(不支持診斷電源3模式信息的診斷請求報文)。DoIP邊緣節點DoIPedgenode車內主機(3.4),在此處符合ISO13400-3的以太網激活線所在終端，以及外部網絡中的第一個節點或主機的鏈路所在終端。DoIP實體證書DolPentitycertificate由中間證書頒發機構(3.5)發放至DoIP實體的證書，用以TLS握手過程中提供給客戶端DoIP實體驗證其真實性。連接到基于IP網絡的節點。中間證書頒發機構intermediatecertificateauthority;intermediateCA頒發后續證書至其他中間證書頒發機構或DoIP實體。中間證書intermediatecertificate存儲在客戶端DoIP實體本地或在身份驗證過程中與端節點證書一同提供以完成信任鏈。無效的源地址invalidsourceaddress為客戶端DoIP實體預留的地址范圍外的源地址。邏輯地址logicaladdress識別診斷應用層實體的地址。連接到基于IP的網絡(例如，以太網),并使用IP通信，但不支持基于DoIP協議的節點。注：某些網絡節點可能也與車輛子網絡(3.14)連接，但由于不支持DoIP協議，所以這些網絡節點不是DoIP網關。因此，這些網絡節點不會與遵循DoIP的客戶端有交互(如響應外部請求)。根證書頒發機構rootcertificateauthority頒發根證書的機構。根證書rootcertificate由根證書頒發機構(3.10)創建并用作信任錨的證書。注：所有想要驗證終端節點證書的實體(例如，來自DoIP實體)安全地存儲和使用根證書，以及信任鏈中的所有必在IETFRFC147中定義的唯一標識，該標識用于在網絡上發送或接收信息。4未知源地址unknownsourceaddress未在連接表內列出的地址。車輛子網絡vehiclesub-net非直接與基于IP的網絡相連接的車輛網絡。注：來自及傳向車內子網絡的數據，僅能經由所連接的DoIP網關進行傳輸。4符號和縮略語下列符號適用于本文件。<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>:獨立的車輛外部網絡節點數量下列縮略語適用于本文件。AL:應用層(ApplicationLayer)APP:應用(Application)ARP:地址解析協議(AddressResolutionProtocol)ASCII:美國信息交換標準代碼(AmericanStandardCodeforInformationInterchange)AutoIP:自動配置網絡協議地址(AutoconfiguredIPaddress)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)5GUI:圖形用戶界面(GraphicalUserInterface)GW:網關(Gateway)IANA:因特網編號管理局(InternetAssignedNumbersAuthority)IETFRFC:互聯網工程任務組請求注釋(InternetEngineeringTaskForceRequestforComments)IP:因特網協議(InternetProtocol)IPv4:因特網協議第4版(InternetProtocolversion4)(見IETFRFC791)IPv6:因特網協議第6版(InternetProtocolversion6)(見IETFRFC2460)MAC:介質訪問控制(MediaAccessControl)MSC:消息序列圖(MessageSequenceChart)MTU:最大傳輸單元(MaximumTransportUnit)NDP:鄰居發現協議(NeighbourDiscoveryProtocol)NL:網絡層(NetworkLayer)OSI:開放系統互連(OpenSystemsInterconnection)PKI:公鑰基礎設施(PublicKeyInfrastructure)PDU:協議數據單元(ProtocolDataUnit)SA:源地址(SourceAddress)SDU:服務數據單元(ServiceDataUnit)SF:單幀(SingleFrame)SPN:可疑參數編號(SuspectParameterNumber)SPP:服務原語參數(ServicePrimitiveParameter)TA:目標地址(TargetAddress)TCP:傳輸控制協議(TransmissionControlProtocol)TLS:傳輸層安全協議(TransportLayerSecurity)UDP:用戶數據報協議(UserDatagramProtocol)VIN:車輛識別代號(VehicleIdentificationNumber)(見GB16735)VM:車輛制造商(VehicleManufacturer)XOR:異或(ExclusiveOr)5一致性本文件遵循適用于診斷服務的OSI服務公約(ISO/IEC10731)中的約定。6.2～6.5給出了一個簡明的DoIP會話標準工作流示例。為盡可能對DoIP的使用者有幫助，6.2~6.5不會提及在DoIP會話期間可能發生的異常和錯誤。6.2～6.5解釋了兩種可能的網絡環境：網絡連接和直接連接。6.2～6.5中的圖示提供了一種針對適合的DoIP會話所包含的DoIP組件、機制和序列的更好的理解方式。由于在直接連接和網絡連接兩種場景中僅連接和車輛發現(見7.4)存在差異，因此在圖11中對這6兩種場景DoIP會話的相同部分作了描述。6.2連接建立和車輛發現在無網絡基礎設施的直接連接場景中，為直接將車輛與客戶端DoIP實體連接起來，客戶端DoIP假設無DHCP服務器的場景，即使已經發起DHCP流程，DHCP流程也不會成功。相反，本地有效的IP地址將由自動配置機制決定，并被配置給兩個相關的接口。一旦獲取到的IP地址配置給DoIP實體的接口，DoIP實體將通過車輛通告報文(見7.4)廣播其車輛識別代號(VIN)、實體識別碼(EID)、組識別碼(GID)和邏輯地址。該報文會被廣播(UDP)三次，并且該報文的目的端口為UDP_DISCOVERY。依據客戶端DoIP實體是否能夠及時地配置TCP/IP通信，來接收初始的車輛通告報文，客戶端DoIP實體可以使用車輛識別請求報文來輪詢車輛。由于一些操作系統只在DHCP失敗后才啟動AutoIP機制，所以AutoIP機制可能在客戶端DoIP實體上有延遲。由于服務端DoIP實體同時啟動這兩種機制，可能其IP配置會快速完成，且客戶端DoIP實體將不會接收到初始的車輛通告報文。圖3描述了在直接連接場景中的連接和車輛發現。服務端DolP實體物理連接AutolP/DHCP請求AutolP/DHCP請求AutolP接口配置AutolP接口配置可選的車輛發現[客戶端已經可達]車輛通告報文(3x)[客戶端未接收到初始的車輛通告報文]車輛識別請求車輛識別響應圖3在直接連接場景中的連接和車輛發現在網絡連接場景中，連接和車輛發現過程略有不同。與網絡的物理連接無需立即同步。因此，用于7TCP/IP連接接口配置和訪問的時間點可能會有顯著差異。在特定的網絡場景中，可以有多個車輛發送車輛通告報文。如果車輛的DoIP實體未發送車輛通告報文，客戶端DoIP實體可以通過發送車輛識別請求報文進行輪詢車輛通告報文。圖4描述了在網絡連接場景中的連接和車輛發現。客戶端DolP實體網絡服務器DolP實體物理連接AutolP/DHCP請求物理連接AutolP/DHCP請求DHCP響應DHCP響應車輛通告(3x)車輛通告(3x)車輛識別請求車輛識別響應[客戶端已可達][客戶端未接收到初始車輛通告]車輛識別請求車輛識別響應圖4在網絡連接場景中的連接和車輛發現(車輛通告報文)使用車內測試設備的場景，例如OTA在線升級或者遠程診斷。車內測試設備可以取消DHCP或者AutoIP動態分配IP地址，通過使用靜態IP地址分配，從而實現最小化的接口啟動時間。在這種場景下車內IP接口仍然使用車輛通告。步驟“添加車輛到列表”(見圖5)未包含在本文件中，因此，該步驟非強制，甚至非必需。但在前一步驟中廣播的車輛通告報文可能會以某種方式被處理。例如，車輛會以某種方式告知“就緒”,或基于當前車輛DoIP會話可用這個信息來啟動自動化流程。雖然在網絡連接場景中，客戶端和DoIP實體間仍有網絡設備，但在兩個通信端點間在邏輯上是直為了初始化客戶端DoIP實體和車內DoIP實體間的連接，第一步應打開一個套接字(目的端口為TCP_DATA)。該步驟應在任何報文交互前完成。因此，DoIP實體應提供資源來處理到達的通信請求實體應提供足夠的資源來處理指定數量的套接字，即能處理并行的DoIP會話數量(<n>)加一個額外的套接字(見DoIP-002)。若超過(n+1)個連接嘗試同時到達，可能無更多8資源可用，且第<n+2)個連接嘗試將被拒絕(是因為沒有任何套接字處于監聽狀態，而不是由于DoIP協議處理的原因)。一旦套接字被建立，一些初始化步驟會被執行。分配和啟動初始非激活定時器(見12.6.3)和通用未激活定時器(見12.6.2)。此外，求報文外的其他數據被路由或者處理。所有后續報文通過該TCP_DATA套接字來交互。在基于安全的TLS通信和相應的TCP_DATATLS套接字(見6.2.5)場景中，DoIP實體應用也會應用此連接處理為在初始連接上激活路由，客戶端向DoIP實體發送路由激活請求報文(見12.5)。若客戶端DoIP實體是滿足要求的，且車內DoIP實體已注冊的連接少于<n>,則會終止相應的初始定時器，并且假設不需要額外的認證或確認或者安全的TLS連接，則套接字狀態變為“已注冊[路由激活或處理有效的DoIP報文(例如，DoIP診斷報文),這將通過肯定路由激活響應報文通知客戶端DoIP實體。通用未激活定時器將重啟并保持激活狀態。DoIP實體在接收任何類型的數據時，首先調用DoIP報頭處理程序。若有效載荷包含診斷報文(通過通用DoIP報頭中的有效載荷類型8001i標識，見9.5),則調用診斷報文處理程序來處理該有效當診斷報文到達時，在報文成功通過診斷報文處理程序后，應立即向調用的客戶端DoIP實體發送DoIP確認(確認應答),實際上報文已經通過了相應的內部路由機制，但還沒有被DoIP網關處理或者轉發到最終的非DoIP服務端。對于符合GB/T40822的診斷報文載荷，目標服務端DoIP實體將發送診斷響應返回給客戶端DoIP實體。該行為由DoIP報文封裝的相應診斷協議來描述，因此不在本文件的范圍內。當客戶端DoIP實體不再需要連接，應總是通過TCP/IP協議機制關閉連接。DoIP實體對該連接啟動終止程序。該終止程序將釋放相應的資源，以便該套接字可用于新的連接。若連接未關閉，則資源應在通用未激活定時器超時或在線檢查執行后釋放。圖5描述了非安全DoIP會話的示例。9天操作者客戶端DolP實體服務端DolP實體選擇車輛增加車輛到列表創建套接字連接TCPDATA套接字診斷報文DolP診斷響應診斷響應響應常規DoIPDolP診斷報文處理程序診斷響應退出退出關閉套接字終止DoIP會話對于安全的TCP連接，使用TLS專用的TCP_DATA端口。對于安全DoIP會話場景，為了初始化客戶端DoIP實體和車內DoIP實體間的安全的TLS連接，第一步應打開一個TLS套接字(目的端口為TLSTCP_DATA)。該步驟應在任何報文交互前完成。因此，DoIP實體應提供資源來處理到達的通信請求(例如，套接字資源)。DoIP實體提供足夠的資源來處理指定數量的套接字，即能處理并行的TLS安全的DoIP會話數量((k>)加1個額外套接字(見DoIP-159)。若超過(k+1>個連接嘗試同時到*V*V達，可能無更多資源可用，且第<k+2)個連接嘗試將被拒絕(是因為沒有任何套接字處于監聽狀態，而不是由于DoIP協議處理的原因)。一旦套接字被建立，客戶端DoIP實體和DoIP實體都將會按照TLS協議規定的握手初始化步驟執行。在TLS成功完成握手之后，所有后續報文將通過該TLSTCP_DATA套接字進行交互(例如，路圖6描述了使用TLS保護的DoIP會話示例。操作者客戶端DolP實體服務端DolP實體選擇車輛增加車輛到列表創建套接字連接TLSTCP_DATA套接字初始化連接TLS握手(ClientHello)TLS握手成功(完成)指示成功連接路由激活請求路由激活響應常規DoIP報頭處理程序路由激活處理程序請求診斷報文DolP診斷響應(確認應答)診斷響應響應常規DoIP報頭處理程序處理程序診斷請求診斷響應退出關閉套接字終止DoIP會話圖6使用TLS保護的DoIP會話示例當客戶端DoIP實體不再需要安全的TCP連接，應始終通過TLS和TCP/IP協議機制關閉連接(見示例TLS1.2RFC5246:2008,7.2.1,TLS1.3RFC8446:2018,6.1)。DoIP實體應該清除當前會話車輛識別規定了如何發現車輛及其DoIP實體，并與其網絡上的IP地址關聯起來。車輛通常是由其VIN來識別。在制造或售后環境中，在同一車輛上可能安裝多個DoIP實體，但此時尚未配置車輛特定的VIN。為了將新安裝和未配置的DoIP實體與車輛相關聯，可用GID來代替VIN。本條給出了一個序列示例，通過該序列，外部客戶端DoIP實體可以將同一網絡內全部連接車輛的服務端DoIP實體進行識別和分組。圖7顯示了由客戶端DoIP實體執行的簡化標識序列的示例。當車輛已連接到DoIP網絡且完成IP地址分配時(見圖5),DoIP實體在等待A_DoIP_Announce_Wait時間后發送車輛通告報文。若客戶端DoIP實體稍晚連接到DoIP網絡，應通過廣播車輛識別請求來觸發車輛通告/車輛識別所有車輛的服務端DoIP實體在A_DoIP_Ctrl時間內響應車輛識別請求。若客戶端DoIP實體接收車輛通告/車輛識別響應并包含VIN/GID同步狀態為未完成的報文(10?g),這說明車輛上存在著VIN/GID未同步的DoIP實體，客戶端DoIP實體將啟動該車輛的車輛發現定時器(由VIN/GID主節點在其車輛通告/車輛識別響應中給定的VIN/GID來標識)。該機制允許VIN/GID主節點在某些實體需要更多時間同步VIN/GID時通知客戶端DoIP實體。當車輛發現定時器超時，將向所有這些DoIP實體發送另一個車輛識別請求，這些DoIP實體在最初的車輛通告/車輛識別響應中報告VIN/GID無效。客戶端DoIP實體識別序列客戶端已連接/IP地址分配完成/車輛通告已收到可選(客戶端丟失車輛公告)-發送車輛識別請求在A_DolP_Ctrl時間內存儲所有到達的車輛公告/車輛識別響應的信息?是車輛通告/車輛識別響應的VIN/GID同步狀態=未完成是啟動A_Vehicle_Discovery_Timer客戶端網絡和車輛設置信息(在識別序列期間動態創建)VIN=…EID00000000003316否車輛No.2GID=00000000000216VIN=…EID00000000000216否車輛No.3GID=00000000000316VIN=..EID00000000006716當車輛發現定時器超時，發送另一車輛識別請求在A_DolP_Ctrl時間內存儲所有到達的車輛公告/車輛識別響應的信息?否是識別序列完成圖7簡化的客戶端識別序列示例6.4應用報文序列圖的通信示例多個報文序列圖(MSC)顯示了客戶端DoIP實體與車輛服務端DoIP實體通信的最常見的通信場景。6.5基于IP的車輛通信協議——概述7.4～7.6、9.2～9.6及12.5中的表格按照以下列標題描述了每條報文。——條目：報文元素的短名。在本文件中引用報文元素時使用此名稱。——位置：描述每個單獨報文元素在DoIP報文中的位置(字節號)。該字節位置總是以0開始，并 ——描述：該列包含對每個獨立報文元素及其用途的更詳細描述。——值：該列列舉了相應報文元素所支持值的范圍和每個值的含義。——支持：該列包含DoIP實體是否支持特定報文或報文元素的信息。盡管報文自身被定義為可——端口和協議：該列規定了支持的特定有效載荷類型的基礎協議和使用的端口。7應用(APP)需求需求8.DolP-108APP-本文件的實施車輛網絡的每個DoIP實體都應執行本文件規定的協議需求。需求8.DoIP-147APP-大端網絡字節順序根據IETFRFC791:1981的附錄B,DoIP報文應使用IP大端網絡字節順序。組標識(GID)是用于識別車輛內多個DoIP實體的一種分散處理方法。這說明在同步過程中，所有其他DoIP實體都將從VIN/GID主節點(例如DoIP邊緣節點)接收VIN/GID。由于該同步過程通常需要一定時間(例如，添加新的DoIP實體到車輛后),因此DoIP實體應使用定義的未設置值(見表1),直到VIN/GID同步完成。DoIP實體間的VIN/GID同步詳細規范超出了本文件的范圍，由車輛制造商自定義。需求8.DoIP-143APP-DoIP實體的車輛GID同步若在車輛中存在多個DoIP實體，并且若不能始終確保為每個DoIP實體配置有效VIN,則每個DoIP實體應支持車輛GID的同步。注：一種確保GID全局唯一的可能方法是使用GID主節點MAC地址。圖8描述了同一車輛內兩個獨立DoIP實體的VIN/GID同步和識別。車輛識別請求)服務端DoIP實體主車輛識別請求)服務端/ECU(X)DolP實體車輛識別響應(GID)車輛識別響應(GID)圖8使用VIN/GID同步的車輛識別示例表1定義了車輛識別參數的未設置值。表1車輛識別參數值(未設置值)長度值00?s或FF?6邏輯地址20000?6或FFFF16實體識別碼(EID)60016或FF?6組識別碼(GID)6圖9顯示了將客戶端DoIP實體連接到車輛的順序和IP地址分配過程。服務端-GID已知/有效服務端DoIP實體連接O這將使能激活線和提供物理數據鏈路連接此處未指定信息的傳遞方式!已連接!()ARP探針,169.254.x.y)ARP(169.254.x.y)所有節點都可能同時發生。方便起見，僅顯示一個DHCP發現ODHCP提供QDHCP請求()DHCP應答0圖10詳細描述了識別多個DoIP實體的完整分散處理方法。外部網絡服務端DolP邊緣節點實體—GID已知/有效服務端DolP實體車輛通告(VIN/GID)車輛通告(VIN/GID)可選車輛通告[VIN/GID同步狀態未完成(10?)]首條包含未完成同步狀態的車輛公告啟動車輛發現定時器!YGip同步()AVehicleDiscovery_Timer(5s)車輛識別請求()車輛識別請求車輛識別請求()車輛識別請求()車輛識別請求()車輛識別響應(VIN/GID)車輛識別響應(VIN/GID)此時診斷儀已知車輛內所有DolP實體循環任一實體路由激活請求()注：圖10的場景不包括車輛識別的定時器啟動后，車輛連接到DoIP網絡的情況。圖10帶有VIN/GID同步的詳細車輛識別7.4APP車輛識別和通告請求報文車輛識別請求和車輛通告報文規定了在網絡中識別車輛或其DoIP實體的需求。客戶端DoIP實體為與DoIP實體進行通信，需要知道DoIP實體的IP地址和安裝該實體的車輛。若客戶端DoIP實體已知IP地址，車輛識別請求報文用于從車輛中檢索VIN/GID和DoIP實體邏輯地址(見6.3.1)。因——VIN——VIN未配置的車輛(例如，在裝配階段或刷寫后);已配置并且客戶端DoIP實體未知VIN/EID/GID已配置并且客戶端DoIP實體已知VIN/EID/GID——在同一車輛上安裝了多個DolP實體；——DoIP實體的IP地址已知。在IP地址未知并且VIN碼未被配置的情況下，無法基于VIN碼將DoIP實體關聯到單個車輛上。6.3.1中描述了解決該關聯問題的備選方法。圖11描述了DoIP實體(網關/節點DoIP實體與客戶端DoIP實體)間的通用車輛通告和識別序列，用于聲明它們的存在或使用規定的請求和響應進行識別。可替代1:網絡連接時的車輛通告物理連接監測()物理連接監測()T{A_DolP_Announce_Wait}車輛通告報文(){A_DolP_Announce_Interval}車輛通告報文()車輛通告報文()可替代2:來自客戶端的車輛識別車輛識別請求()車輛識別響應(){A_DolP_Announce_Interval;{A_DolP_Announce_Wait}客戶端DolP實體IP地址配置()IP地址配置O圖12顯示了一個TCP_DATA套接字處理程序遵循的序列。在使用新的路由激活請求第三個連接時，該處理程序正在同時處理兩個套接字。客戶端3DoIP實體客戶端2DoIP實體客戶端IDolP實體套接字處理程序套接字3(連接客戶端1)套接字2(未連接)套接字1(連接客戶端2)路由激活請求()調用套接字處理程序(校驗套接字)執行在線狀態檢查()執行在線狀態檢查()在線狀態檢查請求()在線狀態檢查請求()在線狀態檢查響應()無在線狀態檢查響應()調用套接字處理程序(無響應接收)關閉套接字()分配源地址(客戶端3)路由激活響應()圖12包含兩個并行套接字和第三次連接嘗試處理程序需求8.DoIP-046APP-DoIP實體車輛識別請求報文每個DoIP實體應支持表2規定的車輛識別請求報文。表2有效載荷類型——無報文參數的車輛識別請求報文位置長度描述值支持條件無報文參數需求8.DoIP-047APP-DoIP實體包含EID的車輛識別請求報文若支持，每個DoIP實體應支持表3規定的包含附加EID參數的車輛識別請求報文。表3有效載荷類型——包含EID的車輛識別請求報文位置長度描述值支持條件EID06EID是DoIP實體應對車輛識別請求報文響應的唯一ID(例如：網絡接口的MAC地址)若使用MAC地址，則應符合IEEEEUI-48強制需求8.DoIP-048APP-DoIP實體包含VIN的車輛識別請求報文每個DoIP實體應支持表4規定的包含附加VIN參數的車輛識別請求報文。表4有效載荷類型——包含VIN的車輛識別請求報文位置長度描述值支持條件VIN0VIN是按照GB16735規定的車輛識別代號。該參數僅在客戶端DoIP實體識別單個車輛上的DoIP實體且客戶端DoIP實體已知車輛的VIN時存在ASCII強制需求8.DoIP-049APP-DoIP實體車輛通告/車輛識別響應報文每個DoIP實體應支持表5規定的車輛通告/車輛識別響應報文。表5有效載荷類型——車輛通告/車輛識別響應報文位置長度描述值支持條件VIN0VIN符合GB16735規定。若VIN在該報文傳輸時未被配置，應使用表1規定的未設置值代替。在這種情況下，GID被用于關聯DoIP節點和特定車輛(見6.3.1)ASCII見表1強制邏輯地址2該參數是正在響應的DoIP實體的邏輯地址(更多細節見7.8)。邏輯地址可被用于直接尋址到DoIP實體的診斷請求見表13強制EID6該參數是DoIP實體的唯一的標識，用在VIN被配置前或被DoIP設備識別前(例如：在車輛裝配過程中)。推薦使用DoIP實體網絡接口的MAC地址信息(若支持多個接口，使用其中的一個)若使用則應符合強制GID6該參數是在沒有為該車輛配置VIN的情況下，同一車輛內的一組DoIP實體的唯一標識。6.3.1定義了一個車輛上DoIP節點間的VIN/GID同步過程。若GID在傳輸該報文時不可用，應使用表1規定的未設置值來代替見表1強制需要的進一步操作1該參數是通知客戶端DoIP實體存在沒有初始化連接或使用集中安全方法的附加信息見表6強制VIN/GID同步狀態1該參數是通知客戶端DoIP實體所有DoIP實體已同步VIN或GID的附加信息見表7可選注1:“需要的進一步操作”的信息可用于表示特定的車載同步程序尚未完成和/或需要額外步驟(例如：安全措施),以允許所有DoIP節點通告其存在網絡上。需求8.DoIP-050APP-DoIP實體車輛通告報文在配置有效的IP地址后，每個DoIP實體應立即以A_DoIP_Announce_Interval時間的間隔發送A_DolP_Announce_Num次符合表5規定的車輛通告報文。注2:因為使用UDP無法保證報文在網絡上正確傳遞，所以應該多次發送該報文進行補償。多次傳輸提高了至少有一條報文被客戶端DoIP實體正確接收到的概率。表6定義了進一步操作碼值。表6進一步操作碼值定義值描述支持無需進一步操作強制011?~0F?為本文件預留強制要求路由激活來初始化集中安全可選用于車輛制造商額外的用途可選需求8.DolP-144APP-DoIP實體車輛通告/車輛識別響應報文的操作碼為10?6當從DoIP實體接收到進一步操作碼為10?(見表6)的車輛通告/車輛識別響應報文時，客戶端DoIP實體應發送激活類型設置為E0?(見表46)的路由激活請求報文(見表47)給DoIP實體，并根據路由激活響應報文(見表48)的車輛制造商規定的字段中決定特定操作。表7定義了VIN/GID同步狀態碼值。表7VIN/GID同步狀態碼值的定義值描述支持001?VIN和/或GID被同步強制0116～0F?6為本文件預留強制未完成的：VIN和GID未被同步強制11]s～FF?s為本文件預留強制需求8.DoIP-125APP-DoIP實體車輛通告發送目標IPv4地址的UDP報文在車輛通告的情況下(非車輛識別響應),應總是發送目標IPv4地址設置為限制的廣播地址的UDP報文。需求8.DoIP-155APP-DoIP實體車輛通告發送目標IPv6地址的UDP報文在車輛通告的情況下(非車輛識別響應),應總是發送目標IPv6地址設置為IETFRFC2375中描述的本地鏈路范圍的組播地址(FF0216::1)的UDP報文。需求8.DoIP-123APP-通過VIN,EID或兩者識別的DoIP實體每個DoIP實體在任何時候應被VIN,EID或兩者同時唯一識別。需求8.DoIP-142APP-DoIP實體至少支持EID和GID若不能確保在任何時刻都能夠通過VIN識別車輛，應支持EID和GID。圖13顯示了依賴于車輛識別請求的有效載荷類型的車輛識別響應報文的產生。初始-車輛識別請求處理程序初始-車輛識別請求處理程序[包含EID的車輛識別請求]開啟有效負載類型DolP-051[車輛識別請求][匹配]發送車輛識別響應報文[不匹配]DolP-053比較服務端DolP實體的EID與請求EID比較車輛的VIN與請求的VIN[不匹配][匹配]最終車輛識別請求處理程序需求8.DoIP-051APP-DoIP實體A_DoIP_Announce_Wait時間每個DoIP實體應在接收到表2規定的車輛識別請求報文后，延遲(表12規定的A_DoIP_Announce_Wait)發送一條符合表5規定的車輛識別響應報文。注：若多個DoIP實體被連接到同一個網絡上，為了避免UDP數據包在網絡上突發，在響應車輛識別請求前增加一個額外的延遲時間。在這種情況下，車輛識別響應的隨機延遲允許由于高網絡利用率被丟棄的UDP數據包，在下一個車輛識別請求廣播中傳遞給客戶端DoIP實體。需求8.DoIP-052APP-DoIP實體接收到包含VIN的車輛識別請求報文后的車輛識別響應在接收到包含VIN的車輛識別請求報文(見表4)后，若來自請求報文的VIN與配置到DoIP實體中的VIN匹配，每個DoIP實體應發送符合表5規定的車輛識別響應報文。需求8.DoIP-053APP-DoIP實體接收到包含EID的車輛識別請求報文后的車輛識別響應在接收到包含EID的車輛識別請求報文(見表3)后，若來自請求報文的EID與DoIP實體的EID匹配(例如：若DoIP實體支持多個網絡接口，EID使用其中的一個MAC地址),每個DoIP實體應發送符合表5規定的車輛識別響應報文。7.5APP診斷電源模式信息請求和響應該有效載荷類型用于檢索車輛的診斷電源模式。客戶端DoIP實體可使用該信息，例如，驗證車輛是否處于診斷電源模式中，診斷電源模式允許在車輛組件中執行可靠的診斷。需求8.DoIP-116APP-DoIP實體診斷電源模式信息請求每個DoIP實體應支持表8規定的診斷電源模式信息請求。表8診斷電源模式信息請求位置長度描述值支持無額外的報文元素需求8.DoIP-117APP-DoIP實體診斷電源模式信息響應每個DoIP實體應支持表9規定的診斷電源模式信息響應。需求8.DoIP-118APP-DoIP實體診斷電源模式信息響應在A_DoIP_Ctrl時間內DoIP實體在接收到診斷電源模式信息請求后，應在A_DoIP_Ctrl時間(見表12)內回復診斷電源信息響應。表9診斷電源模式信息響應位置長度描述值支持診斷電源模式01標識車輛是否處于診斷電源模式中并且準備執行可靠的診斷0016:未準備好0116:已準備好0216:不支持0316～FFi:為本文件預留強制7.6APPDoIP實體狀態信息請求和響應該有效載荷類型用于識別相應DoIP實體的特定操作條件。例如，允許客戶端DoIP實體檢測存在的診斷通信會話及DoIP實體性能。需求8.DoIP-119APP-DoIP實體狀態請求若支持，DoIP實體應支持表10規定的DoIP實體狀態請求。表10DoIP實體狀態請求位置長度描述值支持無額外的報文元素需求8.DoIP-120APP-DoIP實體狀態響應若支持，DoIP實體應支持表11規定的DoIP實體狀態響應。需求8.DoIP-121APP-DoIP實體在A_DoIP_Ctrl時間內狀態響應若支持，在接收到DoIP實體狀態請求后，DoIP實體應在A_DoIP_Ctrl時間(見表12)內回復DoIP實體狀態響應。位置長度描述值支持條件節點類型(NT)01標識有關的DoIP實例是DoIP節點還是DoIP網關00?s:DoIP網關0116:DoIP節點021～FF:為本文件預留強制同時存在的TCP_DATA套接字最大數量11表示該DoIP實體允許的同時存在的TCP_DATA套接字的最大數量，不包含為套接字處理預留的套接字強制當前打開的TCP_DATA套接字數量21當前建立的套接字數量0～255強制最大數據長度34DoIP實體能處理的單個DoIP-098邏輯請求的最大長度可選7.7APP定時和通信參數表12規定了DoIP特定的通信參數，包括超時值和有效載荷類型特定的性能需求。此外，診斷協議會話層定時被映射到DoIP報文中。定時參數描述參數值A_DoIP_Ctrl該超時時間規定了客戶端DoIP實體等待對之前發送的UDP報文的響應的最大時間。它包括等待并收集對廣播報文(僅UDP)的多個響應的最大時間超時：2sA_DoIP_Announce_Wait該定時參數規定了DoIP實體響應車輛識別請求的等待時間和DoIP實體在有效IP地址配置后發送車輛通告報文的等待時間。該定時參數的值應在最小值和最大值間隨機確定隨機時間：0～500msA_DoIP_Announce_Interval該定時參數規定了配置有效的IP地址后，DoIP實體發送的車輛通告報文間的間隔時間延遲時間：500msA_DoIP_Announce_Num該參數規定了配置有效的IP地址后，DoIP實體發送車輛通告報文的次數重復次數：3次A_DoIP_Diagnostic_Message該定時參數規定了接收到的DoIP診斷報文的最后一字節和發送確認的ACK或NACK的間隔時間。在超時后，請求或響應應被視為丟失，且請求可被重復ECU性能響應時間：超時：2sT_TCP_General_Inactivity該超時時間規定了TCP_DATA套接字在被DoIP實體關閉前處于非激活狀態(無數據接收或發送)的最大時間超時：5min表12DoIP定時和通信參數(續)定時參數描述參數值T_TCP_Initial_Inactivity該超時時間規定了TCP_DATA套接字在建立后，處于非激活狀態的最大時間。在無路由激活的規定時間后，DoIP實體關閉該TCP_DATA套接字超時：2sA_TCP_Alive_Check該超時時間規定了DoIP實體在TCP_DATA套接字上寫入在線檢查請求后，等待在線檢查響應的最大時間。因此，若底層TCP協議棧不能傳遞在線檢查請求報文，該定時器將超時超時：500msA_Processing_Time該超時時間定義了客戶端DolP實體發送的不要求響應但需要一定時間處理的DoIP報文的間隔時間。因此，客戶端DoIP實體在向同一DoIP實體發送另一個請求前，應至少等待A_Processing_Time時間超時：2sA_Vehicle_Discovery_Timer該參數是車輛離線端的定時器。該定時器規定了車輛在所有DoIP實體間執行VIN/GID同步需要的時間。車輛發現定時器僅在客戶端DoIP實體接收到包含VIN/GID同步狀態碼為“未完成(10?g)”及有效VIN或GID的車輛通告/車輛識別響應報文時啟動超時：5s邏輯地址應用于診斷報文。一個物理邏輯地址唯一地表示任一DoIP實體內的診斷應用實體，或通過DoIP網關連接的任一車載網絡服務端內的診斷應用層實體。車輛發現過程(見6.2)允許客戶端DoIP實體將物理邏輯地址映射到IP地址上。功能邏輯地址被用于尋址車內一組或所有的診斷應用層實體。由于DoIP不支持組播，對于具有多個DoIP實體的車輛中的功能尋址，為了能夠到達功能邏輯地址尋址的所有服務端，客戶端DoIP實體應向每個DoIP實體發送單播(點對點)IP數據包，這是功能地址的一部分。不存在通過單一IP地址尋址多個DoIP實體的機制。對DoIP網關，若接收到功能尋址的診斷報文，則應在它所連接的車內子網上發送組播或廣播報文。表13定義了邏輯地址的尋址機制。表13中尋址機制未標準化單個服務端的單獨地址。因此，若客戶端DoIP實體要確定響應服務端表13邏輯地址概述地址描述0000??為ISO/SAE預留000116～0DFF6車輛制造商規定0E00s～0FFF16為客戶端地址預留0E00??~0E7F??外部診斷測試設備(例如，用于排放的外部測試設備)0E80?~0EFF1外部車輛制造商/售后增強型診斷測試設備”0F00??~0F7F16內部數據收集/在線診斷設備(僅車輛制造商使用)0F80?6～0FFF16外部持續的數據收集設備(車輛數據記錄儀，例如保險公司使用或收集車隊數據)表13邏輯地址概述(續)地址描述1000?6～7FFF16車輛制造商規定800016～CFFF1為ISO/SAE預留D000??~DFFF1為SAE卡車和客車控制和通信委員會保留E000?~E3FF1?特定標準(例如：ISO27145-1、ISO20730-1)中的用例規定的邏輯地址定義E400?6～EFFF16車輛制造商定義的功能組邏輯地址F000～FFFFi為ISO/SAE預留當在路由激活請求中使用這些地址時，可能會中斷其他車輛上正在進行的診斷通信，可能損害其他正常的功能(例如返回到失效保護行為)。當在路由激活請求中使用這些地址時，首先路由激活的診斷報文會因為其他正在進行的診斷通信而延遲，然后可能被中斷，損害其他正常的功能(例如返回到失效保護行為)。這些地址不應被未設計成車輛的組成部分的客戶端DoIP實體使用。這包括任何通過診斷連接器執行診斷通信的插入設備。這些地址應被安裝在車輛上且持續依靠診斷通信進行周期數據檢索的設備使用。為了完成正在進行的車輛內部通信，以避免車輛正常的操作被損壞，DoIP實體可拒絕/延遲從該類型設備接受路由激活請求。不同的IP網絡場景，會導致不同的定時器和對通信性能產生不同的影響。當定義網絡場景的定時參數時，需考慮上述情況。本文件未對可能的網絡架構和結構規定特定的定時器和網絡設置。需求8.DoIP-097APP-DoIP網關將診斷報文從客戶端DoIP實體路由到服務端DoIP實體每個DoIP網關應根據診斷報文(表21)中包含的地址信息，使用服務端特定的車輛網絡傳輸協議，路由通過TCP_DATA套接字接收的診斷報文的用戶數據到車輛網絡中相應服務端。需求8.DoIP-098APP-DoIP網關路由診斷報文從服務端DoIP實體到客戶端DoIP實體每個DoIP網關都應該能夠支持服務器端使用的傳輸協議，正確接收車內子網中服務器端發送的用戶數據，并利用子網中服務器發送的地址信息(源地址和目標地址),將接收到的用戶數據路由到DoIP鏈路上，通過DoIP診斷報文(見表21)發送給客戶端DoIP實體。這說明DoIP網關需確保在相應的TCP_DATA套接字上使用正確的地址信息發送診斷報文。8服務接口所有的傳輸層服務擁有統一的結構。為定義這些服務，規定了三種服務原語類型：——服務請求原語，用于上層的通信層或應用層向網絡層傳遞控制信息及數據；——服務指示原語，用于DoIP層向上層的通信層或應用層傳遞狀態信息及接收到的數據；——服務確認原語，用于DoIP層向上層的通信層或應用層傳遞狀態信息。該服務規范沒有規定具體的應用程序接口，而只是一組獨立于具體實施的服務原語。診斷通信中服務原語的示例見圖14。客戶端會話層客戶端會話層客戶端DolP層網關DolP層網關CAN傳輸層服務端CAN傳輸層DolP_Data.requestODolP(診斷報文)T_Data.request)DoIP(ACK)T_DatFFOCF()CF()CFODoIP(診斷報文)TData.indication)DolP_Data.indicationO一般DolP報文頭檢查()DolP_Data.confirm)標引序號說明：CF——連續幀；FF——首幀；SF——單幀。圖14DoIP層服務接口所有的DoIP層服務擁有統一的格式。服務原語的書寫格式如下：parameterA.parameterB)其中“service_name”是服務的名稱(例如，DoIP_Data),“type”指出了服務原語的類型，"parameterA,parameterB[,parameterC.…]”是服務原語傳輸的一系列DoIP_SDU值。中括號指出該部分參數為可選。服務原語定義了服務用戶(例如：診斷應用程序)如何與服務的提供者(例如：DoIP層)協同運行。本文件規定了以下服務原語：——請求服務原語(service_name.request)用于服務用戶向服務提供者請求一項服務； 指示服務原語(servicename.indication)用于服務提供者通知服務用戶網絡層的一個內部事件或對等協議層實體服務用戶的服務請求；——確認服務原語(service_name.confirm)用于服務提供者通知服務用戶之前的服務請求的結果。注：為每個服務原語提供的參數順序不表示相應報文中參數的順序，僅提供語法的描述。8.2服務原語參數(SPP)需求0.DoIP-182SPP-SPP數據類型定義數據類型應符合如下：——Enum=8bit枚舉——UnsignedByte=8bit無符號數值——UnsignedWord=16bit無符號數值——UnsignedLong=32bit無符號數值——ByteArray=8bit字節數組DoIP_AI參數用于標識報文發送端和報文接收端的源地址(DoIP_SA)和目標地址(DoIP_TA)以及報文通信類型(DoIP_TAtype)。需求0.DoIP-183SPP-SPPDoIP_SA,DoIP邏輯源地址DoIP_SA參數應為UnsignedWord數據類型，并應用于對發送DoIP層協議實體進行編碼。范圍：[00001～FFFFi]需求0.DoIP-184SPP-DoIP_TA,DoIP邏輯目標地址DoIP_TA參數應為UnsignedWord數據類型，并應用于對接收DoIP層協議實體進行編碼。范圍：[000016～FFFF]參數DoIP_TAtype是對DoIP_TA參數的擴展。需求0.DoIP-185SPP-DoIP_TAtype,DoIP邏輯目標地址類型DoIP_TAtype參數應為Enum數據類型，并應用于編碼DoIP層的通信對等實體所使用的通信模式。應支持兩種通信模式：——1對1通信，稱為物理尋址(單播);——以及1對n通信，稱為功能尋址(組播/廣播)。范圍：[00?s～FF?s]注：物理和功能邏輯地址到IP地址的映射詳見7.8。需求0.DoIP-186SPP-Length,PDU長度Length參數應為UnsignedLong數據類型，并應用于對發送/接收的數據長度進行編碼。范圍：[0000000016～FFFFFFFFi6][0GB～4GB(2字節)]需求0.DoIP-187SPP-PDU,協議數據單元PDU參數應為ByteArray數據類型，并應包含上層實體交互的所有數據。范圍：[001s～FFis]需求0.DolP-188SPP-DoIP_Result使用最先匹配的列表參數值向上層指出錯誤。范圍：[DoIP_OK,DoIP_HDR_ERROR,DoIP_TIMEOUT_A,DoIP_UNKNOWN_SA,DoIP_INVALID_SA,DoIP_UNKNOWN_TA,DoIP_MESSAGE_TOO_LARGE,DoIP_OUT-OF_MEMORY,DoIP_TARGET-UNREACHABLE,DoIP_NO_LINK,DoIP_NO_SOCKET,DoIP_ERROR]注：DoIP_Results由圖17中的DoIP診斷報文處理程序邏輯定義。DoIP_Data.request服務用于發送端向接收端的對等實體請求傳輸(PDU)和(Length>,該對等實體通過“DoIP_SA,DoIP_TA,DoIP_TAtype”中的地址信息標識(服務原語參數定義見8.2)。每次請求DoIP_Data.request服務時，DoIP層應通過發送DoIP_Data.confirm服務來通知服務用戶報文傳輸已完成(或失敗)DoIP_Data,request(DoIPTA<Length〉)DoIP_Data.confirm服務由DoIP層發送。該服務原語用于確認DoIP_Data.request服務已完成，服務通過“DoIP_SA,DoIP_TA,DoIP_TAtype”中的地址信息標識。參數<DoIP_Result>提供了服務請求的狀態(參數定義見8.2)。DoIP_Data.confirm(DoIP_SADoIP_TAtype)DoIP_Data.indication服務由DoIP層發送。該服務原語用于指示<DoIP_Result>事件并將從對等協議實體接收到的<PDU>和<Length>傳送給相鄰上層，該對等實體通過“DoIP_SA,DoIP_TA,DoIP_TAtype"中的地址信息標識(參數定義見8.2)。(PDU>和<Length>的參數僅在<DoIP_Result)等于DoIP_OK時有效。DoIP_Data.indication()DoIP_Data.indication服務調用是在接收到DoIP診斷報文后發送的。若DoIP層檢測到DoIP診斷報文中任何類型的錯誤，該條報文應當被DoIP層忽略，并且不應向相9應用層(AL)DHCP是一個客戶端-服務端式DoIP實體網絡協議，該協議提供了IP地址分配機制。DHCP為動態配置的客戶端DoIP實體獲取所有需要IP配置參數提供了一種機制，確保在本地網絡上能成功地進行通信。D