注：阅读本文需要对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的文件以及格式不统一的问题。具体效果可以参见下图。
关于文中提到的配置文件及格式，感兴趣可以联系使用。