4. 域控系统测试环境搭建

域控系统的测试环境不是单一平台，而是一组按“被测对象真实度”和“信号闭环程度”排列的验证阶梯。理解这条阶梯，比记住某台设备的型号更重要：越靠左，真实度越低、可控性越高、迭代越快；越靠右，真实度越高、复现越难、成本越大。工程上通常让同一份测试用例在不同层级上复用，先在最可控的环境里把逻辑跑通，再逐步把真实传感器、真实网络和真实电源引入，最终在实车上确认系统级行为。

台架：先把“电”和“通信”跑通

台架是最基础的一层，目标不是验证算法，而是确认域控能正常上电、启动、通信和驱动负载。典型台架由域控、程控电源、CAN/CAN FD 或以太网通信卡、可编程负载和调试接口组成。搭建时先确认供电电压与上电时序：例如按 12V 系统设定 9V～16V 工作范围，冷启动最低可到 6V，并设置上电斜率与掉电保持时间。上电后通过诊断接口读取版本与故障码，确认无欠压、过压、看门狗复位等异常。

通信部分要先把物理层和链路层打通。以 CAN 为例，用 500kbps 波特率、120Ω 终端电阻，通过 candump 观察报文是否按周期发出。若域控不发报文，先查终端电阻、线序和收发器供电，再查应用是否进入正常运行状态。台架阶段还应做一次电源扰动测试：在 9V、12V、16V 三个点各保持 30 秒，观察域控是否复位、通信是否中断，并记录电流曲线。这一步能提前暴露电源设计余量不足的问题。

HIL：把车辆模型接进闭环

HIL 的核心是实时机运行车辆模型，通过 IO 板卡与域控交换真实电信号和总线信号。搭建 HIL 时，第一件事是确定 IO 映射表：域控的每一路输入输出，对应实时机的哪个通道、什么电气类型、什么量程。例如轮速信号用频率输出，范围 0～2kHz；制动踏板用模拟量 0～5V；档位用数字 IO。映射表一旦确定，就要做通道自检，确认输出与采集一致。

第二件事是总线仿真。实时机需要模拟整车 CAN 上的其他节点，如 VCU、EPS、ESC，按 DBC 定义周期发送报文。域控发出的控制报文由实时机接收并送入车辆模型，形成闭环。这里最容易出问题的是总线负载和报文周期：如果仿真节点过多、周期过密，总线负载可能超过 60%，导致报文延迟甚至丢失。建议先用 CANoe 或类似工具统计负载，再逐步增加节点。

第三件事是故障注入。HIL 的价值之一是可重复地制造故障：断开某路传感器、注入错误校验、模拟总线短路、拉低电源电压。每次注入都要有明确的预期结果和判定条件，例如“断开左前轮速后 200ms 内域控应报出对应 DTC，并进入降级模式”。没有判定条件的故障注入只是制造混乱，不是测试。

传感器仿真：让感知层“看见”场景

传感器仿真解决的是感知输入问题。摄像头通常用视频注入卡，把预录或合成的视频按域控要求的格式和时序送入；激光雷达用点云回放，把录制的点云按帧和时间戳重放；毫米波雷达用目标模拟器，按距离、速度、角度生成回波。三者共同的关键是时间同步：所有传感器数据必须带统一时间基准，通常用 PTP 或 gPTP，否则融合算法会因时间偏差产生错误关联。

搭建时先做单传感器验证：注入一段已知场景，确认域控能正确识别目标数量和位置。再做多传感器联合验证：让摄像头、激光雷达、毫米波雷达对同一目标给出各自输出，检查融合结果是否一致。若不一致，先查时间戳对齐，再查外参标定。传感器仿真的场景库应覆盖典型工况：前车切入、行人横穿、隧道进出、强光逆光、雨雾衰减。每个场景都要有明确的通过判据，例如“目标检出率不低于 95%，误检率不高于 1%”。

网络与电源模拟：把“恶劣条件”变成可重复输入

网络模拟用网络损伤仪制造延迟、抖动、丢包和带宽限制。例如把以太网延迟设为 5ms、抖动 2ms、丢包 0.1%，观察域控的通信超时和降级逻辑。电源模拟用程控电源制造电压跌落、浪涌和反向电压，验证域控在 ISO 16750-2 类工况下的生存能力。这两类模拟的共同点是：把现实中偶发、难以复现的恶劣条件，变成可精确设定、可重复施加的输入。

环境搭建实战任务

下面给出一个可执行的搭建任务示例，目标是在 HIL 上完成一次“前车切入”场景的闭环验证。任务分为准备、搭建、验证三个阶段，每阶段都有明确的交付物和判定条件。

完成上述任务后，应形成一份可复用的环境配置基线：电源参数、总线配置、IO 映射、传感器注入参数、场景库版本、判定阈值。这份基线是后续所有测试的起点，也是问题复现和结果对比的依据。环境搭建的价值不在于设备堆叠，而在于让每一次测试都建立在可重复、可解释、可追溯的输入之上。