目录

1 传输层和数据链路层(基于ISO 13400-3)介绍

2 传输层

3 DoIP流程解析

4 Autosar中DoIP模块说明

在<<值得收藏的UDS ON CAN的时间参数大整理>>一系列文章中我们介绍了UDSonCAN,本文我们将详细介绍DoIP（Diagnostic communication over Internet Protocol）。DoIP是基于车载以太网的诊断，其具备带宽高，适合传输大量数据的场景，如车上的OTA软件升级。本文篇幅和内容较多，适合多次阅读，收获更多！

从下图可以看出，它和UDSonCan的主要区别在于物理层、数据链路层、传输层和应用层，它们对于服务的支持(14229-1)是相同的(服务层协议(头)是一样的)。

Implementation of UDS document reference according to OSI model

1 传输层和数据链路层(基于ISO 13400-3)介绍

Vehicle network architecture schematics (functional view

主要对边缘节点(可以理解为网关)进行了定义。

理论上因特网协议(IPv4)允许的最大IP数据包长度是64Kbytes,这是由于以太网协议规定了用16位来定义长度，同时需要64个字节作为最小分组长度，最大的payload长度不能超过1500字节。但是我们可以通过IP分包来解决数据包分包的问题。

1.1物理层要求

1）DoIP边缘节点需要支持IEEE802.3中规定的100Base-Tx(100Mbit/s以太网)标准；

2）DoIP边缘节点需要支持IEEE802.3中规定的10Base-Tx(10Mbit/s以太网)标准(支持10Mbit/s的需求的目的是当两个接口不能通过100Mbit/s进行连接的退一步的解决方法)；

3）DoIP边缘节点需要按照IEC60950-1和IEEE 802.3的要求，给连接到外网的变压器线圈之间提供1min 1500V的隔离。

1.2数据链路层要求

1)DoIP边缘节点应支持连接到外部网络上的10Mbit/s以太网；

2)DoIP边缘节点应支持连接到外部网络上的100Mbit/s以太网；

3)DoIP边缘节点应该按照IEEE802.3的规定支持自协商，这样可以保证两个接口可以通过自动握手来实现按照相同的参数(自协商完成传输模式、速率等参数的统一)进行通信；

4)外部测试设备应支持IEEE802.3规定的100BaseTx的标准；

5)测试设备应支持Auto-MDI(X)(它可以自动检测所连接的设备类型，并根据需要自定调整线序，使得不用再人工区分直连线和交叉线)功能。

1.3对于PHY和MAC需求

DoIP边缘节点应该使用一个以太网设备，可以检测物理连接和断开(链路检测)，并通知上层这些事件。

2 传输层

2.1 协议层(IP,Internet Protocol)

IPv4/IPv6 on OSI layers

所有的DoIP实体(DoIP节点和DoIP网关)需要基于相同的IP协议层，但是由于IPv6的优势(更多的IP地址分配、更快的路由速度等)，推荐使用IPv6.

2.2 以太网控制信息协议(ICMP,Internet control message protocol )

ICMP的介绍见<<一文搞懂Autosar以太网协议栈框架>>.

2.3 传输层

2.3.1 TCP传输

TCP的介绍见<<以太网通信之TCP和UDP>>。

Supported TCP ports

TCP使用1对端口(1个接收(本地端口，local port)和1个发送(远程端口，remote port))来简历连接。每个DoIP实体都需要支持上图所示的13400端口(通信的默认端口号)来与外部的测试设备建立连接。

2.3.2 UDP

UDP的介绍见<<以太网通信之TCP和UDP>>。

UDP ports

规定如下所示：

1）所有的DoIP实体都需要监听13400的UDP发现服务；

2）每个DoIP实体都应该通过UDP的数据包(目的端口设置为UDP_DISCOVERY)用于发生如车辆声明消息(vehicle announcement message)等DoIP消息。

3）测试设备需要监听UDP_DISCOVERY这个消息；

4）测试设备需要将发送给DoIP实体的UDP报文中的目的端口号设置为UDP_DISCOVERY，源端口扣根据UDP_TEST_EQUIPMENT_REQUEST来动态分配(49152-65535).

UDP port usage for unsolicited DoIP messages

DP port usage for DoIP request and response messages

2.4 报文结构

DoIP message structure

Generic DoIP header structure

协议版本号由OEM指定。协议类型则根据报文不同而不同，如下所示。

Overview of DoIP payload types

3 DoIP流程解析

可以将这些流程划分为DoIP通信的三个主要阶段，分别为：车辆识别、路由激活和诊断通信阶段。

下边介绍常使用的负载类型。

3.1 DoIP报文头否定响应(0x0000)

Generic DoIP header negative acknowledge structure

Generic DoIP header NACK codes

如上图所示，0x00表示协议版本或者反码不匹配(DoIP-041)，0x01表示类型不支持的负载类型(DoIP-042)，0x02表示长度超过当前DoIP实体的范围(无论当前内存使用情况如何，该负载长度超过 DoIP 报文支持的最大长度(DoIP-043))，0x03表示内存不足(负载长度超过 DoIP 实体的 DoIP 协议栈当前内存的可处理长度(DoIP-044)),0x04表示无效的负载长度(负载长度与特定负载类型的长度不一致。包括负载长度过小或负载长度过大(DoIP-045)).

DoIP generic header handler

3.1车辆识别请求报文( Vehicle Identification Request Message,0x0001)

Payload type vehicle identification request message

此时DoIP头的负载长度为0.

3.2 带EID车辆识别请求报文( Vehicle Identification Request Message with EID,0x0002)

此时负载长度是6.

