车载以太网DoIP 协议，万字长文详解

本文主要是介绍车载以太网DoIP 协议，万字长文详解，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

• 🍅 我是蚂蚁小兵，专注于车载诊断领域，尤其擅长于对CANoe工具的使用
• 🍅 寻找组织 ，答疑解惑，摸鱼聊天，博客源码，点击加入👉【相亲相爱一家人】
• 🍅 玩转CANoe，博客目录大全，点击跳转👉

---

📘前言

DoIP(Diagnostic Communication over Internet Protocol) 协议是一种用于汽车诊断通信的协议，它允许通过IP网络（如以太网）进行诊断操作。DoIP协议的设计初衷是为了解决传统基于CAN (Controller Area Network) 总线的诊断通信方式在带宽、灵活性以及远程访问方面的限制。

DoIP协议的主要特点包括：

• 基于IP网络：DoIP协议使用标准的TCP/IP协议栈进行通信，这意味着它可以通过任何支持IP网络的连接进行诊断操作，无论是本地网络还是远程网络。

• 高带宽：相比CAN总线，以太网提供了更高的数据传输速率，这使得DoIP协议在进行大量数据传输（如软件更新或故障记录）时更加高效。

• 灵活性：由于DoIP基于IP网络，它可以轻松地与现有的IT基础设施集成，支持多种设备和系统之间的互操作性。

• 安全性：DoIP协议支持加密和身份验证机制，以确保诊断通信的安全性，防止未经授权的访问和数据泄露。

• 支持远程诊断：通过DoIP协议，制造商或服务提供商可以远程访问车辆的诊断系统，进行故障排除、软件更新等操作，从而提高了服务效率。

DoIP协议定义了如何建立和维护诊断会话、如何发送和接收诊断消息、如何处理错误等。它使用特定的消息格式和通信规则来确保数据的正确传输和解析。在实际应用中，DoIP协议通常与UDS (Unified Diagnostic Services) 协议一起使用，UDS定义了各种诊断服务的具体内容和行为。

随着汽车行业的不断发展，特别是在电动汽车和智能网联汽车领域的快速进步，DoIP协议作为一种高效、灵活且安全的诊断通信方式，正逐渐成为行业标准。

1、DoIP 协议

由于DoIP现协议是基于以太网技术的车辆诊断协议，所以Doip协议在OSI参考模型各分层传递方式与传统以太网一致。

ISO 134001-2定义了用于车辆诊断的网络层和传输层协议以及服务，是DoIP协议的主要部分。

下图是一个汽车车载网络的拓扑结构图，以太网用于主干网络，CAN/LIN网络主要用于分支网络，分支网络信号通过各个域的网关路由到主干网络。

下图是ISO-13400-2标准中截取的车辆网络架构原理图，这张图上被分为外部网络（Externel network）和车辆的网络（Vehicle network）

• Doip Edge Node：是连接激活线的节点，Tester可以通过该节点对车辆进行Doip通信
• Network Node：连在IP网络上,但不能实现DoIP的节点
• Active line：可以通过给该端口一个2V-32V的电压，激活Doip节点，与车辆建立Doip通信。
  

2、DoIP 报文格式

DoIP协议是应用层协议，DoIP报文是下层TCP/UDP数据包中有效载荷（Payload）内容。DoIP报文由报头和数据段组成。

DoIP报头由协议版本 、反向协议版本、负载类型和负载长度组成，下表展示了DoIP报头结构。

2.1、协议版本

协议版本号: DoIP的协议版本号

• 0x00: 预留
• 0x01: DoIP ISO/IDS 13400-2:2010
• 0x02: DoIP ISO 13400-2:2012
• 0x03: DoIP ISO 13400-2:2019
• 0x04…OxFE:预留
• 0xFF:车辆识别请求报文默认值

2.2、反向协议版本

协议版本号取反:对协议版本进行校验,确保正确的DoIP格式
如:协议版本0x03,则此值为0xFC

2.3 负载类型

Doip报头的负载类型如下表所示

2.3.1 DoIP首部否定响应码

DoIP报文在发送出去前，如果检测到错误，比如格式错误，未知负载类型，报文过长，超出内存等会，Doip实体会响应一帧负载类型为0000，负载为1个字节的否定码的报文。

ISO 13400 -2中定义的NACK Code 定义如下图所示：

• 每个DoIP实体必须支持DoIP首部否定响应
• 每个DolP实体应该忽略收到的DoIP首部否定响应报文
• 测试仪收到不符合规范的DoIP报文不应该发送首部否定应答
  

2.3.1.1 格式错误（0x00）示例

如下图，发送一个格式错误的Doip请求，Doip实体响应了NACK Code 0x00，并且主动断开TCP连接

2.3.1.2 未知的负载类型（0x01）示例

如下图，基于UDP连接，发送一个负载类型为0x00E1（未定义的）Doip请求，Doip实体响应了NACK Code 0x01。

2.3.1.3 报文过长（0x02）示例

