当前位置：首页 > news >正文

浅浅学:DoIP工作流程及基于DoIP的诊断/刷写工具

news 来源：原创 2025/6/28 15:55:22

注：阅读本文需要对UDS及BootLoader有一定了解，基础内容不做赘述。

在汽车"新四化"浪潮的推动下，智能座舱、自动驾驶、车路协同等创新技术正加速重构行业格局。随着车载ECU数量突破百个量级，软件代码量呈指数级增长——高端车型软件规模已超2亿行代码，软件成本占比超过40%。在此背景下，车载系统的迭代效率与用户体验直接挂钩，使得整车OTA（Over-The-Air）升级从技术亮点演变为刚需能力。

传统CAN/LIN总线受限于带宽瓶颈（CAN通常仅1Mbps），在面对动辄数百MB的OTA固件包传输时已显乏力。以太网凭借其100Mbps/1Gbps的高吞吐量、低延迟特性，成为新一代EE架构的核心骨干网。值得注意的是，当诊断协议从CAN总线迁移至以太网时，沿用三十余年的UDS（Unified Diagnostic Services）诊断框架面临协议栈重构的挑战——原有基于CAN标识符的寻址方式需要转换为IP地址通信，传输层协议也需要适配TCP/IP网络特性。

正是这种"传统诊断服务"与"新型车载网络"的融合需求，催生了DoIP（Diagnostic communication over Internet Protocol）协议。作为ISO 13400国际标准，DoIP不仅实现了UDS诊断服务在以太网环境中的无缝移植，更通过IP分片机制支持超大诊断数据包的可靠传输，为智能化时代的车辆诊断、远程刷写、安全监控等场景提供了关键基础设施。

本文主要包含两部分：

1 DoIP在整车网络中扮演的角色和工作过程

2 基于DoIP开发的诊断工具

1 DoIP在整车网络中扮演的角色和工作过程。

1.1 DoIP架构

如下图所示，作为车载以太网诊断的核心中间件，DoIP（Diagnostic over IP）本质上构建了UDS（ISO 14229）诊断服务与TCP/IP网络协议栈之间的桥梁。其核心任务是将应用层的UDS诊断报文封装为符合IP网络传输的数据包（封包），并在接收端反向解析出原始UDS指令（解包）。这一过程通过三级协议栈协同实现：

‌应用层‌：UDS服务单元（如0x22读数据、0x22读数据、0x31例行控制）以APDU（Application Protocol Data Unit）形式存在
‌DoIP适配层‌：添加DoIP报文头（Header）+ 地址扩展字段（Addressing），构成DoIP PDU
‌传输层‌：通过TCP（面向连接）或UDP（广播发现）协议承载，最终映射至以太网物理帧

1.2 DoIP 报文类型及格式

每个DoIP报文由 ‌协议头（Header）‌ 与 ‌有效载荷（Payload）‌ 构成，格式如下：

字节偏移	字段名	长度（Byte）	说明
0-1	Protocol Version	2	协议版本标识（0x01: DoIPv1, 0x02: DoIPv2），第2字节为取反值（0xFE~0xFF）
2~3	Payload Type	2	载荷类型编码（如0x8001: 诊断消息，0x0005: 路由激活响应）
4~7	Payload Length	4	载荷数据长度（单位：字节），大端序存储
8~9	Source Address	2	源地址，类比CAN上的诊断请求ID
10~11	Target Address	2	目标地址，类被CAN上的诊断响应ID
12~N	Payload Data	变长	实际传输内容（诊断场景下包含UDS报文）

DoIP载荷类型根据信息内容分组为：节点管理（ 0x0XXX）、车辆信息 0x4XXX）和
诊断（ 0x8XXX）。具体类型参考如下导图。

1.3 DoIP 节点类型

基于以太网的车载总线下，可以分成以下几个节点类型

Off-Board Tester‌

应用场景：工程开发/售后服务/产线检测
核心功能：通过DoIP协议实现外部设备与车载系统的诊断通信

‌On-Board Tester‌

应用场景：FOTA升级/远程诊断/近场诊断
核心功能：作为车载终端执行DoIP通信协议

‌DoIP Edge Node（边缘路由节点）‌

核心职责：作为协议转发枢纽
工作流程：接收->解析->路由来自客户端DoIP实体的诊断请求

