1. 项目缘起与整体设计思路拆解高阶智驾的域控制器和传感器套件跟传统ECU完全不是一个量级的东西。传统ECU的HiL核心就是CAN/LIN总线上跑信号I/O板卡模拟几个开关和模拟量台架规模小、实时性要求也没那么苛刻。但到了高阶智驾一个域控可能同时挂着好几路摄像头、多颗激光雷达、毫米波雷达还有组合导航和V2X模块数据吞吐量直接飙到Gbps级别时间同步精度要求进入微秒甚至纳秒级。这种场景下市面上买一套标准化的HiL台架基本不可能直接满足需求定制化开发几乎是唯一出路。我做的这个项目目标就是为一套高阶智驾域控制器搭建一套定制化的硬件在环测试系统。说人话就是把真实的域控制器硬件放在台架上用仿真环境给它喂各种传感器数据、车辆状态和场景信息让它在实验室里就能跑完各种极端工况不用真车上路。这套系统要解决的核心问题有三个第一传感器数据注入的实时性和同步性第二车辆动力学和场景仿真的闭环精度第三整套系统的可扩展性和自动化测试能力。为什么选择定制化而不是买成品我当时的判断逻辑是这样的成品HiL台架在通用性上做得好但高阶智驾的传感器接口协议五花八门有GMSL、FPD-Link、以太网、CAN FD甚至还有私有的高速串行协议。成品台架的接口板卡往往只覆盖主流协议遇到非标接口就得加转接模块一转接就引入延迟和不确定性。而且成品台架的软件架构通常是封闭的想深度定制测试场景和自动化流程要么加钱买license要么根本改不了。定制化虽然前期投入大但后期灵活性和可维护性完全不是一个级别。整体架构上我把系统分成四层实时仿真层、传感器数据注入层、车辆动力学与场景层、测试管理与自动化层。实时仿真层跑在实时操作系统上负责车辆模型和传感器物理模型的解算传感器数据注入层负责把仿真出来的数据转换成域控能识别的物理信号车辆动力学与场景层负责生成测试场景和车辆运动状态测试管理与自动化层负责用例管理、执行和报告生成。这四层之间通过高速以太网和反射内存网做数据交换确保整个闭环的延迟控制在毫秒级以内。注意定制化HiL台架最怕的就是“过度设计”。我见过不少团队一上来就想把所有传感器都做真值注入结果预算和时间全砸在硬件上软件和场景反而没做好。我的建议是先明确测试需求优先级把80%的测试场景用20%的硬件资源覆盖掉剩下的再逐步扩展。2. 核心硬件选型与实时性保障2.1 实时仿真平台的选择逻辑实时仿真平台是整个台架的心脏。市面上主流的选择有dSPACE、Speedgoat、NI的PXI系列还有基于RT-Linux自研的方案。我最终选的是Speedgoat的实时目标机搭配Simulink Real-Time做开发。原因有几个第一Speedgoat的I/O模块种类够多CAN FD、以太网、模拟量、数字量都有现成板卡省去了大量底层驱动开发第二Simulink生态成熟车辆动力学模型和传感器模型可以直接从MATLAB/Simulink里生成代码部署开发效率高第三实时性有保障最小步长可以做到50微秒对于大多数智驾场景足够用了。但这里有个坑Speedgoat的以太网板卡虽然支持TSN但配置起来并不简单。我一开始想用标准以太网做传感器数据注入结果发现域控对数据包的到达时间非常敏感普通以太网的抖动根本满足不了要求。后来改用TSN交换机做时间敏感网络配置才把抖动压到了可接受范围。TSN的配置涉及时间同步、流量整形、门控调度等一系列参数我后面会单独讲。2.2 传感器数据注入的硬件方案传感器注入是定制化HiL里最麻烦的部分。摄像头、激光雷达、毫米波雷达的接口和协议完全不同需要分别处理。摄像头注入我选的是基于FPGA的GMSL视频注入板卡。为什么用FPGA因为摄像头数据流是高速串行的而且域控对视频流的帧同步和时序有严格要求。FPGA可以精确控制每一帧的发送时刻还能在视频流里嵌入时间戳和同步信号。具体做法是仿真环境生成原始图像数据通过PCIe传到FPGA板卡FPGA按照GMSL协议打包成串行流再通过同轴电缆送给域控。这里的关键参数是像素时钟和行场同步信号的时序必须和真实摄像头模组完全一致否则域控可能识别不到或者图像错位。激光雷达注入我用的是以太网方案。大多数车载激光雷达输出的是UDP包里面包含点云数据和时间戳。仿真环境生成点云后通过TSN以太网直接发给域控。这里要注意的是点云的坐标系和强度值必须和真实雷达一致否则感知算法会出问题。我踩过的坑是仿真点云的密度和真实雷达差异太大导致感知模型在台架上表现很好一上实车就崩。后来我在点云生成环节加了噪声模型和衰减模型尽量逼近真实雷达的输出特性。毫米波雷达注入相对简单因为很多雷达输出的是CAN FD或者以太网的目标级数据。我用的是CAN FD板卡模拟雷达目标列表把仿真出来的目标距离、速度、角度按照雷达的协议格式打包发送。但要注意雷达的探测周期和域控的接收周期要匹配否则会出现数据堆积或者丢帧。2.3 时间同步与实时性保障时间同步是整套系统的生命线。域控内部对各个传感器数据的时间戳有严格的对齐要求如果注入的数据时间戳乱了感知融合直接失效。我的方案是用PTP精确时间协议做全网时间同步主时钟放在实时仿真机上所有注入板卡和域控都作为从时钟。PTP的同步精度可以做到亚微秒级对于大多数智驾场景够用了。但PTP配置有几个关键点第一交换机必须支持PTP透明时钟否则交换机的排队延迟会破坏同步精度第二所有节点的PTP报文优先级要设到最高避免被其他流量挤占第三域控的PTP从时钟配置要和主时钟的域号、报文类型匹配否则根本同步不上。我调试PTP花了整整一周最后发现是交换机的PTP配置里domain number设错了这种细节问题最容易让人抓狂。实操心得时间同步调试时先用示波器测PTP的秒脉冲信号确认硬件层面同步上了再去查软件配置。如果秒脉冲都对不齐软件怎么调都没用。3. 车辆动力学模型与场景仿真实现3.1 车辆动力学模型的搭建与标定车辆动力学模型是HiL台架的“灵魂”。模型不准域控在台架上跑得再好上实车也是白搭。我用的是一套15自由度的车辆模型包含车身6自由度、四个车轮的旋转和垂向运动、以及转向系统和制动系统的动态特性。模型在Simulink里搭建然后生成C代码部署到实时目标机上。模型标定是个体力活。我拿实车采集的数据做参数辨识主要标定这几个参数轮胎的侧偏刚度和纵滑刚度、悬架的刚度和阻尼、转向系统的传动比和延迟、制动系统的压力-力矩特性。标定方法用的是最小二乘法把实车数据和模型输出做拟合迭代调整参数直到误差在可接受范围内。这里要注意的是轮胎模型对温度 and 路面条件很敏感我建议至少标定干沥青和湿滑路面两种工况否则模型在极端场景下会失真。模型验证我做了三组测试双移线、正弦扫频、紧急制动。双移线看的是横摆角速度和侧向加速度的跟随精度正弦扫频看的是频率响应特性紧急制动看的是纵向减速度和滑移率的匹配度。实测下来横摆角速度的峰值误差控制在5%以内侧向加速度误差在8%以内对于HiL测试来说够用了。3.2 场景仿真与传感器物理模型场景仿真我用的是CarMaker和Simulink联合仿真。CarMaker负责生成道路、交通车、行人等场景元素Simulink负责车辆动力学和传感器模型。两者通过TCP/IP做数据交换步长设为1毫秒。为什么不用CarMaker自带的车辆模型因为CarMaker的车辆模型是黑盒没法深度定制而我的测试需求里有很多非标准工况必须自己搭模型。传感器物理模型是场景仿真里的难点。摄像头模型要模拟镜头畸变、曝光、运动模糊、天气影响激光雷达模型要模拟光束发散、反射率、雨雾衰减毫米波雷达模型要模拟多径效应、杂波、遮挡。这些模型不需要做到物理级精确但至少要能复现真实传感器的典型失效模式。比如摄像头在逆光下的过曝、激光雷达在雨天的点云稀疏、毫米波雷达在隧道里的多径虚假目标这些场景如果模型里没有域控的鲁棒性就测不出来。我踩过的一个大坑是场景仿真里的交通车行为太“规矩”了永远保持安全距离、永远不突然变道。结果域控在台架上跑了几万公里都没触发过紧急避障一上实车就遇到加塞直接懵了。后来我在场景里加了“激进驾驶员”模型随机生成急刹、加塞、鬼探头等行为才把域控的边界场景测出来。3.3 场景库的建设与管理场景库是HiL台架的长期资产。我按照功能、场景、工况三个维度来组织场景库。功能维度包括自适应巡航、车道保持、自动变道、紧急避障等场景维度包括高速公路、城市道路、乡村道路、停车场等工况维度包括白天、夜间、雨天、雾天、雪天等。每个场景用XML描述包含道路几何、交通参与者、环境条件、初始状态等参数。场景库的管理我用的是Git做版本控制每个场景文件都有唯一的ID和版本号。测试用例通过ID引用场景这样场景更新后所有引用它的测试用例自动使用新版本。这里要注意的是场景变更必须做回归测试否则可能出现“修好一个场景弄坏十个用例”的情况。我建议每次场景库更新后至少跑一遍冒烟测试集确认核心功能没受影响。4. 测试管理与自动化执行4.1 测试用例的设计与组织测试用例的设计直接决定了HiL台架的产出效率。我的做法是把测试用例分成三层——功能层、场景层、边界层。功能层验证单个功能是否正常比如自适应巡航的跟车距离控制场景层验证多个功能在复杂场景下的协同比如自动变道时遇到后车加速边界层验证系统在极端条件下的表现比如传感器失效、通信丢包、电源波动。每层用例的通过标准不同。功能层要求100%通过场景层允许有已知的边界情况边界层主要看系统是否能安全降级。用例用Python脚本编写通过测试管理平台调用。脚本里定义测试步骤、注入信号、采集输出、判断结果。这里的关键是断言的设计不能只看最终输出还要看中间状态。比如紧急避障测试不能只看车有没有停下来还要看制动压力建立的斜率、转向角的变化率、以及域控内部的状态机跳转。4.2 自动化测试执行与报告生成自动化执行我用的是Jenkins做调度每天晚上跑全量回归白天跑冒烟测试。测试结果自动上传到数据库生成HTML报告。报告里包含每个用例的通过状态、执行时间、关键波形截图、以及失败原因分析。失败用例会自动截取故障前后的数据方便快速定位问题。这里有个经验自动化测试最怕“假通过”。我遇到过好几次用例显示通过但实际上是域控根本没响应测试脚本误判为通过。后来我在断言里加了“心跳检测”如果域控在指定时间内没有发出预期的报文直接判定为失败。另外测试环境的稳定性也很重要我建议每天开始测试前先跑一遍自检脚本确认所有板卡、电源、通信链路都正常。4.3 持续集成与回归测试策略持续集成是保证台架长期可用的关键。我的做法是代码提交到Git后自动触发编译和单元测试单元测试通过后自动部署到HiL台架跑冒烟测试冒烟测试通过后才允许合并到主分支。每天晚上跑全量回归第二天早上出报告。如果回归测试发现新增失败用例自动发邮件通知相关责任人。回归测试的策略是“全量增量”。全量回归覆盖所有核心用例增量回归只跑受代码变更影响的用例。怎么判断哪些用例受影响我用的方法是代码变更文件关联到功能模块功能模块关联到测试用例。比如改了AEB的触发逻辑就自动跑所有AEB相关的用例。这样既保证了覆盖率又控制了测试时间。常见问题回归测试跑久了用例会越来越多执行时间越来越长。我的解决办法是定期做用例精简把重复覆盖的用例合并把长期稳定的用例降频执行。比如核心功能用例每天跑边界用例每周跑一次。5. 常见问题与排查技巧实录5.1 传感器注入失败的典型原因传感器注入失败是HiL台架调试中最常见的问题。我整理了一个排查表按现象、可能原因、排查方法三个维度来组织。现象可能原因排查方法域控识别不到摄像头GMSL时序不对、同轴电缆阻抗不匹配用示波器测GMSL差分信号的眼图确认时序和幅度激光雷达点云错位坐标系定义不一致、时间戳偏移对比仿真点云和真实点云的坐标系检查PTP同步状态毫米波雷达目标丢失CAN FD波特率不匹配、报文ID错误用CAN分析仪抓包确认波特率和报文格式所有传感器数据延迟大TSN配置错误、交换机拥塞检查TSN门控调度表确认关键流量优先级最高时间戳跳变PTP主时钟不稳定、网络抖动用PTP监控工具查看时钟偏移检查网络负载这张表是我踩了无数坑之后总结出来的基本上覆盖了80%的注入问题。剩下的20%往往是硬件故障或者协议实现差异需要具体问题具体分析。5.2 车辆模型失真的排查思路车辆模型失真表现为台架测试结果和实车测试结果差异大。排查思路是“先静态后动态先单点后全局”。静态测试包括方向盘转角到前轮转角的传动比、制动踏板到制动压力的映射、油门踏板到驱动扭矩的映射。这些静态特性如果不对动态测试根本没法做。动态测试包括阶跃响应、正弦扫频、双移线。阶跃响应看的是响应时间和超调量正弦扫频看的是幅频和相频特性双移线看的是横摆角速度和侧向加速度的跟随精度。如果动态测试发现模型失真优先检查轮胎模型和悬架模型这两个是影响最大的。我遇到过一次模型失真排查了两天才发现是轮胎的侧偏刚度标定错了。原因是实车采集数据时轮胎温度没控制好导致辨识出来的刚度偏高。后来我在标定流程里加了轮胎温度监控确保每次标定都在相同温度下进行。5.3 自动化测试的稳定性保障自动化测试的稳定性是个系统工程。我的经验是硬件稳定性占50%软件健壮性占30%环境一致性占20%。硬件稳定性包括板卡固定牢靠、线束连接可靠、电源稳定、散热良好。我见过太多因为线束松动导致测试随机失败的案例所以现在所有线束都用扎带固定关键连接点用螺纹锁固胶。软件健壮性包括异常处理、超时重试、日志记录。测试脚本里必须加超时机制任何一步操作超过预期时间就判定失败并记录现场。日志要详细到每一步的信号值和状态方便事后分析。环境一致性包括温度、湿度、供电电压、电磁干扰。我建议台架放在恒温恒湿的实验室里供电加稳压器关键信号线加屏蔽。避坑技巧自动化测试跑通之后先连续跑72小时稳定性测试。如果72小时内没有随机失败基本可以认为系统稳定了。如果有随机失败一定要找到根因不要用重试来掩盖问题。6. 定制化HiL台架的扩展与演进6.1 从单域控到多域控的扩展高阶智驾的电子电气架构正在从单域控向多域控演进中央计算区域控制的架构越来越普遍。这意味着HiL台架也要支持多域控联合测试。我的扩展方案是在现有台架基础上增加一个“域控间通信仿真层”模拟域控之间的以太网、CAN FD通信。每个域控有独立的传感器注入通道但共享同一个车辆动力学模型和场景。多域控测试的难点是时间同步和任务调度。多个域控之间的通信有严格的时序要求如果仿真层不能精确控制报文发送时刻域控间的协同就会出问题。我的做法是用TSN交换机做域控间通信所有报文打上硬件时间戳仿真层根据时间戳调度发送。这样可以把域控间通信的抖动控制在微秒级。6.2 云仿真与HiL的协同云仿真和HiL不是替代关系而是互补关系。云仿真适合跑海量场景的快速迭代HiL适合跑关键场景的精确验证。我的做法是在云仿真平台上跑大规模场景筛选把可疑场景和边界场景导出然后在HiL台架上做精确复现和深度分析。这样既保证了测试覆盖率又保证了关键场景的测试精度。云仿真和HiL的数据接口我用的是OpenSCENARIO和OpenDRIVE标准格式。云仿真平台导出场景文件HiL台架导入后自动生成测试用例。测试结果再回传到云平台做统一管理和分析。这套流程跑通之后场景从发现到验证的周期从原来的两周缩短到了两天。6.3 数据闭环与持续迭代HiL台架产生的测试数据是宝贵的资产。我把这些数据分成三类通过用例的数据、失败用例的数据、边界用例的数据。通过用例的数据用来做回归基线失败用例的数据用来做问题定位边界用例的数据用来做模型优化。数据闭环的核心是“测试-分析-优化-再测试”。每次发现失败用例先分析根因如果是模型问题就优化模型如果是域控问题就反馈给域控开发团队如果是测试用例问题就修正用例。优化之后重新跑测试确认问题解决且没有引入新问题。这个闭环跑得越快台架的价值就越大。我个人的体会是定制化HiL台架不是一次性投入而是一个持续演进的过程。硬件会过时软件会迭代场景会更新只有建立起一套可持续的开发和维护流程台架才能长期发挥价值。最后分享一个小技巧台架的每个模块都要有详细的文档和版本记录包括硬件配置、软件版本、标定参数、已知问题。这样即使人员变动接手的人也能快速上手不至于从头再来。 高阶智驾域控制器定制化HiL台架：硬件选型、时间同步与自动化测试实践
1. 项目缘起与整体设计思路拆解高阶智驾的域控制器和传感器套件跟传统ECU完全不是一个量级的东西。传统ECU的HiL核心就是CAN/LIN总线上跑信号I/O板卡模拟几个开关和模拟量台架规模小、实时性要求也没那么苛刻。但到了高阶智驾一个域控可能同时挂着好几路摄像头、多颗激光雷达、毫米波雷达还有组合导航和V2X模块数据吞吐量直接飙到Gbps级别时间同步精度要求进入微秒甚至纳秒级。这种场景下市面上买一套标准化的HiL台架基本不可能直接满足需求定制化开发几乎是唯一出路。我做的这个项目目标就是为一套高阶智驾域控制器搭建一套定制化的硬件在环测试系统。说人话就是把真实的域控制器硬件放在台架上用仿真环境给它喂各种传感器数据、车辆状态和场景信息让它在实验室里就能跑完各种极端工况不用真车上路。这套系统要解决的核心问题有三个第一传感器数据注入的实时性和同步性第二车辆动力学和场景仿真的闭环精度第三整套系统的可扩展性和自动化测试能力。为什么选择定制化而不是买成品我当时的判断逻辑是这样的成品HiL台架在通用性上做得好但高阶智驾的传感器接口协议五花八门有GMSL、FPD-Link、以太网、CAN FD甚至还有私有的高速串行协议。成品台架的接口板卡往往只覆盖主流协议遇到非标接口就得加转接模块一转接就引入延迟和不确定性。而且成品台架的软件架构通常是封闭的想深度定制测试场景和自动化流程要么加钱买license要么根本改不了。定制化虽然前期投入大但后期灵活性和可维护性完全不是一个级别。整体架构上我把系统分成四层实时仿真层、传感器数据注入层、车辆动力学与场景层、测试管理与自动化层。实时仿真层跑在实时操作系统上负责车辆模型和传感器物理模型的解算传感器数据注入层负责把仿真出来的数据转换成域控能识别的物理信号车辆动力学与场景层负责生成测试场景和车辆运动状态测试管理与自动化层负责用例管理、执行和报告生成。这四层之间通过高速以太网和反射内存网做数据交换确保整个闭环的延迟控制在毫秒级以内。注意定制化HiL台架最怕的就是“过度设计”。我见过不少团队一上来就想把所有传感器都做真值注入结果预算和时间全砸在硬件上软件和场景反而没做好。我的建议是先明确测试需求优先级把80%的测试场景用20%的硬件资源覆盖掉剩下的再逐步扩展。2. 核心硬件选型与实时性保障2.1 实时仿真平台的选择逻辑实时仿真平台是整个台架的心脏。市面上主流的选择有dSPACE、Speedgoat、NI的PXI系列还有基于RT-Linux自研的方案。我最终选的是Speedgoat的实时目标机搭配Simulink Real-Time做开发。原因有几个第一Speedgoat的I/O模块种类够多CAN FD、以太网、模拟量、数字量都有现成板卡省去了大量底层驱动开发第二Simulink生态成熟车辆动力学模型和传感器模型可以直接从MATLAB/Simulink里生成代码部署开发效率高第三实时性有保障最小步长可以做到50微秒对于大多数智驾场景足够用了。但这里有个坑Speedgoat的以太网板卡虽然支持TSN但配置起来并不简单。我一开始想用标准以太网做传感器数据注入结果发现域控对数据包的到达时间非常敏感普通以太网的抖动根本满足不了要求。后来改用TSN交换机做时间敏感网络配置才把抖动压到了可接受范围。TSN的配置涉及时间同步、流量整形、门控调度等一系列参数我后面会单独讲。2.2 传感器数据注入的硬件方案传感器注入是定制化HiL里最麻烦的部分。摄像头、激光雷达、毫米波雷达的接口和协议完全不同需要分别处理。摄像头注入我选的是基于FPGA的GMSL视频注入板卡。为什么用FPGA因为摄像头数据流是高速串行的而且域控对视频流的帧同步和时序有严格要求。FPGA可以精确控制每一帧的发送时刻还能在视频流里嵌入时间戳和同步信号。具体做法是仿真环境生成原始图像数据通过PCIe传到FPGA板卡FPGA按照GMSL协议打包成串行流再通过同轴电缆送给域控。这里的关键参数是像素时钟和行场同步信号的时序必须和真实摄像头模组完全一致否则域控可能识别不到或者图像错位。激光雷达注入我用的是以太网方案。大多数车载激光雷达输出的是UDP包里面包含点云数据和时间戳。仿真环境生成点云后通过TSN以太网直接发给域控。这里要注意的是点云的坐标系和强度值必须和真实雷达一致否则感知算法会出问题。我踩过的坑是仿真点云的密度和真实雷达差异太大导致感知模型在台架上表现很好一上实车就崩。后来我在点云生成环节加了噪声模型和衰减模型尽量逼近真实雷达的输出特性。毫米波雷达注入相对简单因为很多雷达输出的是CAN FD或者以太网的目标级数据。我用的是CAN FD板卡模拟雷达目标列表把仿真出来的目标距离、速度、角度按照雷达的协议格式打包发送。但要注意雷达的探测周期和域控的接收周期要匹配否则会出现数据堆积或者丢帧。2.3 时间同步与实时性保障时间同步是整套系统的生命线。域控内部对各个传感器数据的时间戳有严格的对齐要求如果注入的数据时间戳乱了感知融合直接失效。我的方案是用PTP精确时间协议做全网时间同步主时钟放在实时仿真机上所有注入板卡和域控都作为从时钟。PTP的同步精度可以做到亚微秒级对于大多数智驾场景够用了。但PTP配置有几个关键点第一交换机必须支持PTP透明时钟否则交换机的排队延迟会破坏同步精度第二所有节点的PTP报文优先级要设到最高避免被其他流量挤占第三域控的PTP从时钟配置要和主时钟的域号、报文类型匹配否则根本同步不上。我调试PTP花了整整一周最后发现是交换机的PTP配置里domain number设错了这种细节问题最容易让人抓狂。实操心得时间同步调试时先用示波器测PTP的秒脉冲信号确认硬件层面同步上了再去查软件配置。如果秒脉冲都对不齐软件怎么调都没用。3. 车辆动力学模型与场景仿真实现3.1 车辆动力学模型的搭建与标定车辆动力学模型是HiL台架的“灵魂”。模型不准域控在台架上跑得再好上实车也是白搭。我用的是一套15自由度的车辆模型包含车身6自由度、四个车轮的旋转和垂向运动、以及转向系统和制动系统的动态特性。模型在Simulink里搭建然后生成C代码部署到实时目标机上。模型标定是个体力活。我拿实车采集的数据做参数辨识主要标定这几个参数轮胎的侧偏刚度和纵滑刚度、悬架的刚度和阻尼、转向系统的传动比和延迟、制动系统的压力-力矩特性。标定方法用的是最小二乘法把实车数据和模型输出做拟合迭代调整参数直到误差在可接受范围内。这里要注意的是轮胎模型对温度 and 路面条件很敏感我建议至少标定干沥青和湿滑路面两种工况否则模型在极端场景下会失真。模型验证我做了三组测试双移线、正弦扫频、紧急制动。双移线看的是横摆角速度和侧向加速度的跟随精度正弦扫频看的是频率响应特性紧急制动看的是纵向减速度和滑移率的匹配度。实测下来横摆角速度的峰值误差控制在5%以内侧向加速度误差在8%以内对于HiL测试来说够用了。3.2 场景仿真与传感器物理模型场景仿真我用的是CarMaker和Simulink联合仿真。CarMaker负责生成道路、交通车、行人等场景元素Simulink负责车辆动力学和传感器模型。两者通过TCP/IP做数据交换步长设为1毫秒。为什么不用CarMaker自带的车辆模型因为CarMaker的车辆模型是黑盒没法深度定制而我的测试需求里有很多非标准工况必须自己搭模型。传感器物理模型是场景仿真里的难点。摄像头模型要模拟镜头畸变、曝光、运动模糊、天气影响激光雷达模型要模拟光束发散、反射率、雨雾衰减毫米波雷达模型要模拟多径效应、杂波、遮挡。这些模型不需要做到物理级精确但至少要能复现真实传感器的典型失效模式。比如摄像头在逆光下的过曝、激光雷达在雨天的点云稀疏、毫米波雷达在隧道里的多径虚假目标这些场景如果模型里没有域控的鲁棒性就测不出来。我踩过的一个大坑是场景仿真里的交通车行为太“规矩”了永远保持安全距离、永远不突然变道。结果域控在台架上跑了几万公里都没触发过紧急避障一上实车就遇到加塞直接懵了。后来我在场景里加了“激进驾驶员”模型随机生成急刹、加塞、鬼探头等行为才把域控的边界场景测出来。3.3 场景库的建设与管理场景库是HiL台架的长期资产。我按照功能、场景、工况三个维度来组织场景库。功能维度包括自适应巡航、车道保持、自动变道、紧急避障等场景维度包括高速公路、城市道路、乡村道路、停车场等工况维度包括白天、夜间、雨天、雾天、雪天等。每个场景用XML描述包含道路几何、交通参与者、环境条件、初始状态等参数。场景库的管理我用的是Git做版本控制每个场景文件都有唯一的ID和版本号。测试用例通过ID引用场景这样场景更新后所有引用它的测试用例自动使用新版本。这里要注意的是场景变更必须做回归测试否则可能出现“修好一个场景弄坏十个用例”的情况。我建议每次场景库更新后至少跑一遍冒烟测试集确认核心功能没受影响。4. 测试管理与自动化执行4.1 测试用例的设计与组织测试用例的设计直接决定了HiL台架的产出效率。我的做法是把测试用例分成三层——功能层、场景层、边界层。功能层验证单个功能是否正常比如自适应巡航的跟车距离控制场景层验证多个功能在复杂场景下的协同比如自动变道时遇到后车加速边界层验证系统在极端条件下的表现比如传感器失效、通信丢包、电源波动。每层用例的通过标准不同。功能层要求100%通过场景层允许有已知的边界情况边界层主要看系统是否能安全降级。用例用Python脚本编写通过测试管理平台调用。脚本里定义测试步骤、注入信号、采集输出、判断结果。这里的关键是断言的设计不能只看最终输出还要看中间状态。比如紧急避障测试不能只看车有没有停下来还要看制动压力建立的斜率、转向角的变化率、以及域控内部的状态机跳转。4.2 自动化测试执行与报告生成自动化执行我用的是Jenkins做调度每天晚上跑全量回归白天跑冒烟测试。测试结果自动上传到数据库生成HTML报告。报告里包含每个用例的通过状态、执行时间、关键波形截图、以及失败原因分析。失败用例会自动截取故障前后的数据方便快速定位问题。这里有个经验自动化测试最怕“假通过”。我遇到过好几次用例显示通过但实际上是域控根本没响应测试脚本误判为通过。后来我在断言里加了“心跳检测”如果域控在指定时间内没有发出预期的报文直接判定为失败。另外测试环境的稳定性也很重要我建议每天开始测试前先跑一遍自检脚本确认所有板卡、电源、通信链路都正常。4.3 持续集成与回归测试策略持续集成是保证台架长期可用的关键。我的做法是代码提交到Git后自动触发编译和单元测试单元测试通过后自动部署到HiL台架跑冒烟测试冒烟测试通过后才允许合并到主分支。每天晚上跑全量回归第二天早上出报告。如果回归测试发现新增失败用例自动发邮件通知相关责任人。回归测试的策略是“全量增量”。全量回归覆盖所有核心用例增量回归只跑受代码变更影响的用例。怎么判断哪些用例受影响我用的方法是代码变更文件关联到功能模块功能模块关联到测试用例。比如改了AEB的触发逻辑就自动跑所有AEB相关的用例。这样既保证了覆盖率又控制了测试时间。常见问题回归测试跑久了用例会越来越多执行时间越来越长。我的解决办法是定期做用例精简把重复覆盖的用例合并把长期稳定的用例降频执行。比如核心功能用例每天跑边界用例每周跑一次。5. 常见问题与排查技巧实录5.1 传感器注入失败的典型原因传感器注入失败是HiL台架调试中最常见的问题。我整理了一个排查表按现象、可能原因、排查方法三个维度来组织。现象可能原因排查方法域控识别不到摄像头GMSL时序不对、同轴电缆阻抗不匹配用示波器测GMSL差分信号的眼图确认时序和幅度激光雷达点云错位坐标系定义不一致、时间戳偏移对比仿真点云和真实点云的坐标系检查PTP同步状态毫米波雷达目标丢失CAN FD波特率不匹配、报文ID错误用CAN分析仪抓包确认波特率和报文格式所有传感器数据延迟大TSN配置错误、交换机拥塞检查TSN门控调度表确认关键流量优先级最高时间戳跳变PTP主时钟不稳定、网络抖动用PTP监控工具查看时钟偏移检查网络负载这张表是我踩了无数坑之后总结出来的基本上覆盖了80%的注入问题。剩下的20%往往是硬件故障或者协议实现差异需要具体问题具体分析。5.2 车辆模型失真的排查思路车辆模型失真表现为台架测试结果和实车测试结果差异大。排查思路是“先静态后动态先单点后全局”。静态测试包括方向盘转角到前轮转角的传动比、制动踏板到制动压力的映射、油门踏板到驱动扭矩的映射。这些静态特性如果不对动态测试根本没法做。动态测试包括阶跃响应、正弦扫频、双移线。阶跃响应看的是响应时间和超调量正弦扫频看的是幅频和相频特性双移线看的是横摆角速度和侧向加速度的跟随精度。如果动态测试发现模型失真优先检查轮胎模型和悬架模型这两个是影响最大的。我遇到过一次模型失真排查了两天才发现是轮胎的侧偏刚度标定错了。原因是实车采集数据时轮胎温度没控制好导致辨识出来的刚度偏高。后来我在标定流程里加了轮胎温度监控确保每次标定都在相同温度下进行。5.3 自动化测试的稳定性保障自动化测试的稳定性是个系统工程。我的经验是硬件稳定性占50%软件健壮性占30%环境一致性占20%。硬件稳定性包括板卡固定牢靠、线束连接可靠、电源稳定、散热良好。我见过太多因为线束松动导致测试随机失败的案例所以现在所有线束都用扎带固定关键连接点用螺纹锁固胶。软件健壮性包括异常处理、超时重试、日志记录。测试脚本里必须加超时机制任何一步操作超过预期时间就判定失败并记录现场。日志要详细到每一步的信号值和状态方便事后分析。环境一致性包括温度、湿度、供电电压、电磁干扰。我建议台架放在恒温恒湿的实验室里供电加稳压器关键信号线加屏蔽。避坑技巧自动化测试跑通之后先连续跑72小时稳定性测试。如果72小时内没有随机失败基本可以认为系统稳定了。如果有随机失败一定要找到根因不要用重试来掩盖问题。6. 定制化HiL台架的扩展与演进6.1 从单域控到多域控的扩展高阶智驾的电子电气架构正在从单域控向多域控演进中央计算区域控制的架构越来越普遍。这意味着HiL台架也要支持多域控联合测试。我的扩展方案是在现有台架基础上增加一个“域控间通信仿真层”模拟域控之间的以太网、CAN FD通信。每个域控有独立的传感器注入通道但共享同一个车辆动力学模型和场景。多域控测试的难点是时间同步和任务调度。多个域控之间的通信有严格的时序要求如果仿真层不能精确控制报文发送时刻域控间的协同就会出问题。我的做法是用TSN交换机做域控间通信所有报文打上硬件时间戳仿真层根据时间戳调度发送。这样可以把域控间通信的抖动控制在微秒级。6.2 云仿真与HiL的协同云仿真和HiL不是替代关系而是互补关系。云仿真适合跑海量场景的快速迭代HiL适合跑关键场景的精确验证。我的做法是在云仿真平台上跑大规模场景筛选把可疑场景和边界场景导出然后在HiL台架上做精确复现和深度分析。这样既保证了测试覆盖率又保证了关键场景的测试精度。云仿真和HiL的数据接口我用的是OpenSCENARIO和OpenDRIVE标准格式。云仿真平台导出场景文件HiL台架导入后自动生成测试用例。测试结果再回传到云平台做统一管理和分析。这套流程跑通之后场景从发现到验证的周期从原来的两周缩短到了两天。6.3 数据闭环与持续迭代HiL台架产生的测试数据是宝贵的资产。我把这些数据分成三类通过用例的数据、失败用例的数据、边界用例的数据。通过用例的数据用来做回归基线失败用例的数据用来做问题定位边界用例的数据用来做模型优化。数据闭环的核心是“测试-分析-优化-再测试”。每次发现失败用例先分析根因如果是模型问题就优化模型如果是域控问题就反馈给域控开发团队如果是测试用例问题就修正用例。优化之后重新跑测试确认问题解决且没有引入新问题。这个闭环跑得越快台架的价值就越大。我个人的体会是定制化HiL台架不是一次性投入而是一个持续演进的过程。硬件会过时软件会迭代场景会更新只有建立起一套可持续的开发和维护流程台架才能长期发挥价值。最后分享一个小技巧台架的每个模块都要有详细的文档和版本记录包括硬件配置、软件版本、标定参数、已知问题。这样即使人员变动接手的人也能快速上手不至于从头再来。