GBT 43258.2-2023 道路车辆 基于因特网协议的诊断通信(DoIP) 第2部分：传输协议与网络层服务（正式版）

道路车辆基于因特网协议的诊断通信第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