负载长度在DoIP报头中占4个字节，原则上可以支持传输4 GB (4 294 967 295 字节)，但是最大允许的负载长度取决于车辆的传输层配置，比如本案例最大支持0x0010000个字节，超过这个字节长度将报NACK 0x02。

2.3.1.4 超出内存（0x03）示例

暂无实际案例

2.3.1.5 无效的负载长度（0x04）示例

如下图，发送一个车辆识别请求Doip报文，负载长度应该为0，这里写入1，则Doip实体响应了NACK Code 0x04。

2.3.2 车辆声明报文

车辆识别和车辆声明报文 (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）。
车辆声明报文发送流程如下图所示：

2.3.2.1 车辆识别请求（0x0001）

如下图，客户端发送 02 FD 00 01 00 00 00 00 车辆识别请求，DoIP实体返回的车辆识别响应报文，车辆识别响应报文内容包含 VIN、逻辑地址、EID、GID等信息。

DoIP实体的车辆识别报文的格式如下表所示，负载长度为33个字节。

其中 Further action required 的可能值如下表所示，一般情况下为0x00。

VIN/GID sync. status 参数的可能值如下表所示，该参数为可选参数。

2.3.2.2 带EID请求车辆识别请求（0x0002 ）

如下图，客户端发送 02 FD 00 02 00 00 00 06 70 B3 D5 20 00 01 带EID的车辆识别请求，如果EID正确，则DoIP实体返回负载类型为0x0004的车辆识别响应报文，否则DoIP实体不响应。

2.3.2.3 带VIN请求车辆识别请求（0x0003 ）

如下图，客户端发送 02 FD 00 03 00 00 00 11 50 41 4E 47 55 30 31 32 30 35 37 34 39 30 08 34 37 带VIN的车辆识别请求，如果VIN正确，则DoIP实体返回负载类型为0x0004的车辆识别响应报文，否则DoIP实体不响应。

2.3.3 路由激活报文

ISO 13400规定，当测试设备需要通过车载DoIP网关将报文路由到车辆内部网络之前，需要执行路由激活阶段，用于激活TCP_DATA Socket上的路由。该阶段包括路由激活请求和路由激活响应。路由激活请求报文由测试设备发送至DoIP实体，路由激活响应由DoIP实体发送至测试设备。
流程如下图所示，先与DoIP实体通过TCP建立连接，然后测试仪发送负载类型为0x0005的路由激活请求，Doip实体响应负载类型为0x0006的激活响应报文。

下表是路由激活请求的参数和字节大小。

下图是路由激活响应的参数和字节大小。

下表是路由激活响应报文中 Routing activation response code的可能的值，如果为0x10则说明路由激活成功，如果为0x00则表明SA的逻辑地址不对，如果为0x03，则表明当前的SA逻辑地址已经处于激活状态。

2.3.3.1 不支持的SA地址（0x00）

如下图，客户端发送 02 FD 00 05 00 00 00 07 01 01 00 00 00 00 00 ，其中 0x0101是DoIP实体不支持的SA地址，所以DoIP实体响应了0x00 状态码。

2.3.3.2 已经激活的TCP连接上使用不同的SA地址（0x02）

如下图，在已经激活的TCP连接上，使用了不同的SA地主，DoIP实体报0x02状态码

2.3.3.2 不同的TCP连接上使用相同的SA地址（0x03）

如下图，在不同的TCP连接上，不可以使用相同的SA地址，否则Doip实体报0x03状态码

2.3.4 在线检测请求报文

下图是在线检测请求报文的处理流程，只有在已经建立了至少一个的TCP连接的情况下，测试仪再次发送路由激活请求的时候，DoIP实体才会发出在线检测请求报文。
这里注意：

• 在线检测请求报文由DoIP实体发出
• 测试仪在超时时间(T_TCP_Alive_Check )内未回复响应报文, DolP实体会断开TCP连接

如下图日志，在第二次TCP连接后，发送路由激活请求后，DoIP实体发送负载类型为0x0007的在线检测报文，这里测试仪给了逻辑地址为0x0008的响应报文，并且Soure address参数为0E80，告诉DoIP实体，SA地址为0E80的诊断仪仍然在线。

第二种情况是，Doip实体发出在线检测报文后，测试仪没有给出响应，然后Doip节点会主动断开TCP连接，并且给出路由激活正响应报文。
注意，TCP断开连接的Port口是 0x07DA，也就是第一次TCP连接时的Port口。

2.3.5 诊断报文

2.3.5.1 诊断肯定报文示例

由下图可以看出，要和DoIP进行诊断通讯，需要先建立TCP连接，然后路由激活，最后才能发送诊断请求。

诊断报文的负载数据的前4个字节分别是源逻辑地址（2个字节，诊断仪的逻辑地址）和目的逻辑地址（2个字节，Doip实体或者路由到子网的某个ECU的逻辑地址）
用户数据（User data）部分才是UDS的数据

2.3.5.2 诊断否定报文示例（无效的源逻辑地址NACK为0x02）

如果诊断仪发送的诊断报文有误，DoIp实体将返回负载类型为0x8003的诊断否定响应码，即NACK Code，具体的值定义如下图表。
这里要区分NACK和UDS的NRC的区别。DoIP实体会通过负载类型0x8001返回UDS的NRC码，属于诊断肯定响应。

如下图，正常连接TCP和路由激活后，使用无效的SA地址发送诊断请求，DoIP实体返回NACK为0x02的否定响应报文，并主动断开TCP连接（ISO 13400-2 强制要求）

2.3.5.3 诊断否定报文示例（目的逻辑地址无效NACK为0x03）

如下图，正常连接TCP和路由激活后，使用无效的TA地址发送诊断请求，DoIP实体返回NACK为0x03的否定响应报文（无需断开TCP连接）

2.3.6 DoIP实体状态请求报文

负载类型0x4001用于测试仪向DoIP实体请求状态，DoIP实体收到该请求后返回负类型为0x4002的响应报文。
响应的数据如下表所示：

• DoIP实体状态请求和应答报文通过UDP报文实现。
• Node type (NT) ： DoIP节点类型，0为网关，1为节点。
• Max.concurrent TCP_DATAsockets (MCTS) ：最多允许同时多少个TCP的连接存在
• Currently open TCP_DATA sockets (NCTS)：目前打开着的TCP连接数量

如下图所示日志。

2.3.6 诊断电源模式

负载类型0x4003和0x4004用于检索车辆的诊断功率模式。测试仪根可以根据DoIP实体响应的诊断电源模式，从而可以对车辆的组件执行可靠的诊断。

3 DoIP 激活线

传输层和网络层服务由ISO13400-2协议定义,物理层和数据链路层由ISO13400-3协议定义。

3.1 物理层要求

3.2 数据链路层要求

3.3 整车激活线需求

DoIP激活线的主要作用是激活诊断通信。它通常与边缘节点（DoIP edge node）连接，用于在车辆检测和维修等场景中，通过诊断读取车辆的状态进行故障跟踪。当激活线上的电压满足一定条件时，边缘节点会被激活，从而启动诊断通信。这有助于降低电磁干扰、减少电源消耗，并在非诊断通信期间使与诊断相关的功能处于关闭状态，从而进一步降低能耗和对网络带宽的消耗。

DOIP激活线通过控制诊断通信的激活状态，实现了对车辆诊断功能的精确控制，提高了诊断效率和准确性，同时也保障了车辆和诊断设备的安全性。

下图是以太网和激活线的等效原理图。

由下面两张图可以看出

• 当激活线上的电压低于Vinactive=2V时即使外部诊断仪已经连接车辆，边缘节点也不会激活诊断通信，可避免激活线上由于地偏电压或电磁干扰引起的压降误激活；
• 当激活线上的电压大于Vactive=5V，小于Vmax时边缘节点需要在200ms内激活诊断通信，边缘节点会将外部诊断设备物理连接的信息传递到上层，从而使能车辆声明报文的发送；当电压维持在此状态时节点要维持被激活状态；
• 当激活线上的电压又降至Vinactive=2V以下且持续时间超过200ms时边缘节点重新回到未激活状态，此时对于边缘节点来说诊断仪是掉线状态。
  

3.4 诊断连接器需求

4 传输层TCP/UDP连接端口号

传输层要求:

• 每个DoIP实体(IPv4和IPv6)应实现IETF RFC 793、 IETF RFC 1122中规定的TCP要求
• 每个DoIP实体应实现IETF RFC 768、IETF RFC 1122中规定的UDP相关要求
• 每个DoIP实体应支持<n + 1>个TCP socket,其中是相应DolP实体支持的并发TCP数据连接数
• 每个DoIP实体应支持<k + 1>个TLS socket,其中是相应DolP实体支持的并发TLS数据连接数
• 支持TCP/DoIP实体监听端口号13400 (unsecured)
• 支持TCP/DolP实体监听端口号3496 (secured)
• 支持UDP/DoIP实体监听端口号13400

TCP DATA：

• DoIP实体监听端口13400,接收Unsecured TCP连接和数据
• DolP 实体监听端口3496，接收Secured TCP连接和数据
• 测试仪连接13400或3496
  

UDP_DISCOVER:

• 测试仪/DoIP实体需要监听此端口
• 测试仪/DoIP实体主动发送数据时目的端口

UDP_TEST_EQUIPMENT_REQUEST:

• 测试仪/向DoIP实体发送报文时自定义端口

5 DoIP通信时间参数

🌎总结

• 🚩要有最朴素的生活，最遥远的梦想，即使明天天寒地冻，路遥马亡！
  
  
• 🚩如果这篇博客对你有帮助，请 “点赞” “评论”“收藏”一键三连 哦！码字不易，大家的支持就是我坚持下去的动力。
  
  

这篇关于车载以太网DoIP 协议，万字长文详解的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---