原创 王立飞 汽车以太网

概 / 述

上文中我们介绍了DoIP的报文格式和简单的交互机制。今天我们来进一步看看如何利用DoIP进行车辆诊断，以及ISO 13400定义的诊断会话中的细节要求。

– DoIP逻辑地址 –

在车载以太网通信中，因为数据是逐层进行封装和处理的，所以在OSI网络模型中，从数据链路层开始，每一层都会有用于标识发送端或接收端的特定地址，如数据链路层的MAC地址、VLAN ID，网络层的IP地址和传输层的端口号。在DoIP层级中，用来标识DoIP实体的地址为DoIP逻辑地址（Logical address）：

ISO 13400中将逻辑地址分为物理逻辑地址（Physical logical address）和功能逻辑地址（Functional logical address），类似CAN中的物理寻址和功能寻址。在车辆发现的过程中，收发两端会将对方的逻辑地址与IP地址进行映射，保证之后可正确进行诊断会话。逻辑地址长度为2个字节，在车辆声明报文、路由激活报文和诊断报文中都会携带，其定义规则如下表：

表中我们最常见的逻辑地址范围为ECU的逻辑地址（0x0001 — 0x0DFF & 0x1000 — 0x7FFF）和诊断仪的逻辑地址（0x0E00 — 0x0FFF）。此外，有四个需要注意的地方：

a & b : 此逻辑地址块供合法的诊断检测设备或售后诊断设备使用，当出现此类逻辑地址时，其他诊断通信应停止，同时也会减少其他正常功能的通信行为。

c : 此逻辑地址块仅供OEM的内部数据收集或OBD诊断设备使用，不能被外部测试设备使用；

d : 此逻辑地址块供安装在车辆上的长期数据采集设备使用，当接收到此类地址的路由激活请求时，DoIP实体会选择拒绝或延时处理，以防止其影响车内正常的数据交互。

– DoIP逻辑连接 –

DoIP的诊断会话过程是基于TCP实现的，我们知道TCP是面向连接的传输协议，那DoIP是否可以完全依赖于TCP本身的连接来进行数据的交互呢？不完全是，DoIP也有一套自己的连接方式，称之为逻辑链接，其在TCP连接的基础上增加了逻辑地址的概念。DoIP实体通过TCP的五元组（源IP地址、目的IP地址、源端口号、目的端口号、协议类型）加逻辑地址来识别唯一的DoIP连接。下图为DoIP逻辑连接的状态机：

– 我们来依次介绍一下 –

1. 逻辑连接的初始状态为Listen；

2. 当TCP连接建立并进入ESTABLISHED状态后，逻辑连接跳转至Initialized状态并启动Initial inactivity timer；

注：Initial inactivity timer，当DoIP逻辑连接处于Initialized状态时，如未收到有效的路由激活报文，当Initial inactivity timer超时后，DoIP实体会主动关闭此类无效的初始连接。ISO 13400中建议其初始值为2秒。

3. 当接收到诊断仪发送的正确的路由激活报文后，跳转至Registered [pending for authentication] 状态，停止Initial inactivity timer并开启General inactivity timer；

注：General inactivity timer，当DoIP逻辑连接处于Registered状态时，如一段时间之内没有数据的收发行为发生，当General inactivity timer超时后，DoIP实体会主动关闭此类不活跃连接。ISO 13400中建议其初始值为5 分钟，计时器在每一次数据收发时均会被重置为初始值。

4. Registered [pending for authentication] 状态下，如认证完成或无需认证，跳转至Registered [pending for confirmation] ；如果认证失败、General inactivity timer超时或Alive check报文无响应，会跳转至Finalize状态；

5. Registered [pending for confirmation] 状态下，如确认完成或无需确认，跳转至 Registered [routing active] ，到此状态，DoIP逻辑连接激活完成，可以开始进行诊断会话。如果确认失败、General inactivity timer超时或Alive check报文无响应，会跳转至Finalize状态。

状态机中认证（Authentication）和确认（Confirmation）的方法在ISO 13400中并无定义，如果有需求，可使用路由激活报文中的Activation type和Reserved for OEM-specific use字段来实现。

– DoIP参数设置 –

在车辆发现和诊断会话的过程中，ISO 13400定义了若干个时间参数和计时器，用于保证DoIP通信的正常工作，比如上文中的Initial inactivity timer和General inactivity timer，详情见下表：

其中有些参数看起来比较抽象，下面我们通过图示来介绍下他们是如何工作的：

– DoIP真实交互数据 –

下面我们来看几组真实的DoIP报文交互，Wireshark和CANoe为目前常用的两款可以分析车载以太网数据的软件，Wireshark（今天发现wiki上把Wireshark翻译成“导线鲨鱼”，有点意思）在互联网领域应用广泛，开源、功能强大同时免费，并且新版的Wireshark已经可以解析车载网络中的SOME/IP、DoIP和UDS等协议，方便易用。

下图是使用Wireshark抓取了几条DoIP报文，包括两条路由激活报文和三条诊断报文（已隐去部分IP地址和逻辑地址）：

有的同学在抓包的时候有可能会出现下图的情况，这是因为DoIP诊断会话是通过TCP传输的，所以每次接收端都会响应ACK报文，为了防止这些ACK影响数据分析，我们可以在Wireshark的Filter里输入“doip”，将这些TCP的功能报文过滤掉。

下面我们来具体看一下这些报文的数据内容：

Frame No. 12，Routing activation request：

Payload type字段为0x0005，为诊断仪发送的路由激活请求报文，携带了诊断仪的逻辑地址0x0eXX，激活类型为Default 0x00

Frame No. 14，Routing activation response：

Payload type字段为0x0006，为DoIP实体回复的路由激活响应报文，携带了诊断仪和DoIP实体本身的逻辑地址0x0eXX和0x04XX，路由激活响应码为0x10，表示路由激活请求成功，之后就可以进行诊断报文的交互了。

Frame No. 20，Diagnostic message（Request）：

Payload type字段为0x8001，为诊断报文，由诊断仪发给被诊断节点，携带了两端的逻辑地址，Payload部分为UDS 10服务，子功能03，表示进入扩展会话模式。

Frame No. 21，Diagnostic message ACK：

Payload type字段为0x8002，为诊断包报文的ACK，当上一条诊断报文没有错误并可以正确处理时，会回复此报文，仅表示DoIP层面正确，报文已被接收，不会携带UDS服务。

Frame No. 23，Diagnostic message（Response）：

Payload type字段为8001，为诊断报文，携带UDS服务，对Frame No.20中的请求做出了肯定响应，进入扩展会话模式。在Wireshark中，UDS服务的Reply Flag会被单独解析，所以UDS的SID还是10，如果一起解析就变成了肯定响应SID：50。

以上就是真实抓包的一个DoIP诊断会话，大家可以结合上一篇《车载以太网DoIP协议（上）》中介绍的DoIP报文格式和诊断会话流程，自己梳理一下，应该就能对DoIP协议整体有一个大致的了解了。

好了，今天就介绍到这里 给大家分享了 DoIP的逻辑地址、逻辑连接、 相关的时间参数和 一组真实的抓包数据 ， 下一篇王师傅会给大家分享 一些TSN的相关内容 。