‌DoIP In-Vehicle Node（车载处理节点）‌

核心职责：诊断请求终端处理器
通信链路：专责处理来自Edge Node的DoIP协议通信

‌Non-DoIP ETH Node（非协议适配节点）‌

技术特征：采用CAN/CANFD等传统总线协议
通信机制：通过网关实现协议转换（DoIP与传统总线间的报文转译）

该架构通过分层协议处理机制，实现了以太网诊断协议与传统车载总线的兼容协同，构建完整的车载诊断通信体系。网关节点在此架构中承担关键协议转换功能，确保异构网络间的有效通信。

1.4 DoIP 通信过程

DoIP中典型的建链过程参考如下图所示：

首先，整车启动以后，边缘节点作为TCP server端启动监听。相关的以太网节点将作为客户端链接到边缘节点

第二步，测试设备通过广播的方式获取整车上的DoIP节点信息

第三步，收到边缘节点发送的单播响应后，作为TCP Client链接到边缘节点。

第四步，向边缘节点发送路由激活请求。

第五步，边缘激活请求成功后即可发送诊断报文。

需要注意的是，边缘节点作为TCP Server端实际上是有两个Server在同时运行。其中一个Server面向外部Tester，另一个Server是面向内部DoIP节点。他们的IP是不同的。所以边缘节点起到了一个路由器的功能，这有助于车载网络和外部网络的隔离，保证网络安全。

2 基于DoIP开发的诊断工具

根据以太网DoIP相关的通信协议，开发了一款DoIP诊断工具上位机软件。通过这款软件可以获取以下收益：

1 不需要依赖昂贵的以太网调试设备，如Vector盒子，只需要低成本的以太网转换盒

2 能够在开发阶段快速实现诊断功能调试，不需要臃肿的CANoe环境

3 自定义测试序列，能够进行快速测试验证

4 自定义刷写，可以快速实现基于DOIP的软件刷写

总结就是低成本，高效开发，不被设备环境卡脖子！

2.1 硬件链接

这款软件不需要依赖Vector设备和CANoe，只需要如下一个RG45转100BaseT1的盒子即可实现大部分以太网相关节点的ECU开发的支持。当前如果你的ECU本来就是RG45,那就不需要这个盒子啦，或者也可以根据自己ECU特性找适配的转接设备。

2.2 软件概览

本软件支持作为Tester节点（ClientMode）的诊断功能和作为边缘节点的TcpServer（ServerMode）的诊断功能。软件通过JSON配置相关IP/PORT和目标地址以及关键的诊断相关时间参数具体参考如下示例

2.3 诊断功能

加载测试文件，连续执行诊断指令

如图所示，启动TCP server，DoIP节点上电后会自动链接到服务端。此时在ServerMode模式下不需要其他操作即可直接进行诊断通信。根据测试需要可以自定义一个测试文件报文起来，使用时直接加载文件，点击RUN，直接运行加载进来的指令。同时支持双击加载的指令实现单发功能。

在响应对话框，双击响应数据，既可以实现16进制和ASCII之间的相互转换

2 对话框直接输入诊断指令，单指令发送

2.4 刷写功能

需求方面分析，主要存在OEM的需求差异以及ECU本身的差异：

需求差异：Cybersecurity相关安全需求的差异，诊断流程的差异
文件格式多样性：S19/bin/Vbf等OEM私有格式的分级处理要求
传输协议特性：34/36/37服务中的Block结构及数据分片规则差异

‌设计方面，‌采用文件配置的方式，将刷写流程按照诊断指令的先后顺序预先定义在配置文件里。诊对不同的文件类型，统一按照bin文件输入，用户可以通过简单的脚本工具预先将文件转换成bin文件，从而解决36传输多个block的文件以及格式不统一的问题。具体效果可以参见下图。

关于文中提到的配置文件及格式，感兴趣可以联系使用。

1 DoIP在整车网络中扮演的角色和工作过程。

1.1 DoIP架构

1.2 DoIP 报文类型及格式

1.3 DoIP 节点类型

1.4 DoIP 通信过程

2 基于DoIP开发的诊断工具

2.1 硬件链接

2.2 软件概览

2.3 诊断功能

2.4 刷写功能

相关文章：