我们上一篇文章提到，DoIP报头中有两字节的数据类型（Payload Type），代表DoIP报文类型，本文就来详细介绍一下每一种报文类型。
标准中对报文类型的定义如下：
数据类型分为三部分，标绿的是节点管理报文，标黄的是状态信息获取报文，标蓝的是诊断报文。
1. 节点管理报文节点管理报文的作用主要是获取DoIP节点的信息、建立连接、保持连接等。
① 0x0000：Generic DoIP header negative acknowledge当DoIP节点收到的DoIP报文的报头不符合规则时，返回该数据类型的报文。该报文的数据部分只包含1字节的否定响应码（Generic DoIP header NACK code），用来指示错误原因，定义如下：
上表中，Required action表示DoIP节点在发送完该否定响应报文后应该采取的动作，是忽略该报文还是关闭套接字。
该报文可使用上文所述的三种端口类型作为目的端口，具体使用哪种取决于DoIP请求使用的哪种端口。
② 0x0001：Vehicle identification request message该类型报文可以用来请求网络中DoIP节点的车辆信息，诊断设备用UDP报文向网络中发送该报文，来获取被诊断节点的VIN、GID、EID、逻辑地址等信息。
该报文中只包含DoIP报头，没有数据。
该报文的目的端口为UDP_DISCOVERY。
③ 0x0002：Vehicle identification request message with EID该类型报文的作用和上面的一样，只是在请求报文的数据中搭载了6字节EID，可请求指定EID的DoIP节点的其它车辆信息，用于被诊断节点的EID已知的情况。
EID是DoIP节点的唯一识别标识符，一般会被设置为该节点的MAC地址。
该报文的目的端口为UDP_DISCOVERY。
④ 0x0003：Vehicle identification request message with VIN该类型报文原理同上，只是在报文数据中搭载的不是EID，而是17字节的VIN，用于DoIP节点的VIN已知的情况下，请求指定VIN的DoIP节点的其它信息。
该报文的目的端口为UDP_DISCOVERY。
⑤ 0x0004：Vehicle announcement/Vehicle identification response message从名称中可以看出，该类型的报文有两种用途，第一个用途是以上三种报文的响应报文（Vehicle identification response message），当诊断节点发送了以上三种车辆信息请求报文后，符合条件的DoIP节点将会返回该响应报文，报文数据部分的格式如下：
报文数据共33字节，包含：
1字节VIN/GID sync. status：该字节用来表示车内的DoIP节点是否已经完成了VIN或GID的同步（如何同步后文详述）。定义如下;
作为车辆信息响应报文使用时，该报文的目的端口为UDP_TEST_EQUIPMENT_REQUEST。
该报文的第二个用途是作为车辆声明报文（Vehicle announcement），标准规定，当一个DoIP节点成功获取到IP地址后，应在500ms内发送3条车辆声明报文，向网络中的所有DoIP节点广播自己的车辆信息，这时数据部分的定义和上面相同，发送时使用UDP，IP地址设置为255.255.255.255。实际应用过程中发送时间和发送报文数目可能会根据实际情况有所调整。
作为车辆声明报文使用时，该报文的目的端口为UDP_DISCOVERY。
⑥ 0x0005：Routing activation request在车辆发现阶段结束后，外部诊断设备已确定对哪个DoIP节点进行诊断，也获取了必要的信息，这时就需要发送路由激活请求报文，在诊断设备和被诊断的DoIP节点间建立起TCP连接，以便于发送诊断数据（诊断报文都是用TCP来发送的）。
路由激活请求报文由外部诊断设备发送，目的端口为TCP_DATA，源端口可动态定义。报文的数据格式如下：
数据共11字节，包含以下内容：
源地址（SourceAddress）：外部诊断设备的逻辑地址，与诊断通信中的逻辑地址相同。这个逻辑地址用于对某个特定的DoIP节点进行寻址，与UDSonCAN中的CAN ID是类似的概念，是在网络架构设计阶段就分配好的。标准中的范围划分如下图所示，其中红色框内的范围用于诊断设备的逻辑地址，0x0E00-0x0E7F用于OBD诊断，0x0E80-0x0EFF用于增强型诊断。蓝色框内的逻辑地址用于DoIP节点，与UDSonCAN类似，节点的逻辑地址有两个，一个是物理逻辑地址，在0x0001-0x0DFF或0x1000-0x7FFF范围内，另一个是功能寻址，是0xE000。
激活类型（activation type）：用于诊断设备通知被诊断DoIP节点进入哪种类型的诊断状态。定义如下：
剩余字节为保留或自定义字段，一般没有作用。
⑦ 0x0006：Routing activation responseDoIP节点收到诊断设备的路由激活请求报文后，建立TCP连接，并返回该路由激活响应报文，源端口为TCP_DATA，目的端口为诊断设备动态定义的端口。路由激活响应报文的数据格式如下：
响应中的参数定义如下：
其余字段为预留或自定义字段，不常用。 ⑧ 0x0007：Alive check request
诊断仪在线检查报文，用于DoIP节点检查诊断设备是否还处于连接状态。该报文由DoIP节点在与诊断设备建立了TCP连接后用TCP_DATA端口发送，不携带DoIP数据，报文中只有DoIP报头。
⑨ 0x0008：Alive check response诊断设备在收到DoIP节点发送的诊断仪在线检查请求报文后，发送该响应报文，数据中携带两字节的诊断设备逻辑地址：
此外，诊断设备也可以在没有收到请求报文的情况下向DoIP节点发送该响应报文，以通知DoIP节点诊断设备仍然在线。
该报文可以被诊断设备用来请求DoIP节点的状态，报文数据段没有数据。
② 0x4002：DoIP entity status response该报文是上一个报文的响应报文，DoIP节点用该响应报文来向诊断设备发送状态信息。报文的数据段定义如下：
该报文可以被诊断设备用来请求DoIP节点的电源模式信息，报文数据段没有数据。
④ 0x4004：Diagnostic power mode information response该报文是上一个报文的响应报文，DoIP节点用该响应报文来向诊断设备发送电源模式信息，来告知诊断设备当前节点是否允许进行诊断。报文的数据段定义如下：
诊断报文有三个： 0x8001-0x8003：Diagnostic Message and Positive/Negetive Acknowledgment
我们先把三个放在一起看。DoIP诊断通信流程和CAN不一样，CAN是一条诊断请求对应一条诊断响应，但DoIP遵循如下流程：
诊断设备发送一条诊断请求（0x8001-Diagnostic Message），该请求中搭载了UDS诊断数据，DoIP节点收到后先对DoIP报头、诊断数据长度等做判断，先返回一个DoIP层的响应，如果各个条件都满足，则返回肯定响应（0x8002-Diagnostic message positive acknowledgment），否则返回否定响应（0x8003-Diagnostic message negative acknowledgment）。
当DoIP节点返回肯定响应后，再将诊断请求报文中搭载的UDS诊断信息上报给UDS应用程序进行处理，处理完成后，不论是UDS肯定响应还是UDS否定响应，都用诊断报文（0x8001-Diagnostic Message）将UDS诊断响应数据发送给诊断设备。至此一次诊断数据交互才完成。
流程示意图如下图所示：
我们再分别来看一下三种诊断报文的数据段定义。
包含两字节诊断报文发送方源逻辑地址，和两字节接收方目的逻辑地址，以及UDS诊断数据。UDS诊断数据可以是UDS请求，也可以是UDS肯定响应和否定响应。
以下是一条包含UDS诊断请求数据的DoIP诊断报文示例：
② 诊断肯定响应报文（0x8002-Diagnostic message positive acknowledgment）
同样包含发送方和接收方的逻辑地址，还有一字节响应码，以及诊断请求报文中的诊断数据，以便于分析原因。响应码应置为0x00，具体定义如下：
与肯定响应报文的区别就是响应码变成了否定响应码，用来指示否定响应的原因，定义如下：