★ FEATURED ARTICLE 1. 从一次台架联调说起为什么测试工程师绕不开Simulink我第一次真正意识到Simulink对HiL测试的重要性是在一个电机控制器的台架联调现场。当时测试用例已经跑通了八成剩下几个涉及扭矩仲裁和故障降级逻辑的用例怎么都复现不了实车上的表现。查了三天最后发现问题出在模型侧——被控对象模型里一个查表模块的插值方式用的是线性而实际控制器内部用的是最近邻边界工况下输出差了一大截。这个坑让我明白一件事HiL测试工程师如果只会点“运行”和“看曲线”遇到模型层面的问题就只能干瞪眼。HiL也就是硬件在环本质上是把真实的控制器硬件接到一个实时仿真机上用仿真机里跑的被控对象模型来替代真实的电机、发动机、液压系统或者整车。测试工程师的工作是设计用例、搭建环境、执行测试、分析结果、定位问题。而Simulink正是绝大多数被控对象模型、部分控制算法模型以及测试激励模型的搭建工具。你不需要成为建模专家但你得能看懂模型、能改模型、能判断模型哪里可能有问题。这篇文章想聊清楚三件事HiL测试为什么和Simulink绑得这么紧测试工程师到底需要掌握Simulink到什么程度以及从零开始该怎么学、学到什么标志算合格。适合刚入行做HiL测试的新人也适合做了几年测试但一直回避模型、想补齐这块短板的同行。我会尽量用实际场景来讲不堆术语把每个“为什么”说透。2. HiL测试与Simulink的真实关系拆解2.1 HiL台架的三大件里模型占了两件一套典型的HiL系统硬件上通常包含实时仿真机、IO板卡、信号调理模块、故障注入单元、被测控制器和上位机。软件上则是三块实时仿真模型、测试自动化软件、实验管理软件。很多人以为测试工程师只需要跟测试自动化软件打交道模型是建模工程师的事。这个认知在简单项目里勉强成立在复杂项目里会直接导致你无法独立完成工作。实时仿真模型一般分两部分被控对象模型和部分环境模型。被控对象模型描述的是被测控制器要控制的那个物理系统比如电池包的等效电路、电机的dq轴数学模型、变速箱的齿轮动力学。环境模型则包括驾驶员模型、道路模型、传感器模型等。这些模型绝大多数用Simulink和Simscape搭建编译后下载到实时仿真机里运行。测试工程师设计的每一个用例最终都要通过激励模型或者测试软件注入到这套模型里再观察被测控制器的响应。换句话说模型是测试的“战场”。你不熟悉战场的地形就没法设计出有针对性的战术。我见过太多测试工程师用例写得很漂亮但完全基于对控制器行为的猜测而不是基于对模型的理解。结果就是用例覆盖率上不去边界工况测不到出了问题也说不清是控制器的问题还是模型的问题。2.2 测试激励的生成很多时候就在Simulink里HiL测试的激励信号来源有几种测试自动化软件直接发、信号发生器发、剩下的就是Simulink模型发。涉及复杂时序、条件触发、闭环反馈的激励基本都得在Simulink里搭。比如你要测试控制器在车速信号跳变时的响应这个跳变信号可能需要和模型里的其他状态量联动用测试软件写脚本也能做但维护性和可读性远不如在Simulink里搭一个激励子系统。再比如故障注入。很多故障注入单元支持硬件故障注入但涉及信号层面的故障比如传感器信号漂移、卡滞、间歇性丢失往往需要在模型里做信号篡改。你得知道在模型的哪个位置插入故障注入逻辑才能既不影响模型本身的数值稳定性又能准确模拟故障特征。这要求你至少能读懂模型的信号流知道哪些信号是物理量、哪些是总线信号、哪些是经过滤波或限幅的。2.3 问题定位时模型是绕不开的证据链测试执行完结果和预期不符接下来就是定位。定位的路径通常是先看测试软件记录的信号再看被测控制器的内部变量最后看模型里的相关信号。如果前两步都排除了问题大概率出在模型侧或者模型与控制器的接口侧。这时候你需要打开Simulink模型找到对应的信号检查它的计算逻辑、参数配置、采样时间、数据类型。我处理过一个案例控制器在某个转速区间报故障但实车不报。查了控制器内部逻辑没问题最后在模型里发现仿真用的电机效率MAP和实车用的版本不一致导致仿真工况下电机损耗偏大触发了控制器的热保护逻辑。如果测试工程师不会看模型这个问题的定位周期至少翻倍。模型不是建模工程师的专属领地它是测试工程师的公共工具箱。3. 测试工程师需要掌握的Simulink能力分级3.1 入门级能看懂、能改参数、能跑起来入门级的目标很明确模型摆在面前你能知道它是干什么的能改几个关键参数能把它编译下载到实时仿真机里跑起来。具体来说你需要掌握这些操作。第一熟悉Simulink的基本界面和操作逻辑。知道怎么打开模型、怎么查找模块、怎么查看信号线连接、怎么运行仿真。这些看起来简单但很多测试工程师第一次打开一个几千个模块的模型时连从哪里入手都不知道。我的建议是先看顶层再看子系统一层层往下钻不要一上来就陷进细节。第二能识别常用模块。Constant、Gain、Sum、Product、Integrator、Transfer Fcn、Lookup Table、Saturation、Rate Limiter、Unit Delay、Switch、Relational Operator这些是出现频率最高的模块。你不需要知道每个模块的所有参数含义但看到它们能大概猜出这段逻辑在做什么。比如看到Integrator就知道在算积分看到Lookup Table就知道在做查表插值看到Unit Delay就知道有一个采样周期的延迟。第三能修改模块参数。这是入门级最核心的实操能力。测试工程师经常需要改的参数包括查表模块的表格数据、增益模块的增益值、常数模块的数值、限幅模块的上下限、积分模块的初始条件。改参数之前一定要确认两件事这个参数是否被其他模块引用改完之后是否会影响其他测试用例。我习惯在改之前先备份一份原始模型改完之后用版本管理工具记录变更。第四能配置仿真参数。求解器类型、步长、仿真起止时间、数据类型这些在模型编译下载前都要确认。HiL测试通常用固定步长求解器步长和实时仿真机的采样周期一致。如果步长设错了模型跑出来的结果可能完全不可信。我见过一个新人把步长从1ms改成10ms结果电机模型直接发散他还以为是控制器的问题。第五能编译下载模型。不同实时仿真机的编译流程不一样但基本步骤是类似的配置目标硬件、选择编译选项、执行编译、下载到目标机。这个过程可能会报各种错误比如模块不支持代码生成、数据类型不匹配、采样时间冲突。入门级的要求是能看懂常见错误信息知道去哪里查资料解决。提示入门级最容易犯的错误是“改完参数不记录”。HiL测试的可追溯性要求很高任何一个参数变更都可能影响测试结论。建议养成习惯每次改模型都在变更记录里写清楚改了什么、为什么改、影响范围是什么。3.2 进阶级能搭激励、能改逻辑、能定位模型问题进阶级的目标是你能独立搭建测试所需的激励模型能对现有模型做逻辑层面的修改能在问题定位时判断模型是否是根因。这个级别是大多数HiL测试工程师应该达到的水平。搭建激励模型核心是掌握几个常用的建模模式。第一个是状态机模式用Stateflow或者Switch组合来实现时序逻辑。比如你要模拟一个驾驶员踩油门的过程先快速踩下、保持一段时间、再缓慢松开。用Stateflow画三个状态加转移条件比用一堆Switch堆起来清晰得多。第二个是信号生成模式用Signal Builder、Signal Editor或者MATLAB Function来生成任意波形的激励信号。第三个是闭环控制模式用PID Controller或者自定义的反馈逻辑让模型根据被测控制器的输出调整激励输入。改逻辑这件事测试工程师要谨慎但有分寸。谨慎是指不要随意改动被控对象模型的核心物理逻辑那可能会让模型失去物理意义。有分寸是指当测试需要时你应该有能力在模型里增加旁路、增加监测点、增加故障注入逻辑。比如你要测试控制器在传感器信号间歇性丢失时的表现可以在传感器模型输出后面加一个Switch用脉冲信号控制信号是正常输出还是置为零。这种修改不改变模型的核心物理逻辑但能实现测试目的。定位模型问题需要你掌握一些基本的排查方法。我常用的套路是先看信号范围再看信号变化率最后看信号之间的因果关系。信号范围异常通常是参数配置错误或者单位不统一。信号变化率异常通常是采样时间或者求解器设置有问题。因果关系异常通常是逻辑连接错误或者模块方向接反。这些排查方法不需要你精通建模但需要你对模型的信号流有清晰的认识。3.3 高阶级能重构模型、能优化性能、能设计架构高阶级不是每个测试工程师都必须达到的但如果你想在HiL测试领域走得更远这个方向值得投入。高阶级的能力包括重构模型以提高可读性和可维护性、优化模型以满足实时性要求、设计模型架构以支持多项目复用。重构模型典型场景是模型太乱、太慢、太难维护。你可能需要把重复的逻辑封装成子系统或者库模块把复杂的嵌套结构打平把信号命名规范化把注释补全。这些工作看起来是建模工程师的活但测试工程师往往更清楚哪些部分需要重点监测、哪些部分容易出问题所以由测试工程师主导重构效果往往更好。优化性能核心是让模型能在实时仿真机上稳定运行。实时性要求模型的计算必须在每个采样周期内完成。如果模型太大、太复杂或者有代数环、过零检测、变步长求解器就可能导致超时。优化手段包括简化模型、降低采样率、用查表替代复杂计算、用定点数替代浮点数、消除代数环。这些优化需要你对模型的数值特性和实时系统的约束都有深入理解。设计架构是指从项目初期就考虑模型的可复用性和可扩展性。比如把被控对象模型按物理域拆分成独立的子系统把接口定义标准化把参数配置外置到数据字典。这样下一个项目来的时候你可以快速复用已有模型而不是从头搭建。这个能力需要你有多个项目的积累不是短期能练成的。4. 从零到合格一条可复现的学习路径4.1 第一阶段用两周时间打通基础操作如果你完全没接触过Simulink我建议用两周时间集中突破基础操作。第一周找一个简单的官方示例模型比如弹簧阻尼系统或者直流电机模型把它的每个模块都点开看一遍理解每个参数的含义。然后尝试修改参数观察仿真结果的变化。第二周自己从零搭一个简单的模型比如一个带PID控制的温度控制系统练习模块查找、连线、参数配置、仿真运行。这个阶段不需要追求深度重点是建立手感。就像学开车先熟悉方向盘、油门、刹车再去学倒车入库和高速并线。每天投入两小时两周下来你就能独立打开一个中等复杂度的模型知道从哪里看、从哪里改。4.2 第二阶段用一个月时间吃透一个真实项目模型基础操作打通后找一个你正在参与的HiL项目把它的被控对象模型完整地看一遍。不要只看你负责的那部分要看整个模型。看的时候带着问题这个模型的输入输出是什么它分几个子系统每个子系统对应什么物理过程哪些参数是标定参数哪些参数是结构参数看的过程中做笔记画一张信号流图。这张图不用很精确但要能反映出主要信号的来龙去脉。画完之后找建模工程师对一遍看看你理解得对不对。这个阶段的目标是当别人问你“这个模型里车速信号是怎么算出来的”你能在五分钟内找到对应的模块并解释清楚。4.3 第三阶段用持续实践积累定位经验前两个阶段是打基础第三个阶段是真正的能力积累。这个阶段没有明确的时间节点就是持续地在项目中实践。每次遇到问题都尝试从模型侧找原因。每次改模型都记录变更和影响。每次搭激励都尝试用更清晰、更可复用的方式实现。我自己的经验是定位模型问题的能力80%来自踩坑。你踩过的坑越多下次遇到类似问题的反应就越快。所以不要怕出问题出了问题才是学习的机会。但有一个前提每次问题解决后都要复盘。复盘的内容包括问题的根因是什么我是怎么找到的下次遇到类似问题有没有更快的定位路径这个复盘习惯比任何教程都管用。5. 实操现场一个激励模型搭建的完整过程5.1 需求拆解先想清楚要测什么假设我们要测试一个整车控制器在驾驶员急踩油门然后快速松开时的扭矩响应。这个测试的核心是模拟一个特定的驾驶员操作序列然后观察控制器的扭矩输出是否符合预期。需求拆解下来激励模型需要做三件事生成油门踏板信号、生成刹车踏板信号保持为零、生成挡位信号保持为前进挡。油门踏板信号需要模拟“急踩”和“快松”两个动作急踩的斜率、保持的时长、快松的斜率都是需要设计的参数。这个需求看起来简单但如果你直接在测试软件里写脚本也能实现。为什么要在Simulink里搭因为后续你可能需要把这个激励和模型里的其他状态联动比如当车速超过某个阈值时自动触发松开动作。这种联动在Simulink里实现起来更自然维护起来也更方便。5.2 模型搭建从信号源到总线输出搭建过程从信号源开始。油门踏板信号我用Signal Editor来生成因为它可以直观地编辑时间-数值对而且支持多组信号切换。急踩阶段我设置从0到100%的斜率为每秒500%保持2秒然后以每秒300%的斜率降到0。刹车踏板信号用Constant模块值设为0。挡位信号也用Constant值设为3假设3代表前进挡。这三个信号生成后需要打包成总线信号发给被测控制器。总线信号的打包用Bus Creator模块按照控制器接口定义文档里的信号顺序和数据类型配置。配置总线的时候要特别注意数据类型控制器接口通常对数据类型有严格要求比如油门踏板信号是uint16范围0到1000对应0到100%。如果模型里输出的是double类型的0到1就需要做类型转换和标定。总线打包完成后接到实时仿真机的IO接口模块上。这个模块通常是仿真机厂商提供的自定义模块负责把模型里的信号映射到物理IO通道。配置IO模块时要确认通道号、电压范围、分辨率这些参数和实际接线一致。我见过因为通道号配错导致信号发到错误引脚的情况排查了半天才发现是模型配置的问题。5.3 参数标定与验证确保激励信号准确模型搭完不等于能用还需要验证激励信号是否准确。验证方法有两种一种是在Simulink里做离线仿真用Scope观察信号波形是否符合设计另一种是下载到实时仿真机后用示波器或者测试软件测量实际输出。两种方法都要做离线仿真验证逻辑实时测量验证物理输出。离线仿真时我习惯把关键信号都引到Scope上包括油门踏板信号、刹车踏板信号、挡位信号以及它们的总线打包后的信号。对比设计值和仿真值确认没有标定错误。实时测量时重点看信号的幅值、斜率、时序是否和离线仿真一致。如果实时测量的信号有延迟或者失真可能是IO模块的配置问题也可能是信号调理电路的问题。注意激励模型的验证不能只做一次。每次修改模型后都要重新验证。我习惯在模型里加一个自检子系统用Assertion模块检查关键信号是否在预期范围内。这样每次运行模型时如果信号异常仿真会直接报错而不是等到测试执行完才发现问题。6. 常见问题与排查技巧实录6.1 模型编译报错从错误信息定位问题编译报错是HiL测试工程师最常遇到的问题。常见的错误类型有几类模块不支持代码生成、数据类型不匹配、采样时间冲突、代数环。模块不支持代码生成通常是因为用了只有仿真才支持的模块比如Scope、Display、To Workspace。解决办法是把这些模块替换成支持代码生成的模块比如用Signal Logging替代To Workspace。数据类型不匹配通常是因为模型里混用了double和single或者定点数和浮点数混用。解决办法是统一数据类型或者在接口处做显式类型转换。采样时间冲突通常是因为模型里不同子系统的采样时间不一致而实时仿真机要求所有模块的采样时间必须是基础采样周期的整数倍。解决办法是检查每个子系统的采样时间设置确保它们兼容。代数环是Simulink里比较棘手的问题。当模块的输出直接或间接依赖于自身的输入时就形成了代数环。代数环会导致仿真无法求解或者求解结果不准确。解决办法是在环里插入Unit Delay或者Memory模块打破直接依赖。但插入延迟会改变模型的动态特性所以插入位置和延迟步长需要仔细设计。6.2 仿真结果异常从信号特征反推根因仿真结果异常的表现形式很多信号发散、信号恒定不变、信号有高频振荡、信号有低频漂移。不同的异常特征对应不同的根因。信号发散通常是求解器步长太大或者模型本身不稳定。信号恒定不变通常是信号源没启动、使能信号没给、或者模块被禁用。信号有高频振荡通常是采样时间太短导致数值噪声或者控制器参数太激进。信号有低频漂移通常是积分器饱和、或者模型里有未建模的慢动态。排查的时候我习惯从后往前查。先看最终输出信号再看中间信号最后看输入信号。如果中间信号正常但输出信号异常问题就在中间到输出之间的模块。如果输入信号正常但中间信号异常问题就在输入到中间之间的模块。这种二分法能快速缩小排查范围。6.3 实时性不足从模型复杂度找突破口实时性不足的表现是仿真机报超时错误或者仿真步长实际执行时间超过设定值。根因通常是模型太复杂、计算量太大。排查的时候先用仿真机的性能监测工具看每个子系统的执行时间找到最耗时的部分。然后针对性地优化如果是查表模块太多考虑合并表格或者降低表格分辨率如果是积分器太多考虑用离散积分替代连续积分如果是代数环导致求解器反复迭代考虑打破代数环。我处理过一个案例模型里有一个复杂的液压系统用了很多Simscape模块实时执行时间超标。后来把液压系统简化成查表模型精度损失在可接受范围内实时性问题就解决了。这个取舍需要和建模工程师、控制工程师一起评估不能测试工程师单方面决定。6.4 常见问题速查表问题现象可能根因排查方法解决措施编译报错模块不支持代码生成使用了仿真专用模块查看错误信息中的模块路径替换为支持代码生成的模块编译报错数据类型不匹配混用不同数据类型检查接口处的数据类型统一类型或显式转换编译报错采样时间冲突子系统采样时间不一致检查各子系统采样时间统一为基础采样周期的整数倍仿真结果发散步长太大或模型不稳定减小步长观察是否改善调整步长或修改模型仿真结果恒定不变信号源未启动或模块被禁用检查使能信号和模块状态启用信号源和模块实时性不足模型计算量太大用性能监测工具定位耗时模块简化模型或优化算法7. 我踩过的坑和给你的建议第一个坑是“以为模型是别人的事”。刚做HiL测试的时候我觉得模型是建模工程师的领地我只要会用测试软件就行。结果遇到模型相关的问题只能等建模工程师来支持项目进度完全受制于人。后来逼着自己学Simulink才发现很多问题其实很简单只是之前不懂所以觉得神秘。建议你从入职第一天就把模型当成自己的工具不要有心理边界。第二个坑是“改模型不记录”。有一次为了赶进度改了一个查表模块的数据没记录。两周后另一个测试用例出问题查了半天才发现是之前改的数据影响了这个用例。从那以后我养成了强制记录的习惯每次改模型都在变更日志里写清楚改了什么、为什么改、影响哪些用例。这个习惯救了我很多次。第三个坑是“过度依赖离线仿真”。离线仿真跑通了不代表实时仿真就能跑通。实时系统有采样周期约束、计算资源约束、IO延迟这些在离线仿真里体现不出来。我的经验是离线仿真只用来验证逻辑实时验证必须上台架。台架上跑一遍比离线跑十遍都管用。第四个坑是“忽视模型版本管理”。HiL项目里模型会频繁更新如果版本管理没做好很容易出现“昨天还能跑的用例今天跑不了”的情况。建议用Git或者SVN管理模型文件每次更新都打标签测试用例里记录对应的模型版本。这样出问题的时候可以快速回滚到之前的版本对比。最后分享一个小技巧在模型里加监测点。不要只依赖测试软件记录的信号在模型的关键节点上手动加Outport或者Signal Logging把中间信号也记录下来。这样出问题的时候你可以看到信号在模型内部的完整传播路径定位效率会高很多。这个技巧看起来简单但实际用起来效果非常好。8. 学到什么程度算合格一个自检清单说了这么多最后给一个自检清单你可以对照看看自己是否达到了合格水平。能独立打开一个中等复杂度的Simulink模型在半小时内理清它的主要信号流和子系统划分。能修改模型里的常用参数并判断修改是否会影响其他测试用例。能搭建包含时序逻辑和闭环反馈的激励模型并验证激励信号的准确性。能在模型编译报错时根据错误信息定位到具体模块和参数。能在仿真结果异常时从信号特征反推可能的根因并设计排查路径。能在问题定位时判断问题是否出在模型侧并给出初步的解决方向。如果这六条你都能做到那你在HiL测试工程师里已经属于中上水平了。如果还有几条做不到也不用着急这些都是靠项目积累出来的。我做了这么多年也不敢说对模型的理解有多深但至少遇到问题不慌了知道从哪里入手。这个“不慌”就是合格的标准。
阅读完成 · 觉得有帮助？
