DoIP（Diagnostic over IP）路由激活与诊断请求

路由激活

一、参与方角色与背景

图中涉及三个核心实体，是DoIP诊断通信场景中的典型组件：

• DoIP entity：DoIP协议栈的核心处理模块，负责socket管理、报文解析、路由激活等核心逻辑，运行在车载诊断网关或测试设备中。
• External test equipment：外部测试设备（如诊断仪、自动化测试台架），发起连接、发送诊断请求，是通信的“请求方”。
• Actor：人机交互角色（如测试工程师），负责选择车辆等操作决策，是测试流程的“执行者”。

核心配置参数

参数名	作用	通俗解释	典型值/场景
EID (Entity ID)	车辆身份标识	选“自动读MAC地址”（像身份证号）或“自定义名字”（如“EngineECU”）	自动读取：00:1A:2B:3C:4D:5E 自定义：EngineController
GID (Group ID)	车辆分组标识	给车辆打标签，比如“发动机组”或“刹车组”	例：0x01（发动机组）、0x02（刹车组）
Logical Address	通信身份证	用于区分不同ECU的“门牌号”（不是IP地址！）	例：0x01（发动机ECU）、0x02（刹车ECU）
Max Request Bytes	数据包大小限制	最大能传多大的诊断数据（像快递箱尺寸）	例：65536字节（64KB）
Max Initial Vehicle Announcement Time	车辆“报到”等待时间	车辆启动后，最多等多久才广播自己（避免卡住）	例：5000ms（5秒）
Max Tester Connections	最大同时连接数	车辆能同时接几个测试设备（像餐厅座位数）	例：3（最多3台诊断仪同时连）
Communication Connector	网络连接选择	选“用哪个网口”（比如车载以太网口1）	例：Ethernet0
IPv4 Multicast IP Address	车辆广播地址	车辆发“我在这里”广播的地址（像小区广播喇叭）	例：224.0.0.251（DoIP标准地址）
TCP Port / UDP Port	通信“门铃号码”	用哪个端口收发数据（TCP=可靠连接，UDP=快速广播）	TCP: 13400 UDP: 13400

💡 关键提示：

• Logical Address 是核心！测试设备必须用这个“门牌号”才能找到具体ECU。
• Max Tester Connections 限制了同时能连的测试设备数，避免车辆过载。

路由激活流程（3步搞定，拒绝卡顿）

当测试设备（如诊断仪）想和车辆通信时，DoIP实体（车辆的通信大脑）会这样处理：

1. 第一步：检查“身份证”（Source Address）

   • 测试设备发请求时，会带自己的“身份证号”（SA，比如0x01）。
   • DoIP实体对比：
     ✅ 如果和上次成功连接的SA一样 → 直接说：“欢迎回来，通道已开！”
     ❌ 如果SA不同（比如新设备）→ 说：“身份证不对，拒绝连接！”

   （防止黑客冒充设备入侵）

2. 第二步：检查“座位”是否满了

   • 如果当前连接数已达上限（比如Max Tester Connections=3）：
     • ✅ 如果所有座位都坐满了（所有连接都在用）→ 说：“抱歉，没空位了！”
     • ❌ 如果有人没用（比如闲置10分钟） → 说：“让那个不活跃的设备先走，腾个位置给你！”

   （动态释放资源，避免“死锁”）

3. 第三步：成功建立通道

   • 通过以上检查后，DoIP实体：
     • 用操作系统给的“钥匙”（FD）启动一个新线程
     • 建立专属TCP通道（TCP_DATA socket）
     • 对测试设备说：“通道已激活，可以发诊断请求了！”

二、交互步骤详解（按时间顺序）

整个流程围绕“路由激活（Routing Activation）”展开，是DoIP通信建立诊断通道的关键步骤，具体步骤如下：

1. 初始准备：连接与车辆发现

流程开始前，需完成网络/直连环境下的连接建立和车辆识别（例如通过广播发现、VIN码识别等），为后续通信奠定基础。

2. 车辆选择与TCP连接建立

• Add vehicle to list： External test equipment将发现的车辆信息（如VIN、IP地址）添加到设备列表中，便于后续选择。
• Select vehicle： Actor（测试工程师）从列表中选择目标车辆，触发后续针对该车辆的通信流程。
• Open TCP DATA socket： External test equipment作为“客户端”，主动向DoIP entity发起TCP连接（建立TCP DATA socket，用于传输诊断数据）。

3. DoIP entity初始化socket

• Initialize TCP_DATA socket： DoIP entity接收到TCP连接请求后，利用操作系统返回的文件描述符（FD）启动线程，完成TCP_DATA socket的初始化（如绑定IP/端口、设置参数等）。

4. 路由激活请求发送

• Routing activation request： External test equipment通过已建立的TCP连接，向DoIP entity发送“路由激活请求”报文（DoIP协议中，路由激活是诊断通信的前置条件，用于申请诊断权限）。

