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

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