概/述
在汽车网络通信中，诊断扮演了非常重要的角色，无论是故障筛查、整车下线配置，还是ECU的软件更新、远程OTA等，都离不开诊断技术。传统基于CAN的诊断相信大家都不陌生，那么如果应用了车载以太网，诊断该如何实现呢？答案是DoIP，利用DoIP协议，就可以实现基于车载以太网的诊断服务，从而借助更高速率的数据传输进行车辆诊断的相关工作。今天我们就来简单介绍一下DoIP协议。
DoIP ( D iagnostic communication o ver I nternet P rotocol) 为基于IP的诊断通信协议，顾名思义，是基于IP的，专门用来进行诊断数据传输的协议。DoIP的工作机制和相关需求由ISO 13400的一系列标准进行定义。下图是OSI网络模型，我们可以看到DoIP是位于传输层之上的应用层协议，所以除了基于IP，底层也需要支持TCP/IP协议簇中的DHCP、TCP、UDP、IP、ICMP和ARP等其他协议。
我们知道，汽车诊断使用的是UDS（ISO 14229统一诊断服务），那么使用了DoIP，是不是就不需要UDS了？这里需要注意一点，DoIP只是一个传输协议，用于传输诊断服务，在车载以太网中，UDS和在其他汽车总线技术中使用的是一致的，不同的是传输是通过DoIP实现的。
– DoIP报头格式 –
– 首先先来看一下DoIP的报头格式 –
在以太网帧中，DoIP报文是位于TCP/UDP报头后面的有效负载，如上图。DoIP报头共有四个字段：
Protocol version（协议版本） ： 表示所使用的DoIP协议版本，长度为1字节。常见值为0x02，表示ISO 13400-2：2012（虽然现在已经更新了2019版本，但当前大多数主机厂还是遵循2012版本来使用DoIP的）；
Inverse protocol version（协议版本取反） ： 用于对协议版本进行验证，确保DoIP报文格式的正确性，长度为1字节。如协议版本为0x02，取反值应为0xFD；
Payload type（有效负载类型） ： 表示DoIP报文所携带的有效负载类型，长度为2个字节。大致可分为三类：0x0XXX管理类、0x4XXX车辆信息类、0x8XXX诊断类，其他字段暂时被ISO 13400预留或供OEM自定义使用：
Payload length（有效负载长度） ： 表示DoIP有效负载的数据长度。
在DoIP报头后面会跟随Payload type specific message content（DoIP报文内容，也就是DoIP的有效负载），不同类型DoIP有效负载的格式和长度都不尽相同。
– DoIP有效负载类型 –
上文我们提到了DoIP报文的有效负载有多种类型，下表为负载类型字段的不同值所对应的报文内容：
– 我们来依次介绍一下 –
1. Generic DoIP header negative acknowledge
DoIP报头否定响应报文 (0x0000)，当DoIP实体接收到DoIP报头中某些字段有误的报文时，需回复Generic DoIP header NACK报文，并携带标识错误信息的NACK code。如：接收到Payload type字段未知的DoIP报文、Payload length字段与实际报文长度不一致的DoIP报文等情况，均需回复DoIP header NACK报文，其报文格式如下：
（注：所有DoIP报文均会携带DoIP报头，后文中的报文格式图片会将报头部分省略）
此类型报文在报头后面只会携带一个字节的DoIP header NACK code字段，其不同值的含义如下：
2. Vehicle identification request/response message, Vehicle announcement message
车辆识别和车辆声明报文 (0x0001, 0x0002, 0x0003, 0x0004)，此类报文用于识别和确认网络上的被诊断车辆。诊断仪可通过其获取车辆的VIN（Vehicle Identification number）、GID（Group identification）和DoIP实体的逻辑地址等信息。
ISO 13400中规定，当DoIP实体获取了有效的IP地址后，应在500 ms内发送3条Vehicle announcement message，用于声明自己的车辆信息，具体实现的时候，发送时间和条数可以根据主机厂的需求进行调整。因为是以UDP的方式进行发送，为了尽可能保证报文可被正确接收，所以要发送多次，同时报文的目的IP地址设置为本地限制广播地址（255.255.255.255）。其报文格式如下：
– 共6个字段 –
VIN： 大家都比较熟悉，是车辆识别码；
Logical Address： DoIP实体的逻辑地址，用于直接将诊断请求指向某个DoIP实体，此字段在诊断报文中还会出现；
EID： DoIP实体的唯一识别ID，建议设置为DoIP实体节点的MAC地址，在车辆还未配置VIN时，可以用EID来标识DoIP实体，通常应用于车辆装配阶段；
GID： 同一辆车上多个DoIP实体组的标识。
当传输这条报文时，如果这几个字段还未被设置，应设置为全0或全1的无效值。
最后两个字段分别为1字节的Further action required和VIN/GIN sync. Status。
Further action required： 用于携带额外的信息，告知诊断仪传输过程是否有额外的要求，比如是否初始化连接或者Routing activation是否使用了安全机制等，下图为不同值所代表的含义：
VIN/GIN sync. status： 用于通知外部诊断仪车内的DoIP实体是否已经同步了车辆的GID或VIN，具体含义如下：
有的同学应该已经注意到了，上文中 Vehicle announcement message 报文格式图片的标题后面还有一个 Vehicle identification response message ，是的，这两条报文的 Payload type 和报文格式是一样的，只是出现在不同的场景。 Vehicle announcement message 是主动发送的， Vehicle identification response message 是接收到 Vehicle identification request message 后才会回复的。
Vehicle identification request message 是车辆识别请求报文，本节我们共列了4个 Payload type 值，其实前3个都是 Vehicle identification request message ，只不过会携带不同的请求信息，其格式如下：
普通请求只有DoIP报头，Payload type = 0x0001：
EID请求在DoIP报头后面会跟随一个6字节的EID字段，Payload type = 0x0002：
VIN请求在DoIP报头后面会跟踪一个17字节的VIN字段，Payload type = 0x0003：
当诊断仪想要对已知的某辆车进行诊断时，可发送携带已知车辆VIN或DoIP实体EID的车辆识别请求报文。
3. Routing activation request and response
路由激活报文 (0x0005, 0x0006)，当通过一系列车辆探索、发现和识别报文的交互后，诊断仪可以选择对某一辆或多辆车进行诊断，这时需要事先建立好TCP连接，接下来进行路由激活。这两条报文就是用于路由激活、建立逻辑连接。其报文格式如下：
– 请求报文共4个字段 –
Source address： 外部诊断仪的源地址，此地址为DoIP层级的逻辑地址；
Activation type： 激活类型，不同值代表的类型如下：
剩下的两个字段为 ISO 和 OEM 的预留字段，可自行定义。
– 响应报文共5个字段 –
Logical address of external test equipment： 请求激活的诊断仪的逻辑地址。
Logical address of DoIP entity： 当前DoIP实体的逻辑地址。
Routing activation response code： DoIP网关的路由激活回复码，如果激活失败，DoIP网关会直接重置TCP连接；如果激活成功，表示诊断报文可以通过DoIP网关路由到被诊断节点。回复码的具体值和含义见下表：
剩下两个字段和请求报文一样，为预留字段和自定义字段，可由主机厂根据需求自行定义。
4. Diagnostic message and diagnostic message acknowledgement
通过上述报文的交互，外部诊断仪已经和DoIP网关、DoIP实体建立好了通信连接，接下来就可以进行诊断服务的收发了。诊断报文可分为诊断仪发出的诊断请求、车内节点回复的诊断响应，也包含一些车内节点特定工况下出发的事件类响应。当DoIP实体接收到诊断仪发来的诊断报文后，均会给出确认（肯定确认或否定确认）。
诊断报文共有三个类型：Diagnostic message（诊断报文 0x8001）、Diagnostic message positive acknowledgment（诊断报文肯定确认 0x8002）、Diagnostic message negative acknowledgement（诊断报文否定响应 0x8003）。
Diagnostic message格式如下：
– 共3个字段 –
Source address（SA）： 源逻辑地址，诊断报文发送方的逻辑地址，即外部诊断仪；
Target address（TA）： 目的逻辑地址，诊断报文接收方的逻辑地址，即被诊断节点：DoIP实体；
Diagnostic message data： 诊断报文数据，携带真实的诊断服务（e.g. ISO 14229 UDS）；
Diagnostic message acknowledgment报文格式如下：
– 共4个字段 –
Source address（SA）和 Target address（TA）： 两个字段与诊断报文一致，分别为发送方和接收方的逻辑地址
ACK/NACK code： 用于标识是肯定响应码（ACK code）还是否定响应码（NACK）
Previous diagnostic message data： 将接收到的诊断报文中携带的诊断服务复制回传，用于帮助问题分析。
如果是 肯定响应 ，ACK code仅有一个有效值0x00，其余值均预留；
如果是 否定响应 ，NACK code具体的值和所代表的含义见下表：
当遇到源地址无效、目的地址未知、诊断报文过长、内存不足等情况时，DoIP实体均会回复Diagnostic message negatives acknowledge。
5. Alive check request and alive check response
诊断仪在线检查报文 (0x0007, 0x0008) 用于检测诊断仪是否在线，其报文格式如下：
请求报文不包含数据部分，仅通过通用报文Payload type = 0x0007进行标识：
响应报文会携带2个字节的Source address，用于标识当前响应的诊断仪的逻辑地址：
同时，诊断仪也可通过响应报文去维持当前想保持的诊断通信连接，也就是说在特定情况下，即便没有收到请求报文，诊断仪也可主动发送响应报文。
6. DoIP entity status information request and response
DoIP实体状态信息查询报文 (0x4001, 0x4002) 用于查询DoIP实体的一些状态信息，如节点类型、套接字数量等，其报文格式如下：
请求报文依旧不携带数据：
– 响应报文会携带4个字段 –
Node type： 标识DoIP实体的类型为DoIP节点（0x00）还是DoIP 网关（0x01），0x02 至 0xFF为ISO 13400的预留值；
Max. concurrent TCP_DATA sockets (MCTS)： 表示当前节点13400端口支持的最大并发的套接字连接数量；
Currently open TCP_DATA sockets (NCTS)： 表示当前节点 13400 端口已建立的套接字连接数量；
Max. data size (MDS)： DoIP 实体能处理的最大数据长度。
7. Diagnostic power mode information request and response
诊断模式查询报文 (0x4003, 0x4004) 用于查询车辆是否处于诊断的电源模式下并且可以被执行诊断，其报文格式如下：
请求报文和其他类型请求报文类似，不携带任何数据：
响应报文会携带一个字节的诊断电源模式字段，用于标识车辆的诊断模式：
Diagnostic power mode字段的值与含义见下表：
一共7大类DoIP有效负载类型我们就简单介绍完了，其中诊断仪在线检查报文（0x0007, 0x008）、DoIP实体状态信息查询报文（0x4001,0x4002）和诊断模式查询报文（0x4003, 0x4004）是在特定场景下使用的，正常的流程中不是必须的。
– DoIP会话 –
下面我们结合一个完整的DoIP会话，来帮大家梳理下上文介绍到的这些报文类型是如何应用的
1 诊断仪连接车辆，物理连接建立；
2 配置IP地址，配置的方法有两种，DHCP和Auto-configuration，当DHCP配置不成功时，才会启动Auto-configuration。在DHCP流程中，通常由外部诊断仪来扮演DHCP Server；
3 DoIP实体主动发送3次Vehicle announcement message；
4 当未收到DoIP实体发送的Vehicle announcement message时，诊断仪应主动发送Vehicle identification request，DoIP实体接收并响应Vehicle identification response。如收到Vehicle announcement message，此步骤可跳过；
5 当车辆识别后，诊断仪应发起TCP同步，和DoIP实体建立TCP连接；
6 TCP连接建立后，诊断仪应发送Routing activation request，DoIP实体接收并响应Routing activation response，DoIP逻辑连接建立；
7 接下来就可以进行诊断服务的传输了，诊断仪发送Diagnostic message request，DoIP实体接收并响应Diagnostic message response。这里图中的DoIP message ACK是DoIP层级的确认报文（0x8002，0x8003）。
图中出现了四个端口号，UDP_DISCOVERY，UDP_TEST_EQUPMENT，TCP_DATA和动态分配。车辆发现的过程是通过UDP进行数据传输的，在ISO 13400中规定，UDP_DISCOVERY为13400端口，UDP_TEST_EQUPMENT和动态分配的端口号可以在私有端口号中动态选择（49152 – 65535）。诊断会话是通过TCP进行数据传输的，在ISO 13400中规定，TCP_DATA为13400端口，在DoIP工作期间，DoIP实体应持续监听13400端口。以上就是一个完整的DoIP诊断会话。
好了，今天就先到这，给大家介绍了 DoIP的报文格式和简单的交互机制 ， DoIP的下一篇文章王师傅会结合一些 实际数据 给大家介绍 如何利用DoIP进行车辆诊断 。