5. DoIP entity处理路由激活

DoIP entity接收到路由激活请求后，需经过两层逻辑处理：

• Generic DoIP header handler： 通用DoIP报文头解析模块先校验报文格式（如DoIP协议版本、消息类型、长度等），确保报文合规。
• Routing activation handler: Register TCP_DATA socket： 路由激活专用处理模块：
  • 校验请求中的源地址（Source Address, SA）：若当前请求的SA与“上一条成功激活的SA”相同，则返回“激活成功”；若不同，返回“激活失败”（防止非法设备盗用诊断通道）。
  • 将当前TCP_DATA socket与“诊断通道”绑定注册，后续诊断报文将通过该socket传输。

6. 车辆识别响应与连接状态通知

• Vehicle identification response： DoIP entity处理完路由激活后，返回“车辆识别响应”报文（包含车辆识别结果、诊断会话权限等信息），通知External test equipment“路由激活结果”及“车辆诊断就绪状态”。
• Indicate successful connection： External test equipment收到响应后，向Actor反馈“连接成功”（如UI界面显示“已连接目标车辆”），标志着诊断通道正式建立。

7. （隐含逻辑）连接数限制与资源管理

当DoIP entity的当前连接数（socket数）达到最大值时：

• 若所有已有连接均处于“active（活跃）状态”（即正在传输诊断数据），则新请求的路由激活返回失败。
• 若存在“非活跃连接”（如空闲超时、未释放资源），则强制断开非活跃连接，为当前新连接释放资源，使新连接“激活成功”。

三、核心逻辑总结

整个流程的核心是 “路由激活” —— 通过严格的源地址校验和连接资源管理，确保只有合法设备能建立诊断通道；同时，TCP连接的建立、socket初始化、响应通知等步骤，共同构成了DoIP诊断通信的“通道准备”流程，为后续的ECU诊断报文传输奠定基础。

简言之，图中通过时序化交互，清晰展示了DoIP诊断中“从连接建立到路由激活再到通道就绪”的完整流程，重点突出了协议栈的**安全校验（SA检查）与资源管理（连接数限制）**逻辑，是理解DoIP通信机制的关键入口。

诊断请求

1. 参与方角色解析

• DoIP entity：处理 Diagnostic over IP（DoIP） 协议的实体（如车辆端/测试设备端的 DoIP 协议栈模块，负责诊断消息的封装、解析与传输）。
• External test equipment：外部测试设备（如诊断工具、自动化测试平台），发起诊断请求或接收响应。
• Actor：最终执行动作或发起请求的“行为主体”（如测试工程师、上层应用逻辑）。

2. 消息交互流程拆解（按时间顺序）

流程围绕 “Loop diagnostic session（循环诊断会话）” 展开，包含请求-响应和会话结束两个阶段：

阶段一：循环诊断会话（Loop diagnostic session）

1. 请求发起：

   • External test equipment 向 Actor 发送 Request（如测试工程师通过测试设备触发诊断请求）。

2. Actor 内部处理 & 确认响应：

   • Actor 内部的 Generic DoIP header handler（通用 DoIP 头处理器）和 DoIP diagnostic message handler（DoIP 诊断消息处理器）依次处理请求。
   • 处理完成后，向 External test equipment 返回 DoIP diagnostic response (confirmation acknowledge)（DoIP 诊断响应，用于确认请求已接收/处理）。

3. 诊断请求传输：

   • 左侧 DoIP entity 向右侧 DoIP entity 发送 Diagnostic request（诊断请求，如车辆端向测试设备请求诊断数据）。

4. 诊断响应传输（双向）：

   • 右侧 DoIP entity 处理请求后，向左侧 DoIP entity 返回 Diagnostic response（诊断响应，如测试设备返回诊断结果）。
   • 左侧 DoIP entity 将响应传递给 External test equipment（测试设备接收诊断结果）。

5. 最终响应传递：

   • External test equipment 向 Actor 发送 Response（如测试设备将诊断结果返回给测试工程师）。

阶段二：会话结束（Log off & 关闭连接）

1. 会话结束请求：

   • External test equipment 发送 Log off（会话结束请求）。

2. 连接关闭与释放：

   • External test equipment 与 DoIP entity 之间关闭 TCP_DATA socket（传输层的诊断数据通道）。
   • DoIP entity 执行 Finalize TCP_DATA socket（释放 socket 资源，完成连接清理）。

3. 核心逻辑总结

这张时序图展示了 DoIP 协议下诊断消息的端到端流转：从外部测试设备发起请求，经执行器处理、DoIP 实体间传输，再到响应返回与会话关闭。流程体现了 “请求→处理→确认→传输→响应→结束” 的完整诊断链路，是汽车电子/嵌入式领域中 诊断协议（DoIP）测试/通信 的典型场景。