4、测试环境搭建：硬件在环(HIL)环境、虚拟节点模拟器、网络抓包工具配置、CANoe/CAPL脚本基础
好，咱们进入实战前的最后一步——搭环境。说实话，很多做DoIP压力测试的工程师，最后翻车都不是因为协议没搞懂，而是环境没搭对。我见过太多人花了两周写脚本，结果一跑就崩，最后发现是HIL台架的网络延迟没配好。嗯，咱们今天就把这事彻底理清楚。
4.1 硬件在环(HIL)环境搭建
HIL环境说白了，就是把真实的ECU接上测试系统。但DoIP测试有个特殊的地方——它走的是以太网，不是CAN。所以你的HIL台架必须支持100BASE-TX或1000BASE-T。
我个人习惯用Vector的VT系统搭配VN5610/VN5640接口卡。为什么？因为它的以太网口支持硬件时间戳，抓包精度能到纳秒级。你想想看，做压力测试时，如果时间戳不准，你根本分不清是ECU响应慢还是网络抖动。
- HIL实时系统（如dSPACE SCALEXIO或NI PXI）
- 以太网接口卡（Vector VN5610/VN5640或同级别）
- 可编程电源（控制ECU的12V/24V供电）
- 故障注入模块（模拟短路、断路、信号干扰）
接线时有个坑——DoIP要求使用独立的以太网段。千万别把ECU和HIL接到公司办公网络里。我在项目中遇到过，有同事图省事直接插交换机上，结果广播风暴把整个测试搞崩了。正确的做法是用一个单独的千兆交换机，只连ECU、HIL和抓包工具。
4.2 虚拟节点模拟器配置
有时候你手头没有那么多真实ECU，或者想模拟极端场景（比如100个节点同时发诊断请求），这时候就需要虚拟节点模拟器了。
我常用的是CANoe的虚拟节点功能，或者用Python自己写一个简单的DoIP模拟器。这里我推荐一个轻量级方案——用vDoIP库配合Scapy。
# 一个简单的DoIP虚拟节点示例
from vdoip import DoIPNode
import time
# 创建虚拟节点，逻辑地址0x0E80
node = DoIPNode(
logical_address=0x0E80,
vin="WDB1234567890ABCD",
eid=b'\x01\x02\x03\x04\x05\x06'
)
# 启动节点，监听UDP 13400端口
node.start()
# 模拟诊断响应
while True:
msg = node.receive(timeout=1)
if msg:
# 自动回复UDS诊断请求
node.auto_respond(msg)
time.sleep(0.01)
4.3 网络抓包工具配置
抓包是DoIP调试的命根子。没有抓包，你就是在盲人摸象。我个人只用Wireshark，配合Vector的硬件抓包卡。
配置要点：
- 过滤规则：直接写
udp.port == 13400 || tcp.port == 13400 - 时间戳精度：必须开启微秒级显示（Wireshark里设置View -> Time Display Format -> Seconds Since Epoch with microseconds）
- Follow TCP Stream：这个功能太重要了，能直接看到DoIP消息的完整交互过程
我曾经遇到一个诡异的问题——ECU偶尔不响应路由激活请求。抓包后发现，原来是ECU的TCP窗口大小设置太小，导致数据包被分片了。这种问题，你不抓包根本想不到。
4.4 CANoe/CAPL脚本基础
CANoe是DoIP测试的瑞士军刀。但很多人一上来就写CAPL，结果写得一塌糊涂。我建议你先理解CAPL的核心机制——事件驱动。
说白了，CAPL脚本就是一堆事件处理函数。当某个事件发生（比如收到DoIP消息、定时器到期），对应的函数就会被调用。你不需要写主循环，系统帮你调度。
// 一个简单的DoIP压力测试CAPL脚本框架
variables
{
// 定义全局变量
dword gSendCount = 0;
dword gRecvCount = 0;
msTimer gTimer;
}
on start
{
// 初始化
write("DoIP压力测试开始");
setTimer(gTimer, 100); // 每100ms发送一次请求
}
on timer gTimer
{
// 发送诊断请求
DoIP_SendRequest(0x0E80, 0x22, 0xF1, 0x90);
gSendCount++;
setTimer(gTimer, 100);
}
on DoIPResponse
{
// 收到响应
gRecvCount++;
write("收到响应，序号: %d", gRecvCount);
// 检查响应时间
if (this.RespTime > 50)
{
write("警告: 响应超时! 耗时: %d ms", this.RespTime);
}
}
on start- 脚本启动时执行，适合做初始化on timer- 定时器事件，控制发送节奏on DoIPResponse- 收到DoIP响应时触发
写CAPL脚本时有个小技巧——多用 write() 函数打印日志。我刚开始做压力测试时，脚本跑了一整夜，第二天一看全崩了，但不知道崩在哪。后来我养成了习惯，每个关键步骤都加日志输出，定位问题快多了。
4.5 环境验证清单
环境搭好后，别急着跑压力测试。先做一轮基础验证：
| 验证项 | 预期结果 | 检查方法 |
|---|---|---|
| DoIP车辆发现 | 能收到VIN和逻辑地址 | Wireshark过滤udp.port==13400 |
| TCP连接建立 | 三次握手成功 | Follow TCP Stream查看 |
| 路由激活 | 收到0x0004响应 | CAPL日志检查 |
| 诊断请求/响应 | UDS响应正常 | 手动发送0x22 0xF1 0x90 |
嗯，环境搭建这部分就这些。说白了，HIL、虚拟节点、抓包、CAPL这四样东西，你只要配好了，后面写压力测试脚本就是水到渠成的事。下一章咱们就开始真正搞压力测试了——并发请求、负载控制、结果分析，那才是真正刺激的部分。