注释：文中提到的图和表均与13400-2中对应。
ISO 13400-2定义了诊断仪和车辆ECU之间使用DoIP诊断协议（应用层）、IP协议（网络层）、TCP协议（传输层）以及UDP协议（传输层）进行诊断通信的设计需求。
首先基于下面的典型车辆网络架构图介绍标准中涉及的术语：
1、主机（host）：连接到基于IP协议的网络的节点。在互联网世界中，主机这个词很常用。在车载以太网中，我们可以将主机理解为支持IP协议的车辆ECU。2、DoIP节点（DoIP node）：车辆内支持DoIP诊断协议的主机，仅支持对自身的DoIP诊断。3、DoIP网关（DoIP gateway）：车辆内支持DoIP诊断协议的主机，它不仅支持对自身的DoIP诊断，还可以支持对其所连接的车辆子网络上ECU的诊断。4、DoIP边缘节点（DoIP edge node）：以太网激活线（在ISO 13400-3中有定义，可以简单理解为诊断仪用来触发DoIP诊断的硬线信号）所连接的DoIP网关。5、DoIP实体（DoIP Entity）：DoIP节点和DoIP网关统称为DoIP实体。6、诊断电源模式：在之前的文章“整车电源模式”中，笔者对什么是电源模式进行过详细的介绍。诊断电源模式是影响车辆内网络上所有ECU诊断能力的抽象的车辆内部电源供电状态。诊断仪通过诊断电源模式来识别所有网关所连接子网络上的所有ECU的状态是否允许诊断通信。引入诊断电源模式的目的是提供给诊断仪关于所连接车辆是否可以进行诊断的信息或者是否需要将车辆设置为不同诊断电源模式。
接下来按照OSI七层模型从应用层的DoIP诊断协议开始介绍。建议读者在阅读以下内容之前先阅读上一篇文章“DoIP技术基础（一）”。DoIP诊断协议的作用是将诊断应用程序需要传输的数据，比如ISO14229-5（UDSonIP）定义的诊断服务按照一定的格式进行封装。表11（本文中的表格编号和图编号与标准保持一致，便于读者对照标准查阅）描述了DoIP报文的通用结构。DoIP报文由“通用报头”和“特定净荷类型报文数据”组成。通用报头由“协议版本”、“反协议版本”、“净荷类型”、“净荷长度”组成。其中净荷长度使用4个字节表示，单位为字节，因此净荷的最大数据量为4GB。表12介绍了各种净荷类型DoIP报文。根据所包含报文数据内容的不同，DoIP报文分为节点管理报文（净荷类型值为0x0xxx）、车辆信息报文（净荷类型值为0x4xxx）和诊断报文（净荷类型值为0x8xxx）。
节点管理报文包括：DoIP报头负响应报文、车辆识别请求报文、带有EID的车辆识别请求报文（可选）、带有VIN的车辆识别请求报文、车辆公告报文或车辆识别响应报文、路由激活请求报文、路由激活响应报文、活动检查请求报文、活动检查响应报文。
车辆信息报文包括：DoIP实体状态请求报文（可选）、DoIP实体状态响应报文（可选）、诊断电源模式请求报文、诊断电源模式响应报文。
诊断报文包括：诊断报文、诊断报文正响应、诊断报文负响应。
以下为DoIP通用报头处理的相关设计需求定义（本文中设计需求编号与标准保持一致，便于读者对照查看）：
DoIP-036：DoIP实体发送的所有DoIP报文应使用表11定义的通用报头结构。DoIP-156：DoIP实体应支持表11定义的车辆识别请求报文的协议版本默认值，当诊断仪同时支持多个协议版本并且它不知道DoIP实体支持的协议版本时，诊断仪应在车辆识别请求报文中使用协议版本默认值。DoIP-037：每个DoIP实体应按照图7定义的顺序处理所有DoIP报文的通用报头。DoIP-038: 每个DoIP实体应支持表13定义的DoIP报头负响应。
DoIP-087: 在发送完DoIP报头负响应后，每个DoIP实体应按照表14执行所需动作。DoIP-039: 每个DoIP实体应忽略接收到的DoIP报头负响应。
DoIP-040: 在接收到DoIP实体发送的不正确DoIP报文时，诊断仪不应发送DoIP报头负响应。DoIP报头负响应仅用来判定之前发送的DoIP报文的错误状态。在开发阶段为了验证DoIP实体是否正确使用了DoIP报文，诊断仪可以使用DoIP报头负响应。但在量产阶段诊断仪不应发送报头负响应，以免DoIP报文在诊断仪与DoIP实体之间不停地来回发送。DoIP-041: 如果报头中的协议版本或反协议版本不符合表11定义的格式，每个DoIP实体应发送负响应码为0x00的DoIP报头负响应。DoIP-042: 如果DoIP实体不支持报头中的净荷类型，每个DoIP实体应发送负响应码为0x01的DoIP报头负响应。DoIP-043: 如果报头中的净荷长度超出了DoIP实体支持的最大DoIP报文大小（不考虑当前内存使用情况），每个DoIP实体应发送负响应码为0x02的DoIP报头负响应。DoIP-044: 如果报头中的净荷长度超出了当前可用的DoIP协议处理程序内存，每个DoIP实体应发送负响应码为0x03的DoIP报头负响应。DoIP-045: 如果报头中的净荷长度与特定净荷类型规定的净荷长度不匹配（包括特定净荷类型的最小长度、固定长度和最大长度的检测。），每个DoIP实体应发送负响应码为0x04的DoIP报头负响应。
以上介绍了节点管理报文中的DoIP报头负响应报文的设计需求，下面开始介绍节点管理报文中的车辆识别请求报文、车辆识别响应报文以及车辆公告报文的设计需求。
首先说明一下为什么需要“车辆识别”。在之前的文章“DoIP ISO13400-1”中介绍了诊断仪与车辆进行DoIP诊断通信的4种连接方式，如下所示：
1、诊断仪与车辆点对点直接连接；2、诊断仪与车辆通过网络设备中转的点对点连接；3、诊断仪与多辆车通过网络设备中转的连接；4、车辆与多个诊断仪（或者诊断仪中的多个诊断应用程序）通过网络设备中转的连接。
以上4种连接方式中，除了第1种点对点直接连接，诊断仪和车辆都需要通过网络设备中转连接，而某个网络中的网络设备可能还同时负责其它诊断仪和车辆的连接，因此诊断仪必须有能力识别与它进行诊断通信的特定车辆。车辆识别请求报文和车辆公告报文的作用就是为了使诊断仪能够在网络中识别车辆或识别车辆中的DoIP实体。为了与DoIP实体进行诊断通信，诊断仪需要获取DoIP实体的IP地址以及它所在的车辆。在获取了DoIP实体的IP地址之后，诊断仪就可以通过车辆识别请求报文获取特定车辆的VIN/GID和DoIP实体的逻辑地址。以下为车辆识别请求报文、车辆识别响应报文以及车辆公告报文的设计需求：
DoIP-046: 每个DoIP实体应支持表16定义的车辆识别请求报文。
DoIP-047: 每个DoIP实体应支持带有表17定义的EID参数（可选）的车辆识别请求报文。
DoIP-048: 每个DoIP实体应支持带有表18定义的VIN参数的车辆识别请求报文。
DoIP-049: 每个DoIP实体应支持表19定义的车辆公告和车辆识别响应报文。车辆公告和车辆识别响应报文主要包括以下参数：
1、VIN：如果车辆的VIN还没有配置，则需使用表40定义的VIN无效值。在VIN没有配置时，需要使用GID将DoIP实体与特定车辆关联。
2、逻辑地址：物理逻辑地址唯一地表示任何DoIP实体内的诊断应用层实体或连接到DoIP网关的任何ECU中的诊断应用层实体。车辆发现过程允许诊断仪将物理逻辑地址映射到IP地址。功能逻辑地址用于车辆内一组或所有诊断应用层实体的寻址。对于功能寻址，诊断仪为了找到所有功能寻址的ECU可能需要发送多个IP数据报。无法通过单个IP地址来寻址多个DoIP实体。DoIP网关接收到功能寻址的诊断报文则意味着在其连接的车辆子网络上进行多播或广播。表39介绍了所有逻辑地址的分类。
3、EID：当VIN还没有配置时（例如车辆还在总装过程中），EID（Entity ID）作为确定DoIP实体唯一性的标识符。建议使用MAC地址作为EID，以保证EID的唯一性。
4、GID：当车辆还没有配置VIN时，GID作为同一车辆内一组DoIP实体的唯一性标识符。当GID不可用时，应使用表40定义的无效值。
5、需要的后续动作：告知诊断仪所需要的后续动作（表20定义），例如需要发送路由激活请求。
6、VIN/GID同步状态（可选）：告知诊断仪所有DoIP实体是否完成VIN/GID的同步过程（表21定义）。
DoIP-050: 当配置完有效IP地址后，每个DoIP实体应按照表19定义的参数立即发送车辆公告报文，包括发送公告报文的次数以及公告报文之间的间隔时间。车辆公告报文需要发送多次的原因是使用UDP协议并不能保证报文在网络上正确传输。
DoIP-144: 当车辆公告或车辆识别响应报文中需要的后续动作代码为0x10（需要路由激活，表20定义）时，诊断仪可能发送路由激活类型为0xE0（中央安全，表23定义）的路由激活请求报文（表22定义）给DoIP实体，并且根据整车厂在路由激活响应报文（表24）中的定义决定需要执行的特定动作。
DoIP-125: 在发送车辆公告报文时，UDP报文的目标IP地址应该总是设定为有限广播地址。
DoIP-123: 在任何时刻，每个DoIP实体应通过VIN或EID确定唯一性。
DoIP-142: 如果不能保证车辆在任何时刻通过VIN确定唯一性，则车辆应支持EID和GID。
DoIP-51: 在接收到车辆识别请求报文后，每个DoIP实体应发送延迟的（表38中的车辆公告等待时间）车辆识别响应报文。在发出车辆识别响应报文之前等待额外的延迟时间是为了避免当许多DoIP实体连接在同一网络时UDP数据报集中发送。当收到诊断仪广播发送的车辆识别请求时，随机延时发送的车辆识别响应报文允许UDP数据报在保持高效网络利用率的情况下到达诊断仪。
DoIP-52: 当接收到包含VIN的车辆识别请求报文时，如果车辆识别请求报文中的VIN与DoIP实体写入的VIN匹配，则每个DoIP实体应按照表19发送车辆识别响应报文。
DoIP-53: 在接收到包含EID的车辆识别请求报文时，如果车辆识别请求报文中的EID与DoIP实体的EID匹配（例如，DoIP实体的某一个MAC地址，假设DoIP实体具有多个网络接口），则每个DoIP实体应按照表19发送车辆识别响应报文。
由于路由激活和活动检查报文都直接涉及到套接字（Socket）相关的内容，下面先介绍一下什么是套接字，然后再将ISO 13400-2中套接字处理的内容介绍下，以便读者更好地理解路由激活和活动检查报文。
一、套接字介绍
要理解什么是套接字，先要从IP地址和端口号说起。IP地址是大家比较熟悉的，它是TCP/IP网络中普遍使用的主要地址形式。IP地址是OSI模型中网络层的通信地址，它唯一地标识了网络设备的网络层接口，从而使数据通过互联网发送至正确的网络设备。
但问题在于，一个网络设备上可能运行多个应用程序，例如笔记本电脑同时运行了网页浏览器和PC版微信。端口号的作用就是在相同的IP地址下（同一个网络层设备）用来区分不同应用程序（即计算机中的不同应用进程）。TCP和UDP都是OSI模型中的传输层协议，不同的应用层协议在使用TCP和UDP协议传输数据时都需要分配相应的端口号，例如大家熟悉的HTTP协议使用TCP传输层协议，其端口号为80。
总结一下，IP地址是网络层设备之间正确传输数据的关键，但应用层协议还必须关注分配给各个应用程序的端口号，以便能够通过TCP或UDP协议将网络层设备通过IP地址收到的数据发送至不同端口号所对应的应用程序。
IP地址和端口号组合在一起就称为套接字。例如，一个网络设备的IP地址为192.168.3.1，该网络设备上运行的网页浏览器应用程序对应的套接字为192.168.3.1：80。
二、套接字处理及活动检查
首先从诊断仪和DoIP实体之间的逻辑连接状态的角度介绍车辆的DoIP实体的状态信息和行为需求。
外部设备（例如诊断仪）和DoIP实体之间的逻辑连接通过逻辑设备地址（源地址）和套接字保证唯一性。套接字通过源IP地址和端口、目标IP地址和端口以及传输层协议类型（即UDP或TCP）来表示。
DoIP-152: DoIP实体应能够通过套接字处理和关联的源地址区分逻辑连接。
DoIP-153: DoIP实体应为每个逻辑连接提供单独的定时器（初始不活动定时器、通用不活动定时器）。
DoIP-154: 如果DoIP实体支持认证和确认机制，每个逻辑连接都应支持认证和确认状态。
DoIP-127: 当一个新的套接字处于“TCP连接已建立”状态时，它应该以“初始化已完成”的状态加入连接处理表。初始不活动定时器应分配到此连接并启动定时器。
DoIP-128: 在接收到DoIP路由激活报文并且成功完成DoIP协议处理后，初始化已完成的套接字表示一个逻辑连接并且此逻辑连接应更新到“已注册（等待认证）”的连接状态。正在初始化的诊断仪的源地址应与此连接关联。初始不活动定时器应停止，通用不活动定时器应分配到此连接并启动。
DoIP-129: 在认证机制成功完成后或不需要认证时，连接应设定为“已注册（等待确认）”状态。
DoIP-130: 在确认机制成功完成后或不需要确认时，连接应设定为“已注册（路由激活）”状态。
DoIP-131: 除了DoIP路由激活报文或用于认证和确认的报文，其它接收到的DoIP报文在连接处于“已注册（路由激活）”之前不应被处理或者路由。
DoIP-132: 如果初始不活动定时器或通用不活动定时器超时、或者认证或确认失败、或者诊断仪没有对DoIP活动检查报文进行响应，逻辑连接应设定为“结束”状态。
DoIP-133: 如果连接处于“结束”状态（例如，任意一端发出关闭请求之后），TCP套接字应关闭并重置为监听状态，TCP套接字资源释放以允许建立新的连接。
图12描述了各种连接状态之间的转换。
活动检查请求报文只能在一个处于“已注册”状态的连接上发送。处于初始化完成状态并且存储在连接表条目中但仍然没有完成注册（例如，等待一个激活路由请求）的套接字上不应发送活动检查请求报文。如果没有路由激活请求报文发送，此状态的套接字随着初始不活动定时器超时而结束。
DoIP-134: 活动检查报文只在处于某种“已注册”状态的连接上发送。
初始不活动定时器是针对DoIP实体使用无效的DoIP报文在TCP_DATA套接字上尝试连接或者DoIP实体没有发送任何数据的情况下的应对措施。
DoIP-083: 每个DoIP实体所支持的每个TCP_DATA套接字都要使用一个独立的初始不活动定时器。
DoIP-084: 当套接字已处于“已建立连接”状态（open）时，TCP_DATA套接字的初始不活动定时器应重置为初始值T_TCP_Initial_Inactivity(表38)并启动计时。
DoIP-085: 当在TCP_DATA套接字上接收到有效的激活路由请求报文（见表22）后，此TCP_DATA套接字的初始不活动定时器应该立即停止计时。
DoIP-086: 如果TCP_DATA套接字的初始不活动定时器超时，则此TCP_DATA套接字将被关闭并重置为监听状态。
通用不活动定时器是针对网络连接断开或诊断仪没有发送任何数据但未关闭TCP_DATA套接字连接的情况下的应对措施。在此情况下，通用不活动定时器将关闭TCP_DATA套接字，从而使DoIP实体在经过特定时间的不活动状态后回到默认状态。
DoIP-79: 每个DoIP实体所支持的每个TCP_DATA套接字都要使用一个独立的通用不活动定时器。
DoIP-80: 当套接字刚刚处于“已建立连接”状态（open）或者在任何时候套接字上有数据接收或发送时，此TCP_DATA的通用不活动定时器应该重置为初始值T_TCP_Genera_Inactivity(表38)。
DoIP-124: 如果诊断仪需要保持当前的一个空闲连接处于活动状态，则诊断仪应使用活动检查响应报文。
注释：活动检查响应报文是最小的有效报文，它除了重置所对应连接的通用不活动定时器之外不触发任何进一步动作。一个无效的DoIP报文将导致DoIP实体关闭TCP_DATA套接字。
DoIP-081: 只要TCP_DATA套接字处于“已建立连接”状态（open），此TCP_DATA套接字的通用不活动定时器就应该一直运行。
DoIP-082: 如果TCP_DATA套接字的通用不活动定时器超时，则此TCP_DATA套接字将被关闭并重置为监听状态。
套接字处理和活动检查的主要作用是满足DoIP实体应如何处理多个TCP_DATA套接字的需求。此需求是为了保证诊断仪可以与DoIP实体进行连接，并且DoIP实体能在当前连接不受额外连接尝试干扰情况下将未使用的TCP_DATA套接字用于通信。第11章图25展示当诊断仪尝试在一个新建立连接的TCP_DATA套接字上激活路由时触发TCP_DATA套接字处理程序的一个时序图。
DoIP-088: 每个DoIP实体应按照图13定义的顺序实施TCP_DATA套接字处理程序。
注释1：假定TCP_DATA套接字处理程序的TCP堆栈能够保证监听同一端口的多个TCP套接字根据收到的TCP连接尝试动态地分配和使用，直到没有TCP_DATA套接字可用为止。在此情况下，TCP堆栈使用TCP_RST响应拒绝额外的连接尝试。
注释2：为了减少需求的复杂性，每个需求描述聚焦在当前特定的操作，并假定之前的活动检查已经按照图13的时序执行完毕。不同活动检查方法（单个TCP_DATA套接字和所有TCP_DATA套接字）的例子在图14和图15中描述。
DoIP-089: 如果路由激活请求报文中的源地址已经分配给接收路由激活请求所在的TCP_DATA套接字，被请求的DoIP实体应接受此路由激活请求。
DoIP-106: 如果路由激活请求报文中的源地址与当前接收路由激活请求所在的TCP_DATA套接字所注册的源地址不同，被请求的DoIP实体应拒绝此路由激活。
DoIP-090: 如果路由激活请求中的源地址没有分配给任何已建立连接的TCP_DATA套接字并且没有超过DoIP实体能够同时支持的最大TCP_DATA套接字数量，被请求的DoIP实体应接受路由激活请求并将源地址分配给接收路由激活请求所在的TCP_DATA套接字。
DoIP-091: 被请求的DoIP实体应通过当前分配给路由激活请求报文中源地址的TCP_DATA套接字发送活动检查请求报文。
DoIP-092: 如果在T_TCP_Alive_Check（见表38）时间内没有收到活动检查响应报文，DoIP实体应关闭相应的TCP_DATA套接字并接受此套接字上接收到的路由激活请求报文。
DoIP-093: 如果在T_TCP_Alive_Check（见表38）时间内收到活动检查响应报文，DoIP实体应拒绝接受此套接字上接收到的路由激活请求报文。
DoIP-094: 如果源地址已知但没有分配给任何已建立连接的TCP_DATA套接字并且DoIP实体同时支持的最大数量TCP_DATA套接字都已注册，被请求的DoIP实体应该向所有当前已建立连接的TCP_DATA套接字发送活动检查请求。
DoIP-095: 如果在T_TCP_Alive_Check（见表38）时间内没有收到活动检查响应报文，DoIP实体应关闭相应的TCP_DATA套接字。DoIP实体应接受对应TCP_DATA套接字上接收到的路由激活请求并将源地址注册到此TCP_DATA套接字上。
DoIP-096: 如果在T_TCP_Alive_Check（见表38）时间内在所有已注册TCP_DATA套接字上都接收到活动检查响应报文，DoIP实体应拒绝接收到路由激活请求的TCP_DATA套接字的激活请求。
三、路由激活请求报文和路由激活响应报文
路由激活和路由响应报文是为了激活在TCP_DATA套接字的路由所必须发送的DoIP报文。关闭TCP_DATA套接字的路由不需要定义额外的净荷类型，因为可以简单地通过关闭TCP_DATA套接字来实现。第11章图25展示了诊断仪试图激活新建立的TCP_DATA套接字的路由的过程示例。
DoIP-57: 每个DoIP实体应支持表22定义的路由激活请求报文。
路由激活请求报文的主要参数如下：
1、源地址（SA）：发出路由激活请求报文的诊断仪地址。
2、激活类型：特定的激活类型可能需要不同类型的认证和确认。
DoIP-100: 每个DoIP实体应按照图9处理路由激活请求报文。
表23定义了路由激活请求激活类型。
DoIP-58: 每个DoIP实体应按照表24定义支持路由激活响应报文。
路由激活响应报文的主要参数如下：
1、诊断仪逻辑地址：发出路由激活请求报文的诊断仪逻辑地址。
2、DoIP实体逻辑地址：发出路由激活响应报文的DoIP实体逻辑地址。
3、路由激活响应码：由DoIP网关发出。如果诊断仪的路由激活请求被拒绝，DoIP网关将重置与诊断仪的TCP_DATA连接。路由激活成功则意味着DoIP诊断报文现在可以通过TCP_DATA连接进行路由。
DoIP-102: 在发送对应的路由激活响应报文后，每个DoIP实体应该按照表25定义执行所需要的动作。
DoIP-59: 如果收到的路由激活请求报文中的源地址是未知的，每个DoIP实体应发送响应码设置为0x00的路由激活响应报文。
DoIP-60: 如果收到的路由激活请求报文中的TCP_DATA套接字不可用（按照7.2.4套接字处理程序的需求），每个DoIP实体应发送响应码设置为0x01的路由激活响应报文。
DoIP-149: 如果收到的路由激活请求报文中的源地址与当前已激活的TCP_DATA套接字收到的连接条目表不一致，每个DoIP实体应发送响应码设置为0x02的路由激活响应报文。
DoIP-150: 如果收到的路由激活请求报文中的源地址已注册并且在不同的TCP_DATA套接字激活，每个DoIP实体应发送响应码设置为0x03的路由激活响应报文。
注释1：应同时支持多少个源地址由整车厂自行决定。这取决于DoIP实体允许多少个TCP_DATA套接字同时工作，DoIP实体支持的最大同时工作套接字数量可通过7.1.9定义的DoIP实体状态请求报文获取。
DoIP-61: 如果路由激活请求前需要额外的认证， 收到路由激活请求报文之后每个DoIP实体应发送响应码设置为0x04的路由激活响应报文（如果DoIP实体支持）。
DoIP-105: 如果路由激活请求需要车辆的确认但确认结果为拒绝， 收到路由激活请求报文后每个DoIP实体应发送响应码设置为0x05的路由激活响应报文（如果DoIP实体支持）。
DoIP-151: 如果收到的路由激活请求报文中的路由类型DoIP实体不支持， 收到路由激活请求报文后每个DoIP实体应发送响应码设置为0x06的路由激活响应报文。
DoIP-62: 如果下列条件全部满足，收到路由激活请求报文后每个DoIP实体应发送响应码设置为0x10的路由激活响应报文：
1、路由激活请求报文中的逻辑源地址为DoIP实体已知；
2、按照7.2.4的套接字处理程序需求，TCP_DATA套接字可用；
3、不需要额外的认证步骤；
4、不需要车内的确认。
DoIP-63: 如果下列条件全部满足，收到路由激活请求报文后每个DoIP实体应发送响应码设置为0x11的路由激活响应报文（如果DoIP实体支持）：
1、路由激活请求报文中的逻辑源地址为DoIP实体已知；
2、按照7.2.4的套接字处理程序需求，TCP_DATA套接字可用；
3、不需要额外的认证步骤；
4、需要车内发出的额外确认（例如，通过组合仪表显示确认信息报文）。
注释2：这意味着一旦车内已执行了额外的确认，0x11响应码将不再发送并且DoIP实体将按照请求执行路由激活。诊断仪可以周期性地发送路由激活请求报文来判断车内的确认是否已成功完成。
四、活动检查请求报文和活动检查响应报文
活动检查报文的作用是确定一个打开的TCP_DATA套接字是否仍然被诊断仪使用的DoIP报文的报文结构。TCP_DATA套接字处理程序通过活动检查报文进行套接字活动检查（见7.2.4）。第11章图25展示了诊断仪在试图建立一个新的TCP_DATA套接字时触发活动检查报文的时序图。
DoIP-75: 每个DoIP实体应支持表32定义的活动检查请求报文。
DoIP-76: 每个DoIP实体应按照7.2.4的需求发送活动检查请求报文。
DoIP-77: 每个DoIP实体应支持表33定义的活动检查响应报文。
活动检查响应报文的参数如下：
源地址（SA）：当前在TCP_DATA套接字上激活的诊断仪的逻辑地址。
DoIP-78: 每个DoIP实体应按照7.2.4的需求接收和处理活动检查响应报文。
注释：诊断仪也可以使用活动检查响应报文保持当前的空闲连接处于活动状态，即诊断仪之前没有收到DoIP实体发送的活动检查请求报文也可以发送活动检查响应报文。
前面介绍完了DoIP报文中的节点管理报文，本文将介绍剩下的两类DoIP报文：车辆信息报文以及诊断报文。
一、车辆信息报文
车辆信息报文包括诊断电源模式信息请求报文、诊断电源模式信息响应报文、DoIP实体状态请求报文（可选）、DoIP实体状态响应报文（可选）。
1、诊断电源模式信息请求和响应报文
诊断电源模式信息请求和响应报文用于获取车辆的诊断电源模式。诊断仪可能需要使用车辆的诊断电源模式信息，例如诊断仪需要确认车辆是否处于正确的诊断电源模式，从而允许诊断仪对车辆的零部件执行可靠的诊断。
DoIP-116: 每个DoIP实体应支持表34定义的诊断电源模式信息请求报文。
DoIP-117: 每个DoIP实体应支持表35定义的诊断电源模式信息响应报文。
DoIP-118: 在接收到诊断电源模式信息请求报文后，DoIP实体应在A_DoIP_Ctrl(见表38)时间内发送诊断电源模式信息响应报文进行响应。
2、DoIP实体状态信息请求和响应报文
DoIP实体状态信息请求和响应报文用于识别DoIP实体的特定运行状态。例如，允许诊断仪检测当前存在的诊断通信会话以及DoIP实体的能力。
DoIP-119: DoIP实体应支持表36定义的DoIP实体状态信息请求报文（如果DoIP实体支持）。
DoIP-120: DoIP实体应支持表37定义的DoIP实体状态信息响应报文（如果DoIP实体支持）。
DoIP-121: 在接收到DoIP实体状态信息请求报文后，DoIP实体应在A_DoIP_Ctrl(见表38)时间内发送DoIP实体状态信息响应报文进行响应（如果DoIP实体支持）。
DoIP实体状态信息响应报文的参数如下：
1、节点类型（NT）：DoIP节点或DoIP网关；
2、最大可同时支持的TCP_DATA套接字（MCTS）：DoIP实体允许同时连接的最大TCP_DATA套接字数量，不包括为了套接字处理预留的套接字；
3、当前打开的TCP_DATA套接字（COTS）：当前已建立连接的套接字数量；
4、最大数据量：DoIP实体在一次逻辑请求中能够处理的最大数据量。
二、诊断报文
诊断报文包括诊断请求报文和诊断响应报文（诊断正响应、诊断负响应）。
如果诊断报文由诊断仪发送，DoIP实体将总是对这些报文进行响应（正响应或负响应）。诊断报文也可以由DoIP实体发送，例如发送诊断响应报文或发给诊断仪非诊断请求报文（例如基于事件触发的响应）。在这种情况下，诊断仪不会对诊断报文进行响应。
DoIP-64: 每个DoIP实体应支持表26定义的诊断报文结构，包括接收的诊断报文（例如，诊断请求报文）和发送的诊断报文（例如，诊断响应报文）。
诊断报文的参数如下（全部为强制参数）：
1、源地址（SA）：诊断报文发送方的逻辑地址（例如，诊断仪的地址）；
2、目标地址（TA）：诊断报文接收方的逻辑地址（例如，车辆网络中的特定ECU）；
3、用户数据（UD）：实际的诊断数据（例如，ISO 14229-1中定义的诊断服务请求）。
DoIP-65: 每个DoIP实体应按照图10定义的顺序处理在其TCP_DATA套接字上接收到的诊断报文。
表27举例说明了一个ISO27145-3诊断请求是如何通过DoIP诊断报文帧进行传输的。
图10描述了DoIP诊断报文处理流程。
DoIP-66: 每个DoIP实体应支持表28定义的诊断报文正响应。
表29定义了诊断报文正响应的响应（ACK）代码。
DoIP-67: 当诊断报文被正确处理并复制到目标网络的发送缓存后，每个DoIP实体应立即发送响应代码设置为0x00（见表29）的诊断报文正响应。
DoIP-68: 每个DoIP实体应支持表30定义的诊断报文负响应。
表31定义了诊断报文负响应的响应（NACK）代码。
DoIP-70: 当收到的诊断报文中的源地址没有在接收此诊断报文的TCP_DATA套接字上激活时，每个DoIP实体应发送负响应代码设置为0x02（见表31）的诊断报文负响应并关闭TCP_DATA套接字。
DoIP-71: 当收到的诊断报文包含一个未知目标地址（例如，目标地址对应的ECU没有连接到寻址的DoIP网关），每个DoIP实体应发送负响应代码设置为0x03（见表31）的诊断报文负响应。
DoIP-72: 当收到的诊断报文超过目标网络或目标ECU所支持的最大传输协议长度时（例如，CAN诊断报文长度大于4095个字节或超过某个特定ECU的报文长度限制），每个DoIP实体应发送负响应代码设置为0x04（见表31）的诊断报文负响应。
注释1：这意味着如果功能寻址的DoIP诊断报文必须路由到不同的子网（例如，目标地址设定为WWH-OBD功能组地址0xE000）并且一个或多个子网不支持诊断报文的净荷长度，DoIP实体也要发送诊断报文负响应。例如，如果一个报文净荷大小超过7个字节的功能寻址DoIP报文需要路由到包含一路CAN子网的几个不同的子网，CAN子网限制功能寻址请求报文净荷不能超过7个字节（即仅允许单帧）。DoIP网关应发送负响应代码设置为0x04的诊断报文负响应并丢弃这个DoIP诊断请求报文。
DoIP-73: 当诊断报文太长以致不能复制到目标缓存时（例如，传输协议拒绝提供必要缓存的请求），每个DoIP实体应发送负响应代码设置为0x05（见表31）的诊断报文负响应。
注释2：如果DoIP网关使用动态缓存分配，以上问题是暂时性的。
DoIP-103: 当诊断报文的目标地址指向一个当前不可到达的设备时，每个DoIP实体应发送负响应代码设置为0x06（见表31）的诊断报文负响应（如果DoIP实体支持）。
注释3：以上情况可能是因为一个不可用的目标网络（例如，暂时性网络重组或者网络物理错误）。
DoIP-107: 当未知目标网络或传输协议错误发生并且不能被之前的负响应代码覆盖时，每个DoIP实体应发送NACK代码设置为0x07或0x08（见表31）的诊断报文负响应（如果DoIP实体支持）。
DoIP-74: 当DoIP-71到DoIP73、DoIP103、DoIP107的诊断报文负响应情况发生时，每个DoIP实体应丢弃收到的诊断报文。
通过一个简单易懂的DoIP协议标准流程示例，帮助读者更好地理解在一个正确的DoIP协议运行中（不包括可能发生的特例和错误），DoIP协议中各个元素、运行机制和事件发生的顺序。
一、建立连接和发现车辆
1、直接连接场景
当诊断仪与车辆直接连接时，必须使用交叉以太网电缆或者诊断仪和DoIP实体任意一个支持Auto-MDI（X）。
假设不存在DHCP服务器，因此在初始化完成后，DHCP分配IP地址的过程失败，DoIP实体将通过自动配置机制确定本地有效IP地址。
一旦DoIP实体的网络接口通过获取的IP地址配置完成，DoIP实体将通过车辆公告报文广播它的VIN、EID、GID和逻辑地址。车辆公告报文将以UDP_DISCOVERY为目的端口广播（UDP）3次。
由于某些操作系统只有在DHCP失败后才会启动本地自动IP分配机制，诊断仪的自动IP机制可能会延迟启动。由于DoIP实体会同时启动DHCP和自动IP机制，因此DoIP实体的IP配置很可能更快地完成，导致诊断仪收不到初始车辆公告报文。如果诊断仪未能及时完成用于接收初始车辆公告报文的TCP/IP通信配置，诊断仪可能需要使用车辆识别请求报文查询车辆。
图17描述了在直接连接场景下的建立连接和发现车辆过程。
2、网络连接场景
当诊断仪与车辆通过网络连接时，建立连接和发现车辆的过程与直接连接场景有微小区别。诊断仪和DoIP实体连接到网络的物理接连不是必须在时间上保持同步，网络接口配置完成并允许TCP/IP连接尝试的时间点也可能存在明显的差别。
如果诊断仪还没有接收到期望的DoIP实体或者车辆（可能存在多个车辆通过网络发送车辆公告报文）发送的车辆公告报文，诊断仪应通过发送车辆识别请求报文查询车辆。
图18描述了网络连接场景下建立连接和发现车辆的过程。
二、DoIP会话
1、创建套接字连接
要开始创建诊断仪和车辆内DoIP实体之间的连接，第一步是打开一个套接字（目标端口是TCP_DATA），这个步骤必须在任何报文交换之前完成。
DoIP实体必须提供用于处理接收到通信请求的资源（例如，套接字资源）。DoIP实体必须提供足够的套接字资源用于处理需要同时支持的特定DoIP会话数量（例如，支持n+1个套接字，n为会话数量，见DoIP-002）。
如果DoIP实体同时接收到超过n+1个连接尝试，则可能出现由于没有更多的资源可用而导致第n+2个连接尝试被拒绝（因为不再有任何套接字处于监听状态，而不是因为DoIP协议处理的原因）。
套接字连接建立之后必须执行一些初始化动作。例如，要给套接字分配一个初始不活动定时器（见7.2.3）和一个通用不活动定时器（见7.2.2）并启动定时器。此外还需要设定此套接字连接为“已初始化”状态（见7.2.1.3），以确保除了路由激活请求报文之外，不对任何接收到的数据进行路由和处理。所有后续的报文应通过这个TCP_DATA套接字进行发送和接收。
为了在已初始化的套接字连接上进行路由激活，诊断仪需要向DoIP实体发送路由激活请求报文（见7.1.5）。如果诊断仪合法并且当前DoIP实体已注册的活动连接数小于n，则此连接的初始定时器停止如果假设后续不需要额外的认证和确认过程，则此套接字连接切换为“已注册”状态（路由激活），这个状态通过正响应的路由激活响应报文来告知诊断仪，通用不活动计时器重新启动并且保持活动状态。
到此为止有效的DoIP报文（例如DoIP诊断报文）可以被路由或处理了。
2、DoIP报文处理
当接收到任何种类的数据时，DoIP实体首先调用DoIP报文头处理程序。如果净荷包含一个诊断报文（DoIP报文头中净荷类型为0x8001，见7.1.6），则调用诊断报文处理程序来处理净荷。
当接收到一个诊断报文时，如果诊断报文成功通过了诊断报文处理程序（正响应确认），即报文已经通过相应的内部路由机制（假设DoIP实体是DoIP网关）但还没有必要发送给目的ECU。此时，DoIP实体应立即将DoIP报文正响应确认信息发送给诊断仪。
如果是符合UDS的诊断报文净荷，目标ECU发送诊断响应回复诊断仪。这种行为通过封装在DoIP报文中的相应诊断协议来描述，不属于13400-2的范围。
3、套接字资源释放
当诊断仪不再需要套接字连接时，此连接应总是通过TCP/IP协议关闭。DoIP实体发起此连接的终止过程。这个连接终止释放了相应的资源，从而使此套接字可以用于新的连接。如果此连接没有被终止，在通用不活动计时器超时或在执行活动检查后此套接字资源被释放。
图19描述了DoIP会话示例。
三、车辆网络集成
1、车辆识别（车辆视角）
车辆识别（车辆视角）主要说明车辆和车辆内的DoIP实体如何被发现以及如何与它们在网络上的IP地址关联。
车辆一般通过VIN码进行识别。在生产或者售后环境，几个DoIP实体可能安装在同一辆车上，但此时车辆特定的VIN仍没有及时配置。为了将新安装的未配置VIN的DoIP实体和特定的车辆关联，可能使用组标识符（GID）来代替VIN。
这种方法意味着需要存在一个VIN/GID主节点（例如DoIP边缘节点），在同步的过程中所有其它DoIP实体从主节点接收VIN/GID。因为这个同步过程需要一些时间（例如一个新的DoIP实体添加到车辆），在同步完成之前需要定义一个无效值（见表40）提供给DoIP实体使用。DoIP实体之间的VIN/GID同步的具体规范超出了13400-2的范围，由整车厂自行决定。
DoIP-143: 如果车辆内的存在的DoIP实体数量大于1个且不能保证每个DoIP实体总是配置有效的VIN，那么每个DoIP实体应支持车辆GID同步。
注释：可以使用GID主节点的MAC地址作为GID来保证GID的全球唯一性。
图20展示了同一车辆内的2个独立的DoIP实体VIN/GID同步和识别过程。
2、车辆识别（诊断仪视角）
车辆识别（诊断仪视角）说明了诊断仪如何将DoIP网络所连接的所有车辆的DoIP实体进行识别并分组的过程。
图23展示了经过简化的诊断仪执行车辆识别的过程示例。当车辆已经连接到DoIP网络并且完成IP地址分配（见图21）时，DoIP实体在等待A_DoIP_Announce_Wait时间后发送车辆公告报文。
如果诊断仪在以上动作完成之后连接到DoIP网络，诊断仪应通过发送广播式的车辆识别请求来触发车辆公告报文或车辆识别请求响应报文。
所有车辆的DoIP实体应在A_DoIP_Ctrl时间内发送车辆识别请求的响应报文。
如果诊断仪接收到的车辆公告或车辆识别响应报文包含的VIN/GID同步状态为0x10（未完成同步），则意味着车辆内存在DoIP实体没有完成VIN或GID同步，此时诊断仪将对这辆车（通过VIN/GID主节点发送的车辆公告或车辆识别响应报文中的VIN/GID来识别车辆）启动车辆发现定时器。
以上机制允许VIN/GID主节点告知诊断仪车辆内的一些DoIP实体需要更多的时间进行VIN/GID同步。当车辆发现定时器超时，诊断仪要向初始发送的车辆公告或车辆识别响应报文中VIN/GID为无效的DoIP实体发送另外一个车辆识别请求报文。
