HIL项目做到第十篇按理说该聊点压箱底的东西了。这轮我在台架上把怠速功能、速度控制和超速防止功能放在一起做了一轮完整验证表面上看三个功能都不算高难度动作真正测起来才发现恰恰是这些基础控制逻辑最容易暴露台架配置、信号定义和控制器策略之间的隐性矛盾。如果你正准备搭一套VCU硬件在环测试环境或者已经在跑了但经常被莫名其妙的测试失败卡住这篇直接把三类功能的用例设计思路、信号准备方法和几个真实的翻车现场分享出来可以少走不少弯路。1. 三个功能同时摆上台架的缘由试金石而非常规回归1.1 它们在整车控制逻辑里的真实位置怠速功能、速度控制、超速防止光看名字会觉得是三个彼此独立的模块。但真正把它们放进整车控制器的软件架构里看三者其实是同一条扭矩控制链上的不同断面。怠速控制的本质是当前没有驾驶员扭矩需求或需求很小时控制器通过对发动机/电机输出扭矩的闭环调节把转速稳定在目标值附近。这一环涉及的不仅有转速PID还有怠速目标转速的工况切换比如空调接入、挡位挂入D挡、电池充电请求等。速度控制的本质则换成车速闭环驾驶员给出一个目标速度或扭矩百分比请求VCU把这个请求换算成驱动扭矩车辆模型再反馈回一个实际车速形成整车级的闭环。而超速防止更像是悬在这条闭环上方的安全网它不断检查当前车速或转速是否越过阈值一旦越界就接管或限制扭矩输出必要时直接断油或者走故障降级。从功能逻辑上看三者层层嵌套怠速不稳会导致起步冲击速度控制的目标车速生成逻辑出错会直接触发超速防止超速防止如果响应太激进又会把正常加速过程切成钝挫。所以这轮测试我没有把它们拆成三组孤立用例而是按基础控制-闭环跟踪-安全边界的顺序串在一条测试链上这也是标题里同时测的意义所在。1.2 为什么这些功能必须上HIL跑而不能只靠实车很多刚入行的测试工程师会问怠速、超速这些功能实车上一踩油门一抬刹车就能感觉到为什么还要花大力气做硬件在环我的回答是实车能测出现象但很难测出边界。以怠速为例实车环境下空调压缩机何时接入、转向助力泵消耗多少扭矩、蓄电池充电电流波动多大这些负载扰动都是不可控的你很难在相同条件下复现两次一模一样的转速跌落。超速防止更麻烦实车把车速推到限值附近本身就是高风险操作尤其是在试验场里反复逼近临界状态对测试员和车辆都是一种消耗。HIL测试的本质价值是把整车环境中这些不可控变量变成台架模型里的可参数化输入负载扰动随时可以注入坡度阻力可以按百分比设置车速信号可以直接被掰成一个跳变值看控制器反应而且每次跑完落一份波形记录问题能复现、能对比、能量化。这也是我把这三个功能定义为台架试金石的原因一座HIL台架如果能把这三个功能测明白说明实时机模型、信号路由、故障注入、标定连接这一整套基础设施都是健康的。它们就像软件工程里的单元测试覆盖的不只是被测功能本身更是整个测试环境的质量下限。2. 让VCU入戏台架信号路由、负载模型与标定准备2.1 信号排布先画矩阵图再动线束HIL台架跑这三项功能之前第一件事不是写用例而是把VCU需要的所有输入输出信号一项项列清楚。我习惯先做一张信号-通道-初始值对照表把模型侧和控制器侧的要求对起来避免上线后才发现某个CAN信号漏配或者初始值踩了雷。信号功能信号方向通道类型典型初始值说明点火开关状态台架-VCU数字量IOOFF测试起动逻辑必需油门踏板开度台架-VCU模拟量IO0%双路冗余信号须同步制动踏板开关/行程台架-VCU数字/模拟0速度控制退出条件挡位状态(P/R/N/D)台架-VCU总线信号P挡影响怠速目标与起步车速信号台架-VCU总线信号0 km/h超速防止判据轮速信号(四轮)台架-VCU总线信号0 km/h与车速交叉校验发动机转速/电机转速台架-VCU总线信号0 rpm怠速闭环反馈扭矩请求/实际扭矩VCU-台架总线信号0 Nm闭合驱动链路主继电器/驱动使能VCU-台架数字量IO断开判断控制器是否进入安全状态这张表里最容易出问题的是模拟量信号和总线信号同时存在的场景。比如油门踏板VCU内部通常会做两路信号交叉校验如果台架侧只给了单路控制器就会报出合理的信号故障并限制扭矩表面上看起来像是功能失效实际上是测试环境没造够。这类问题我在第一节做信号预检时必查宁可多花半天把信号通道盘点完也不要带着缺失的半套环境跑用例。2.2 被控对象模型负载扰动是怠速测试的扮演者怠速测试在台架上能不能做真关键看车辆纵向动力学模型里的负载项是否完整。一个合格的HIL被控对象模型至少要包含整车质量、滚动阻力系数、风阻系数和坡度阻力传动系模型挡位、传动比、转动惯量发动机/电机的外特性和动态响应特性附件负载接口空调压缩机、转向泵、发电机等功率消耗怠速工况下车辆静止车速等于零此时引起转速波动的主要就是附件负载的接入和脱开。我的做法是在模型里独立开一个附加扭矩负载输入端口测试时通过该端口注入一个阶跃扭矩比如从0跳到10 Nm观察VCU的怠速闭环能否在设定时间内把转速拖回目标窗口。这比真的去模拟空调压缩机内部物理过程要简单可靠得多而且可重复性极强。速度控制测试则需要模型里细致处理坡度阻力。假设整车质量1500kg7%坡度相当于角度约4度坡道阻力大约是m·g·sinθ约15009.80.0699≈1000N换算到轮端扭矩约200Nm以上。如果模型里车重参数填成0或者坡度注入通道失效速度控制测试就会表现出完全不失速的假象这样的测试结果是没有任何参考价值的。我后面第6章会专门讲这个坑。2.3 标定接口与故障注入口要提前预埋三组功能测试里至少有三类参数需要在线标定怠速目标转速表、超速限制阈值、速度控制的PID增益和滤波系数。台架上的标准做法是走XCP over CAN通过A2L文件将编译器符号映射到标定工具里。用CANape或INCA连接好之后可以在测试中途实时修改目标转速、限速阈值验证控制器对参数变更的响应这比重新刷写一遍软件效率高太多。我强烈建议HIL工程在搭建初期就把标定连接是否可用作为验收项之一而不是等到用例跑不过去时才反过来排查标定问题。故障注入方面我这一轮主要用到两种方式。一种是信号级故障注入直接在CANoe里改总线信号的值、加延时、加扰动或者短时移除报文用来模拟传感器信号丢失、信号超限等电子层面的故障。另一种是电气级故障注入通过故障注入单元FIU切断VCU与执行器之间的硬线连接或者把某条线短接到电源/地线用来验证控制器在硬件通道失效时的行为。两种方式服务的用例类型完全不同前者适合测控制策略层面对数据质量的判断后者适合测硬件保护策略和降级逻辑缺一不可。3. 怠速功能实际起动过渡、负载突变与学习值异常3.1 起动-怠速过渡测试看超调也看稳定时间怠速测试的第一组用例是从起动过程开始的。点火开关OFF到ON后VCU先控制起动机拖动发动机转速爬升达到一定转速门槛比如350rpm后控制使能转速继续越过点火启动点最终收敛到目标怠速。这个过程中的关键指标有三个是否出现低于熄火转速的跌落比如低于500rpm、转速超调量不允许超过目标值上方某一阈值、从起动到进入怠速稳定窗口的时间。我这轮的目标怠速设定为800rpm稳定窗口宽度为±50rpm要求进入窗口后持续5s不超限。实际跑出来的波形显示转速首次冲到860rpm附近超调约60rpm随后回落到780~820区间整个过程约1.2s。判断结果时要注意不同控制器的PID参数风格差异很大有的激进型超调大但收敛快有的保守型稳定但偏慢写自动判定时不要用一个绝对模板卡死所有项目。3.2 目标怠速变更与负载突加突减怠速控制的难点在于扰动抑制。我在台架上依次注入了空调压缩机接入请求、DCDC大功率负载切换、挡位从P到D的扭矩预载请求每项都记录转速的跌落深度和恢复时间。以一个典型用例为例目标怠速800rpm测试第3s注入10Nm的附加扭矩负载模拟空调压缩机吸气冲击持续5s后撤出。实测转速最低掉到735rpm跌深65rpm负载撤出后最高冲到845rpm大约0.8s回到±30rpm以内。这类数据的参考价值在于如果跌深超过软件设定的限制比如100rpm或恢复时间明显偏长说明怠速前馈补偿量不够或者PI参数偏保守。台架测试的好处就是可以不断修改补偿标定重跑同一条激励看迭代效果。负载突变测试还有一条容易忽略的边界同时接入两个以上负载请求。比如挡位挂入D挡的同时注入空调请求附件扭矩叠加会让转速双重跌落。真实整车环境里这种工况经常出现但很多实车标定测试并不会刻意把它提出来做组合验证。HIL用例设计时要主动把这些交错请求补上覆盖率才够。3.3 怠速自学习HIL最适合做的专项验证现代VCU普遍带有怠速自学习功能根据发动机磨损、积碳、环境变化实时修正怠速时的基础扭矩补偿量。这个功能在HIL台架上做反而比实车更有优势因为台架环境稳定可以精确操控学习进程和条件。我在测试里特别设计了一组学习值污染用例通过标定接口把怠速学习值初值设置到上限附近比如50%然后观察控制器在连续多次怠速工况中是否能逐步把学习值修正回归正常区间。另一个方向是阻断学习条件比如让冷却液温度始终不满足学习允许条件确认学习值保持不变防止控制器在条件不满足时依然偷偷改写学习量。这类用例最容易出错的位置在于学习允许条件的信号采集。HIL环境里冷却液温度、进气温度等信号都是模型算出来的如果模型里温度上升速率与实际不符学习条件可能永远无法满足导致测试时间里控制器始终不进入自学习状态。遇到这种情况先别看控制器的PID逻辑回头核查仿真模型的温度动态是否合理。4. 速度控制实测轨迹跟随、坡道补偿与信号干扰4.1 从驾驶员请求到扭矩命令的完整链路速度控制功能在HIL台架上的闭环链路是测试系统通过油门踏板/挡位/制动信号给控制器输入驾驶员意图VCU根据整车状态计算目标扭矩并输出给车辆模型车辆模型解算出新的车速反馈给VCU。速度控制不是简单地把驾驶员踏板百分比映射成扭矩百分比其中还叠加了模式解释、起步保护、加速度限制、扭矩滤波等多个环节。实际测试时我习惯先给一条低速起步工况油门踏板以固定速率从0踩到30%观察VCU输出的目标扭矩斜率是否受加速度限制器约束实际车速是否平滑上升而不是踹一脚的冲出去。如果发现目标扭矩在低速段出现跳变优先怀疑扭矩请求坐标转换环节也就是从踏板特性表查到的驾驶员目标扭矩与其他扭矩源仲裁时出现了优先级冲突。这类排查在示波器上看目标扭矩与滤波后扭矩两条曲线对比很容易定位。4.2 车速寻迹不依赖真实道路的闭环验证车速寻迹测试是速度控制功能最核心的用例组。测试系统按照预设的目标车速-时间曲线比如0→30→50→80→60→0 km/h更新行驶工况车辆模型跟踪VCU输出的扭矩实际车速被采集回来和参考车速做对比。这里的寻迹检验的是速度闭环的动态性能跟随误差不能超过阈值切换阶段不能有剧烈振荡稳态阶段误差应该收敛值零附近。下面是一组典型的测试数据质量1500kg平路无坡度阶段目标车速实测峰值误差稳定误差备注0→30km/h加速加速度约2m/s²2.8km/h0.4km/h开始段有轻微超调30km/h匀速持续10s0.9km/h0.3km/h扰动注入后恢复30→80km/h加速加速度约3m/s²4.1km/h0.6km/h高速段误差增大80km/h→60km/h松油门滑行自然减速-3.2km/h1.1km/h滑行阻力模型起作用60→0km/h制动制动请求-2.4km/h0.7km/h停车前有低速顿挫看数据可以得出一个规律误差最差的区段通常发生在目标车速快速变化的过渡段而不是稳态段。如果过渡段误差超标不要急着调PID先看一下目标车速生成器本身的斜率限制是否合理很多速度控制问题的根源是目标信号跳变太快控制器动态响应跟不上并不是控制器本身调教得差。4.3 坡道与滚动阻力变化下的速度跟随平路上的速度控制平稳只能说明基础闭环没问题车辆工程上真正敏感的是坡道补偿能力。我在模型里设了3%和7%两档坡度对比测试目标车速50km/h匀速时的速度波动。7%坡度时控制器需要额外输出约200Nm的轮端扭矩来克服坡道阻力这在实际扭矩命令中表现为明显的直流偏置。如果VCU的速度控制算法带有坡道估计功能它会在检测到车速下降和扭矩增加后逐步学习出坡度值并做前馈补偿如果没有就纯粹靠PI调节器慢慢把误差收回来这个过程中车速的跌落深度会明显更大。我实测的两类策略差异是带坡道前馈的控制器在坡度阶跃后车速最大跌4.3km/h约1.5s恢复到目标值单纯PI的速度控制器最大跌了7.8km/h且恢复时间超过3s伴随轻微振荡。这个对比很适合用来评价控制器算法的好坏。4.4 车速信号质量问题从信号抖动到传感器失效速度控制对车速反馈信号的质量非常敏感。我在测试中给车速信号人为叠加了两种典型故障一种是叠加正弦扰动幅值约1.5km/h、频率5Hz模拟传感器信号屏蔽不良带来的抖动另一种是短时冻结即车速值保持上一个有效值不变长达200ms模拟CAN报文丢失或传感器延迟。叠加抖动时速度控制器如果滤波时间常数偏小会把扰动放大成扭矩波动实测表现为加速踏板没有动但扭矩请求在±30Nm之间来回摆。改用较大的滤波系数后扭矩波动显著下降但代价是有效车速信号的延迟变大动态跟随性能变差。这个权衡没有绝对正确只能看项目更在意舒适性还是动态响应。而车速信号冻结则直接触发另一条逻辑当控制器检测到车速信号变化率超过物理极限持续一段时间后会判定车速信号不合理进而请求切换到备用车速或限制扭矩输出这个降级行为的时序和阈值是否符合功能安全需求也是HIL测试的一个重点。5. 超速防止实测限值触发、扭矩切断与失效场景5.1 三层防护逻辑正常限速、功能限速与失效保护超速防止不是一个单一功能而是至少三层机制的组合。第一层是正常驾驶时的电子限速例如整车设计最高车速120km/h当车速达到118km/h时控制器开始线性减小驾驶员扭矩请求保证车速被压在限值以下而不是失控冲破。第二层是功能性限速比如根据当前挡位或驱动模式限制最大允许车速运动模式放开、经济模式收紧。第三层是失效保护检测到关键信号错误或总线通信故障时无条件限制扭矩或切断动力源。HIL测试三层都要覆盖到但前两层侧重阈值标定的准确性第三层侧重安全响应的时间要求。我设计用例时会把阈值附近的行为拆成接近-触发-恢复三段分别观察接近段看扭矩是否开始衰减、衰减斜率多大触发段看车速是否继续上升、上升量多少恢复段看车速降到阈值以下后扭矩是否平滑恢复不要出现反复切换的抖动。5.2 越界测试持续油门下的限速介入动作我按某平台的标定为例超速限制阈值设为105km/h限制介入后目标扭矩按每100ms衰减5%的比例递减。用例从80km/h匀速开始以固定油门踏板开度持续加速车速逐渐逼近限值。实测数据显示车速到达约103.5km/h时控制器已经通过预测逻辑提前开始衰减扭矩到车速实际突破105km/h时扭矩已经衰减了约15%继续深踩油门扭矩以设定斜率持续下降最终车速被稳定在106km/h以内没有出现继续向上的失控趋势。这里有一个值得记录的经验限速器介入的预测提前量很关键如果控制器等到实际超速后才动作车速度往往还会惯性冲高1~2km/h标定上通常会在接近阈值时预留一个控制提前带这个提前带在测试报告中要单独标注。自动判定时我通常给超速加强允许值留一个余地比如限速105km/h时允许最大到达车速不超过108km/h持久时间不超过500ms。如果突破量或持续超限时间超了基本可以判定超速防止策略失效或标定不合理。5.3 信号失效时超速保护还灵不灵超速保护最怕的不是正常越界而是控制器看不到车速已经超出限制。我在这一轮专门做了车速信号失效注入把CAN线上的车速信号强制改为一个低值例如实际车速110km/h但总线车速值始终固定在30km/h同时轮速信号同样被拉到低值模拟双通道车速同时失效。这种情况下如果控制器只依赖车速信号做超速判断就会完全失去防护能力。所以整车架构里通常会冗余一条车速硬线信号或由VCU根据电机转速和当前挡位换算出一个估算车速作为备份。测试中我观察到的结果是总线车速被污染后约400msVCU识别出车速和备份车速由转速换算得到不一致触发了交叉校验故障进入限制扭矩模式输出的扭矩被直接限制为一个安全值。这个400ms的判断时间就是功能安全概念里常说的故障反应时间HIL测试的职责之一就是验证这个时间是否被实测确认过。这类失效用例里还要确认一个反直觉的点当故障消失后控制器能否自动恢复正常控制。很多策略设计得足够安全但恢复逻辑写得很激进故障解除瞬间会有一个扭矩跳变。我在测试中专门在故障撤销后观察转速和扭矩波形确认无异常冲击后才把用例判定为通过。6. 自动化用例脚本与判定窗口怎么写才靠得住6.1 用参数表驱动用例而不是把场景写死在脚本里跑完一轮手动测试后下一步就是把三组功能转成自动化回归用例。我的做法是建一张可配置的用例参数表表的每一行是一条独立的测试场景字段包括工况名称、初始条件、输入激励参数、期望响应和判定窗口。脚本本身只负责按行读取参数、注入信号、采集数据和执行判定不承载具体的场景知识。以怠速测试为例参数表里记录的是目标转速800rpm、负载注入幅值10Nm、注入时间5s、允许跌深100rpm、恢复时间2s。如果后续标定目标转速改成750rpm只需要在表里改数值不需要动脚本代码。更关键的是一旦新需求出现可以在不发布软件版本的情况下快速新增一行用例测试资产的可持续性比写死逻辑高很多。下面是一段Python风格的判定伪代码核心逻辑是判别转速是否掉落过低并能否恢复窗口def check_idle_recovery(speed_log, target, low_limit, recover_time): min_speed min(speed_log) if min_speed low_limit: return FAIL: 转速跌落过深 in_window_at None for i, spd in enumerate(speed_log): if abs(spd - target) 50: if in_window_at is None: in_window_at i else: in_window_at None if in_window_at is None or (len(speed_log) - in_window_at) recover_time * sample_rate: return FAIL: 未在规定时间内回到窗口 return PASS实际项目中我还会引入状态机来判断是否处于怠速模式而不是单纯看转速范围否则在加减速过程中可能误判。6.2 判定标准必须留合理的容忍窗口写自动化判定的头号教训是判定条件太紧把合法工况误判为失败太松又让真正的问题溜过去。每个指标都要给容忍带但容忍带必须有理有据。这里有几个经验值可以参考判定指标建议容忍范围说明怠速稳态波动目标±50rpm内更窄容易受噪声误触温度/负载扰动后的恢复时间设定值20%余量考虑模型计算步长离散化超速加强允许值阈值3km/h与标定提前带相关故障反应时间设计指标100ms过于严格会刷出假失败速度跟随稳态误差目标±1km/h过渡段误差可单独放宽合理余量的另一个作用是过滤掉HIL实时机模型由于固定步长离散化带来的数值噪声。比如Simulink模型步长1ms车速反馈经CAN传输还有一定延迟这些因素叠加起来会给波形增加微小毛刺判定算法如果不做窗口过滤几乎每次都会等不到完美状态。6.3 失败用例如何一键找回根因自动化跑出FAIL结果不可怕可怕的是FAIL之后需要花一小时在数据文件里捞波形。我的做法是在每条用例启动时自动记录全局时间戳并在测试报告中生成同一时间轴下的信号截图截图内容包括所有关键总线信号、IO信号、标定参数和判定算法内部状态量。报告中直接把FAIL位置对应的上下10s窗口截出根因排查效率能提升几倍。另外自动化执行时一定要把每个用例的复现能力放到第一位。比如超速防止测试油门踏板的上升斜率和起始车速必须严格一致否则两次运行的初始条件不同是否触发就没了可比性。我在脚本里设置了前置条件检查用例启动前先确认当前车速、挡位、转速都在预期窗口内不在就自动等待或中止而不是稀里糊涂往下跑这一点对回归测试的稳定性帮助很大。7. 三个让人印象深刻的翻车案例7.1 车速方向反了速度控制和超速防止同时失效有一次在排查加速测试失败时发现车速一直显示为0但模型内部计算的车速是正常的。从CANoe里看总线报文车速信号确实在更新但数值纹丝不动。最后查出来是DBC里车速信号的定义是负向有效即信号值减去偏移量后再取反才是真实车速而台架侧按照普通量纲直接解析导致控制器收到的车速是负值被合理性检查直接丢弃。这个问题在实车上几乎不可能出现因为传感器方向接反会直接被试车员发现但HIL环境里DBC文件是从工具链导入的一旦方向标签不一致就是一场无声的灾难。现在我在信号预检阶段会给每个总线信号做一个注入-回读验证台架发送一个已知值解析回读确认一致后再开始用例。7.2 初始DBC值把一个关键状态置为无效VCU以为已超速另一次失败现象是测试刚开始VCU就进入了超速限制模式扭矩输出被压得很低但车速明明是0。排查了很久最终发现CANoe环境变量里车速信号有效位的初始值被置为无效控制器按功能安全策略在车速信号无效时直接进入安全状态限制扭矩。台架启动顺序里如果初始化信号的有效位被漏配控制器收到的是一个看似异常的状态自然会触发保护。这个案例说明HIL环境的初始信号状态不是随意填的必须跟整车上下电的真实时序对齐先给有效位还是先给车速值先后顺序不对都会影响控制器的状态机。7.3 模型车重填成0超速测试结果完全失真最后一例是我自己踩过的坑。某次超速防止测试里车辆从80km/h加速到105km/h的时间比预期短了很多超速触发后的减速也快得离谱限速介入的逻辑明明有延迟却看不出延迟效果。查模型参数时发现车重字段被填成了0导致车辆模型里整车惯性缺失同样的扭矩作用下加速度被无限放大整个速度动态过程严重失真。这类问题在纯信号回路的测试里不容易暴露但一旦涉及速度控制、超速防止这种依赖纵向动力学的用例模型的物理参数就成了测试有效性的地基。从那以后我的台架验收清单里增加了一条强制性检查正车质量、风阻系数、滚动阻力系数等关键物理参数必须在测试报告中固化存档每次环境刷新后核对防止谁无意间改掉。这三件事串起来其实都是同一个道理HIL测试测得不只是控制器还在测测试环境本身。台架信号配置错了、初始状态没对齐、模型参数失真都会让功能失败的结论指向完全错误的根因。把这套地基打好再来谈怠速、速度控制、超速防止的功能验证才算真正把硬在环的价值发挥出来。