3.3 带VIN 码的车辆识别请求(Vehicle Identification Request Message with VIN,0x0003)

Payload type vehicle announcement/vehicle identification response message

此时负载长度是17.

3.4 车辆识别响应报文(Vehicle Identification Response Message,0x0004)

用于发送车辆声明或者回复0x0003的报文。

Payload type vehicle announcement/vehicle identification response message

Invalidity values

Definition of further action code values

Definition of VIN/GID sync. status code values

车辆识别请求与响应报文的处理流程

Connection and vehicle discovery in a networked scenario

3.5 路由激活请求与响应

ISO 13400规定，当测试设备需要通过车载DoIP网关将报文路由到车辆内部网络之前，需要执行路由激活阶段，用于激活TCP_DATA Socket上的路由。该阶段包括路由激活请求和路由激活响应。路由激活请求报文由测试设备发送至DoIP实体，路由激活响应由DoIP实体发送至测试设备。

DoIP connection states

DoIP-127表示TCP连接已建立。

DoIP-128表示成功接收到1帧DoIP的路由报文接收到路由激活请求后DoIP实体的状态将变为已注册-Registered，同时initial inactivity timer停止，启动general inactivity timer作为激活状态超时计时器，路由激活消息对应的诊断设备的逻辑地址将和Socket进行关联。

激活过程中包含两个可选的环节：认证-Authentication及确认-Confirmation，是否需要执行认证或确认流程包含在路由激活请求消息中，而具体的认证和确认流程需OEM自定义。如果需要，则对应有两个已注册-Registered状态的子状态已注册未认证-Registered not authticated和已注册未确认-Registered not confirmed。DoIP实体将根据认证和确认的完成情况回复路由激活请求，只有通过相关流程才能最终进入已注册-Registered状态，可以进行后续的诊断通信。

DoIP-129表示已成功完成认证。

DoIP-130表示已成功完成确认。

3.5.1 路由激活请求(payload type:0x0005)

Payload type routing activation request

Routing activation request activation types

激活类型（Activation Type）用来指示不同的身份验证或确认路由激活的特定类型。具体来说分为默认激活模式、法规要求的诊断通信激活（例如全球调和车载诊断系统（WWH-OBD））和由主机厂定义的激活类型，如主机厂可能需要在路由激活过程中添加安全验证。

3.5.2 激活响应报文(payload type:0x0006)

Payload type routing activation response

Routing activation response code values

路由激活响应报文（0x0006）为对路由激活请求报文的响应，是在车内DoIP实体成功接收到路由激活请求报文，并通过一系列验证处理，允许车辆外部报文路由到车内之前发送的报文。其有效载荷的格式如下图所示。

3.6 诊断通信

在完成车辆识别和路由激活后，诊断数据才能通过网络在车辆与测试设备之间传输，从诊断通信阶段才开始正式的诊断数据的交互(即通过UDS相关服务完成诊断信息的读取写入，故障码及快照信息的读取，进行例程控制等操作，与之前的UDSonCan协议相同)。

诊断通信阶段的报文有4种，分别为诊断请求和诊断响应报文、DoIP报文ACK响应报文和DoIP报文NACK响应报文，其中诊断请求报文和诊断响应报文有效载荷的格式一致，包含了诊断数据（UDS诊断数据），且其报文类型标识符一致，都为0x8001；DoIP报文ACK响应报文和DoIP报文NACK响应报文结构相似，用于对DoIP报文的响应，响应过程不涉及上层协议，唯一的区别在于响应代码是ACK还是NACK。ACK代表肯定的响应，即当前DoIP报文可以通过检测，并能将上层协议的诊断数据传输到目标车内的DoIP实体进行处理；NACK代表否定响应，即当前DoIP报文的信息未通过检测，则上层协议的诊断数据无法被车内DoIP实体处理。

3.6.1 诊断请求与响应报文

Payload type diagnostic message structure

Example of ISO 27145-3 request message transported by a DoIP message frame

3.6.2 ACK报文

Payload type diagnostic message positive acknowledgment structure

Diagnostic message positive acknowledge codes

3.6.3 NACK报文

Payload type diagnostic message negative acknowledgment structure

Diagnostic message negative acknowledge codes

3.7 时间参数分析

DoIP timing and communication parameters

参数示意图

其中A_Processing_Time表示Tester连续的报文的最小间隔时间(某些服务DoIP节点需要处理)，其他时间都表示超时时间，即不允许超过的时间。在这里我们再详细聊一下A_Vehicle_Discovery_Timer这个值。

Detailed vehicle identification with VIN/GID synchronisation

该参数是指留给车上DoIP节点做GID同步的时间，诊断设备只有在收到的车辆信息响应报文或车辆声明报文中带有**有效的 VIN/GID 且 VIN/GID sync. status 为 “incomplete(0x10)”**时，才会启动该定时器，等待车上的DoIP节点进行GID同步。该定时器超时时间为5s，超时后诊断设备可再次请求车辆信息。

4 Autosar中DoIP模块说明

4.1 模块交互

4.2 报文分析

报文交互

1 tester广播车辆识别请求；

2 ECU回复，声明自己的信息给tester;

3 tester给ECU发送ARP;

4 ECU回复自己的MAC给tester;

5 tester向ECU请求建立TCP连接(通过三次握手)；

6 tester向ECU发送路由激活请求；

7 ECU回复路由激活成功；

8 tester通过payload type为0x8001向ECU发送诊断消息0x10 0x01服务；

9 ECU通过payload type为0x8002回复肯定响应；

10 tester向ECU回复TCP ACK表示9已收到；

11 ECU通过payload type为0x8001回复诊断响应0x50 0x01.