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

车载以太网DoIP 协议,万字长文详解DoIP DiagnosticCo 协议是一种用于汽车诊断通信的协议 它允许通过 IP 网络 如以太网 进行诊断操作

大家好,欢迎来到IT知识分享网。

  • 🍅 我是蚂蚁小兵,专注于车载诊断领域,尤其擅长于对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 -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、反向协议版本

2.3 负载类型

在这里插入图片描述

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

在这里插入图片描述

2.3.1 DoIP首部否定响应码

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实体的逻辑地址等信息。

在这里插入图片描述

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 路由激活报文

在这里插入图片描述

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 在线检测请求报文

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

在这里插入图片描述

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

在这里插入图片描述

在这里插入图片描述

2.3.5 诊断报文

2.3.5.1 诊断肯定报文示例

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

在这里插入图片描述

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实体状态请求报文

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

在这里插入图片描述
如下图所示日志。

在这里插入图片描述

2.3.6 诊断电源模式

等补日志截图。

3 DoIP 激活线

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通信时间参数

在这里插入图片描述

在这里插入图片描述

🌎总结

23

7

  • 🚩要有最朴素的生活,最遥远的梦想,即使明天天寒地冻,路遥马亡!


  • 🚩如果这篇博客对你有帮助,请 “点赞” “评论”“收藏”一键三连 哦!码字不易,大家的支持就是我坚持下去的动力。
    18


免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://haidsoft.com/114766.html

(0)
上一篇 2025-12-06 20:20
下一篇 2025-12-06 20:33

相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注微信