拓冰网站定制 
1. 买HIL之前先搞清楚你到底在仿真什么1.1 被“实时”两个字带偏的采购逻辑很多人第一次接触HILHardware-in-the-Loop硬件在环实时仿真器是被供应商的PPT带进去的。满屏的“微秒级步长”“多核并行”“FPGA亚微秒解算”看完之后肾上腺素飙升觉得只要把这台机器搬回实验室所有控制器的测试问题都能迎刃而解。结果设备到了发现连最基本的电机模型都跑不稳步长稍微调小一点就报超时这时候才意识到——买之前根本没想清楚自己要仿真什么。HIL的核心价值在于“实时”两个字但“实时”不是指仿真器跑得快而是指仿真器的解算节拍必须和真实控制器的时间节拍严格对齐。真实ECU电子控制单元每1毫秒发一次CAN报文你的仿真器就必须在1毫秒内完成模型解算、IO刷新、报文收发这一整套动作晚一点点控制器收到的就是过期数据测试结果直接失真。所以选HIL的第一件事不是看参数表而是把你手头那个控制器的时序需求先列出来。我见过太多团队在选型时把注意力全放在“能跑多快”上却忽略了一个更根本的问题你的被控对象模型到底有多复杂一个简单的DC-DC变换器模型和一个完整的整车多体动力学模型对仿真器的需求完全是两个量级。前者可能一颗中端FPGA就能搞定后者没有多核CPU加FPGA协处理根本跑不动。所以我在实际项目里总结出一条经验先定模型再定步长最后才去看硬件。1.2 从Simulink模型到实时硬件的鸿沟大部分人的HIL之旅都是从Simulink开始的。在桌面环境里拖几个模块连上Scope点一下运行波形漂漂亮亮地出来了。然后你信心满满地把这个模型往HIL里一灌发现完全不是那么回事。桌面仿真可以慢慢算算一天也没人管你实时仿真必须在规定的时间窗口内算完算不完就溢出溢出就报错报错就停机。这个鸿沟主要体现在三个地方。第一是求解器的选择桌面仿真常用变步长求解器比如ode45它会根据模型动态自动调整步长精度高但时间不确定实时仿真必须用定步长求解器每一步的时间是固定的这就要求你对模型的刚性有充分认识步长选大了精度不够选小了算不完。第二是代数环的问题桌面仿真里Simulink会自动迭代求解代数环实时环境里这种迭代会直接导致超时必须在建模阶段就消除代数环。第三是连续状态的离散化实时仿真器本质上是在离散时间点上计算连续系统的近似解离散化方法的选择直接影响仿真精度和稳定性。我个人的做法是在把模型部署到HIL之前先在Simulink里用定步长求解器跑一遍把步长设成你打算在HIL上用的值看看结果能不能接受。如果桌面定步长跑出来的结果和变步长差很多那说明你的模型对步长敏感上HIL之后大概率会出问题。这一步花不了多少时间但能帮你省掉后面大量的调试功夫。1.3 汽车HIL和PIL测试的本质区别热搜词里出现了“汽车hil和pil测试”这两个概念经常被混在一起说但它们的定位完全不同。PILProcessor-in-the-Loop是把控制算法代码放到目标处理器上跑被控对象模型还在桌面环境里仿真主要验证的是代码在目标硬件上的执行效率和数值精度。HIL则是把真实的控制器硬件整个接进来仿真器负责模拟被控对象和传感器执行器接口验证的是控制器在接近真实工况下的行为。举个例子你开发了一个电机控制器PIL阶段你关心的是FOC算法在目标DSP上跑一次需要多少微秒定点化之后电流环的精度够不够。到了HIL阶段你关心的是当电机模型出现堵转、缺相、过压这些异常工况时控制器的保护逻辑能不能及时响应。两者的测试目的不同对仿真器的要求也不同。PIL对仿真器的实时性要求相对低一些因为被控对象模型不需要和真实硬件同步HIL则必须严格实时因为控制器的时序是硬的。选HIL的时候一定要想清楚你是要做控制器功能验证还是要做系统级集成测试。功能验证可能只需要几个IO通道和中等算力的仿真器系统级集成测试可能需要几十个CAN通道、多路模拟量采集和故障注入单元价格差好几倍。别为了“以后可能用得上”去买一堆用不着的接口电子设备贬值快得很。2. 实时仿真器的核心指标哪些是真门槛哪些是噱头2.1 步长、抖动和IO延迟三个被混淆的概念供应商在介绍产品时最喜欢说“我们的步长可以做到1微秒”。这句话本身没错但步长小不等于实时性好。真正决定HIL性能的是三个指标最小步长、步长抖动和IO延迟。最小步长是指仿真器能稳定运行的最短解算周期步长抖动是指实际解算周期与设定值之间的偏差IO延迟是指从仿真器计算出输出值到物理接口真正输出信号的时间。这三个指标里步长抖动往往被忽略但它对测试结果的影响最大。假设你的步长设定是100微秒但实际抖动有20微秒那控制器收到的信号时间戳就是不准的做高精度时序相关的测试时结果完全不可信。好的HIL仿真器抖动应该控制在步长的1%以内也就是100微秒步长下抖动不超过1微秒。IO延迟则取决于接口类型模拟量输出的延迟通常比数字量高因为要经过DAC转换和滤波。我在选型时会要求供应商提供实测的抖动数据而不是只看数据手册上的标称值。实测方法很简单让仿真器输出一个方波用示波器测量上升沿的时间间隔连续测几千个周期看时间间隔的分布。如果供应商不愿意提供这个测试那就要打个问号了。2.2 FPGA在HIL里到底扮演什么角色热搜词里FPGA出现了很多次从“fpga实现频率测量”到“fpga高速adc采样”说明大家对FPGA在仿真领域的应用很关注。在HIL仿真器里FPGA主要承担三类任务高速IO管理、亚微秒级模型解算和自定义协议实现。高速IO管理是最基础的比如PWM信号的采集和生成、编码器信号的解码、高速ADC数据的读取。这些任务对时间精度要求高用CPU做会被操作系统调度打断用FPGA做可以保证纳秒级的确定性。亚微秒级模型解算是指把电力电子、电机控制这类动态快的模型放到FPGA上跑步长可以做到100纳秒甚至更小。自定义协议实现是指一些非标接口比如特定客户的私CAN协议或者自定义的同步串行接口。但FPGA不是万能的。它的开发门槛高用Simulink的HDL Coder自动生成代码虽然方便但生成的代码效率和手写的有差距。而且FPGA的资源有限一个中端FPGA能容纳的模型规模是有限的复杂的电机模型加上逆变器模型可能就把DSP slice用完了。所以我的建议是只有确实需要亚微秒步长的场景才上FPGA一般的毫秒级测试用CPU就够了。别为了“看起来高级”去买带FPGA的型号多花的钱可能几年都用不上。2.3 从“能跑”到“跑得准”精度验证的实操方法仿真器买回来第一件事不是跑项目而是做精度验证。我通常分三步走。第一步是开环验证给仿真器输入一个已知的信号看输出是不是符合预期。比如给一个正弦波看输出的幅值、频率、相位对不对。这一步主要验证IO通道的精度和延迟。第二步是闭环验证把仿真器和真实控制器接起来跑一个简单的闭环控制比如直流电机的速度控制。用示波器同时测量控制器的PWM输出和仿真器的转速输出看响应曲线和理论计算是否一致。这一步能发现很多问题比如IO延迟导致的相位滞后、量化误差导致的稳态误差。第三步是对比验证把HIL的测试结果和台架测试结果做对比。这是最有说服力的验证但成本也最高。我一般会选一个典型的工况比如电机的阶跃响应分别在HIL和台架上做把两条曲线叠在一起看。如果差异在可接受范围内说明仿真器的精度满足要求。如果差异大就要分析是模型的问题还是仿真器的问题。注意精度验证一定要在项目开始前做不要等到项目中期才发现仿真器精度不够那时候换设备成本就大了。3. 选型时必须算清楚的三笔账3.1 算力账你的模型到底需要多少GFLOPS算力是HIL选型里最容易被忽悠的地方。供应商说“我们的处理器有10 GFLOPS的浮点算力”听起来很厉害但你的模型到底需要多少算力很少有人认真算过。我一般用这个经验公式来估算模型的计算量FLOPs/步乘以步长频率步/秒就是需要的持续算力。举个例子一个包含电机模型、逆变器模型和简单车辆动力学的模型假设每步需要5000次浮点运算步长是100微秒那需要的算力就是5000除以100微秒等于50 MFLOPS。这只是一个粗略估计实际还要考虑IO处理、通信协议栈的开销一般留2到3倍余量。所以这个模型需要150 MFLOPS左右的持续算力。市面上主流的HIL仿真器CPU算力都在几个GFLOPS以上跑这个模型绰绰有余。但问题在于模型的计算量不是均匀分布的。有些步可能只需要几百次运算有些步可能需要几万次。如果仿真器的算力是平均分配的遇到计算量大的步就会超时。所以选型时要关注仿真器的峰值算力和任务调度机制看它能不能处理计算量的突发。3.2 IO账通道数和电气特性哪个更重要IO通道数是最直观的参数但电气特性往往更关键。同样是模拟量输出有的仿真器输出范围是±10V有的是0到5V有的输出阻抗是50欧姆有的是100欧姆有的支持电流输出有的只支持电压输出。这些电气特性决定了你的仿真器能不能直接和被测控制器对接。我遇到过一个问题仿真器的模拟量输出范围是±10V但被测控制器的ADC输入范围是0到3.3V。直接接上去要么烧ADC要么信号被截断。解决办法是加信号调理电路但调理电路会引入额外的延迟和噪声。所以选型时一定要把被测控制器的IO电气特性列出来和仿真器的IO规格逐条对比。数字IO也有讲究。有的控制器要求PWM输入是高电平有效有的是低电平有效有的要求上升沿触发有的是下降沿触发。这些都可以在仿真器里配置但前提是仿真器的数字IO支持这些配置。另外数字IO的驱动能力也要注意有的仿真器数字输出是3.3V TTL电平驱动能力只有几毫安直接驱动光耦或者继电器可能不够。3.3 扩展账现在够用和三年后够用是两回事HIL仿真器不是消耗品买一台通常要用五到八年。所以选型时不能只看当前项目的需求还要考虑未来可能的变化。我一般会从三个维度来评估扩展性IO扩展、算力扩展和协议扩展。IO扩展看仿真器有没有空闲的插槽能不能加装新的IO板卡。算力扩展看仿真器支不支持多机级联能不能通过实时网络把多台仿真器连起来跑更大的模型。协议扩展看仿真器支不支持新的通信协议比如从CAN升级到CAN FD或者从以太网升级到车载以太网。这里有个经验如果预算允许IO通道数至少留30%的余量算力至少留50%的余量。因为项目需求往往会膨胀今天只需要20路模拟量输入明天可能就要加40路。如果仿真器没有余量就只能换设备那成本比一开始就买大一点的高多了。4. 实操从开箱到跑通第一个闭环的完整流程4.1 硬件上电前的检查清单新设备到了别急着上电。我一般会先做一遍外观检查看看机箱有没有运输损伤板卡有没有松动接口有没有氧化。然后对照装箱单清点配件特别是线缆和转接头这些东西容易漏发少了任何一个都可能耽误进度。上电之前还要确认供电电压和接地。HIL仿真器通常是220V交流供电但有些型号支持宽压输入。接地一定要做好仿真器的模拟地和数字地要分开走最后单点接地。接地不好会导致模拟量输出噪声大严重的时候会烧板卡。上电之后先别接被测控制器让仿真器空跑一段时间用手摸一下机箱温度用耳朵听一下风扇声音。如果温度过高或者风扇声音异常可能是散热有问题要联系供应商处理。空跑的时候可以打开仿真器的监控软件看看CPU占用率和内存占用率正常情况下应该在10%以下。4.2 Simulink模型改造的五个关键步骤把桌面Simulink模型改造成能跑在HIL上的实时模型我一般按这五步走。第一步是替换求解器。把变步长求解器换成定步长求解器步长设成你打算在HIL上用的值。这一步会暴露很多问题比如代数环、过零检测、连续状态过多等。第二步是离散化连续模块。Simulink里很多模块是连续的比如积分器、传递函数、状态空间。实时仿真器只能处理离散模型所以要用离散化的版本替换。Simulink提供了自动离散化的功能但自动离散化的结果不一定最优关键模块最好手动离散化。第三步是配置IO接口。把模型里的输入输出端口和仿真器的物理IO通道对应起来。这一步要注意信号类型和量程的匹配比如模型里的转速是弧度每秒但仿真器的模拟量输出是伏特中间要加比例换算。第四步是设置任务调度。实时仿真器通常支持多任务调度不同任务可以有不同的步长。比如电机模型用100微秒步长车辆动力学用1毫秒步长。合理划分任务可以降低算力需求。第五步是代码生成和部署。用Simulink Coder或者Embedded Coder把模型生成C代码然后编译下载到仿真器。这一步要注意代码生成配置比如是否支持浮点运算、是否使用查表优化等。4.3 第一个闭环测试直流电机速度控制跑通第一个闭环是HIL调试的里程碑。我一般选直流电机速度控制作为第一个测试用例因为它足够简单出了问题容易定位。硬件连接仿真器的模拟量输出接控制器的速度给定输入控制器的PWM输出接仿真器的数字量输入仿真器的模拟量输出接控制器的转速反馈输入。注意信号地和电源地要共地。模型配置电机模型用一阶惯性环节加饱和参数根据实际电机设置。PWM输入解码用仿真器自带的捕获模块测量占空比和频率。转速输出用一阶滤波模拟传感器的响应延迟。调试步骤先开环测试给控制器一个固定的速度给定看仿真器输出的转速是不是稳定在对应值。然后闭环测试给一个阶跃给定看转速响应曲线。如果响应曲线有振荡先检查PWM解码是否正确再检查模型参数是否合理。我踩过的一个坑是PWM解码的采样率不够。控制器的PWM频率是10kHz仿真器的数字输入采样率是100kHz理论上够用但实际解码出来的占空比有±2%的波动。后来把采样率提高到1MHz波动降到±0.1%。所以数字输入的采样率至少要是信号频率的50倍以上。4.4 常见报错和排查思路HIL调试过程中最常见的报错是“步长溢出”意思是模型在规定的步长内没算完。排查思路是先看CPU占用率如果接近100%说明算力不够要么优化模型要么加大步长如果CPU占用率不高但还溢出可能是某个任务被阻塞了检查IO访问和通信是否正常。第二个常见报错是“IO超时”意思是仿真器在规定时间内没收到IO数据。排查思路是先检查物理连接看线缆有没有松动再检查IO配置看通道号和信号类型对不对最后检查被测控制器看它是不是在正常工作。第三个常见报错是“数值溢出”意思是模型里出现了无穷大或者NaN。排查思路是先检查模型里有没有除以零或者开根号负数的情况再检查积分器有没有饱和限制最后检查离散化方法是否合适有些刚性系统用显式离散化会发散。提示每次修改模型后先做一次离线仿真确认结果正确再部署到HIL。直接改HIL上的模型很容易引入新问题而且排查起来更麻烦。5. 那些供应商不会告诉你的坑5.1 实时操作系统的调度抖动HIL仿真器跑的是实时操作系统但“实时”不等于“零抖动”。任何操作系统都有调度开销任务切换、中断处理、内存管理都会引入抖动。好的实时操作系统抖动在微秒级差的可能在几十微秒。这个抖动会直接叠加到仿真步长上影响测试精度。我实测过几款不同品牌的HIL仿真器在同样步长下抖动差异可以达到一个数量级。有的仿真器标称步长10微秒实测抖动有5微秒有的标称100微秒实测抖动只有1微秒。所以选型时不要只看标称步长一定要问实测抖动。降低抖动的方法有几个一是减少任务数量把能合并的任务合并二是提高任务优先级把关键任务的优先级设到最高三是关闭不必要的后台服务比如日志记录、远程监控等。但这些方法都有副作用比如关闭日志记录会影响问题排查所以要权衡。5.2 模型编译的隐藏时间成本从Simulink模型到HIL可执行文件中间要经过代码生成、编译、链接、下载几个步骤。这个过程的时间成本往往被低估。一个中等复杂度的模型代码生成可能要几分钟编译要十几分钟下载要几分钟。如果模型改一次就要走一遍这个流程一天下来改不了几次。我一般会建议团队搭建一个持续集成环境把模型编译自动化。每次提交模型后自动触发编译编译结果自动部署到测试台架。这样开发人员只需要关注模型本身不用等编译。另外代码生成的配置也很关键开启并行编译、增量编译可以显著缩短编译时间。还有一个隐藏成本是模型版本管理。HIL上跑的模型版本和Simulink里的模型版本必须严格对应否则测试结果不可追溯。我见过一个团队因为模型版本混乱导致测试报告和实际模型对不上最后不得不重新跑一遍所有测试。所以从项目一开始就要建立模型版本管理制度每次部署都记录模型版本号和编译时间。5.3 故障注入功能的真实价值故障注入是HIL的一个重要功能可以模拟传感器故障、执行器故障、通信故障等异常工况。但很多团队买了带故障注入的仿真器却从来没用过。原因一是不知道怎么用二是觉得手动拔线也能模拟故障。手动拔线确实能模拟断路故障但模拟不了间歇性故障、参数漂移故障和复合故障。比如模拟一个传感器信号偶尔跳变手动操作根本做不到必须用故障注入单元。而且故障注入可以精确控制故障的发生时刻和持续时间这对于测试控制器的故障诊断逻辑非常重要。我建议在选型时把故障注入作为必选项但不要追求功能大而全。常用的故障类型就那几种开路、短路到地、短路到电源、信号偏移、信号卡滞。支持这几种就够了太复杂的故障类型可能几年都用不上。另外故障注入单元的通道数要和IO通道数匹配否则想注入故障的通道没有故障注入功能就尴尬了。5.4 技术支持和备件供应的长期考量HIL仿真器是精密设备出了问题往往需要供应商支持。选型时一定要考察供应商的技术支持能力响应时间多长有没有本地技术支持团队能不能提供远程协助。我遇到过一个问题仿真器的一个IO板卡坏了供应商在国内没有备件要从国外调货等了两个月。这两个月项目完全停摆损失远超过板卡本身的价值。备件供应也是长期考量。仿真器的生命周期通常是五到八年但供应商可能三五年就停产了。停产之后备件供应就成了问题。所以选型时要问清楚供应商的产品路线图看这个型号还能供货多久备件能供应多久。如果可能的话关键备件比如IO板卡、电源模块在采购时多买一套放着。注意不要只看价格选最便宜的供应商。HIL仿真器是长期投资技术支持和备件供应比初始价格重要得多。6. 不同预算下的选型策略6.1 入门级方案单机箱加基础IO预算在二十万以内的基本只能选入门级方案。这类方案通常是一个紧凑型机箱内置一个多核CPU配基本的模拟量和数字量IO。算力在1 GFLOPS左右步长最小可以做到50微秒适合跑一些简单的模型比如DC-DC变换器、小功率电机控制。入门级方案的优点是价格低、体积小、上手快。缺点是扩展性差IO通道数有限算力余量小。如果项目需求稍微复杂一点可能就捉襟见肘了。我一般建议入门级方案只用于教学或者预研不要用于正式的产品开发。选入门级方案时要注意有些低价产品用的是非实时操作系统抖动很大根本不能做HIL。判断方法很简单问供应商要操作系统的名称和版本查一下这个系统是不是实时系统。另外入门级方案的IO精度往往不高模拟量输出的精度可能只有12位对于需要高精度模拟的场景不够用。6.2 主流级方案多核CPU加FPGA协处理预算在五十万到一百万之间的可以选主流级方案。这类方案通常是多核CPU加FPGA协处理器算力在10 GFLOPS以上步长最小可以做到1微秒IO通道数在100路以上。适合跑电机控制、车辆动力学、电力电子等中等复杂度的模型。主流级方案的关键是CPU和FPGA的任务划分。CPU负责慢速的模型解算和通信管理FPGA负责高速IO和快速模型解算。划分得好整体性能可以提升好几倍划分得不好FPGA反而会成为瓶颈。我一般建议把步长小于10微秒的模型放到FPGA上步长大于10微秒的放到CPU上。选主流级方案时要重点关注FPGA的资源。不同型号的FPGA逻辑资源、DSP slice数量、内存大小差别很大。如果FPGA资源不够模型就放不进去只能退回CPU跑性能优势就没了。所以选型时要让供应商提供FPGA的资源使用报告看你的模型能不能放进去。6.3 高端方案分布式多机箱级联预算在一百万以上的可以选高端方案。这类方案通常是多台仿真器通过实时网络级联每台负责一部分模型整体算力可以做到几十甚至上百GFLOPS。适合跑整车级模型、大规模电力系统模型等复杂场景。高端方案的关键是实时网络的同步性能。多台仿真器之间要交换数据如果网络延迟大或者同步不好整体仿真精度就会下降。好的实时网络延迟在微秒级同步误差在纳秒级。选型时要问清楚网络协议和同步机制最好能提供实测数据。高端方案的另一个问题是复杂度高。多台仿真器的配置、调试、维护都比单机复杂得多。需要专门的团队来管理对人员的技术能力要求也高。我见过一些团队买了高端方案但因为没人会用最后只当单机用浪费了大部分性能。所以选高端方案之前先评估一下团队的技术能力。6.4 二手设备和租赁两个被低估的选项如果预算实在紧张可以考虑二手设备或者租赁。二手HIL仿真器的价格通常是新机的三到五折性能可能只落后一两代对于很多应用来说完全够用。但买二手设备要注意几点一是确认设备来源避免买到问题设备二是检查IO板卡的磨损情况特别是经常插拔的接口三是确认软件授权能不能转移有些供应商的软件授权是绑定硬件的。租赁适合短期项目或者预研阶段。租赁的好处是不用一次性投入大笔资金而且可以随时升级到最新型号。缺点是长期租赁的总成本可能超过购买而且租赁的设备通常不能定制。我一般建议项目周期在一年以内的考虑租赁超过一年的考虑购买。提示无论买新机、二手还是租赁都要在合同里明确技术支持和培训条款。HIL仿真器的学习曲线不低没有供应商的支持上手会很慢。7. 从选型到落地的个人经验7.1 先租后买用项目验证设备我现在的做法是在正式采购之前先租一台目标型号的仿真器用实际项目跑一遍。租期一般一个月足够完成一个完整的测试循环。这样做的好处是你能真实感受到设备的性能、稳定性和易用性而不是只看供应商的演示。演示环境都是精心调过的实际项目里会遇到各种意想不到的问题。租用期间要重点测试几个方面一是模型部署的便捷性从Simulink到HIL的流程顺不顺二是长时间运行的稳定性连续跑24小时看会不会出问题三是技术支持的响应速度遇到问题能不能及时解决。这些体验是参数表上看不到的但直接影响后续的使用体验。如果租用下来满意再谈采购。这时候你已经有实际使用数据了谈判的时候也更有底气。如果租用下来不满意换一家再租损失也就是一个月的租金比买错了设备再换的成本低多了。7.2 让实际使用人参与选型很多团队的选型是领导拍板实际使用人没有发言权。这是大忌。领导关注的是价格、品牌、参数实际使用人关注的是好不好用、稳不稳定、能不能解决问题。两者的视角完全不同。我见过一个团队买了某国际大牌的仿真器参数很漂亮但实际使用人发现软件界面反人类建一个简单的模型要花半天时间最后设备闲置了。所以选型时一定要让实际使用人参与最好让他们上手试用。试用的时候不要只跑供应商提供的demo要跑自己的模型。自己的模型才能暴露真实的问题。另外试用的时候要记录操作步骤和遇到的问题这些记录是选型决策的重要依据。7.3 预留培训和技术支持预算HIL仿真器不是买回来就能用的需要培训。培训包括两个方面一是设备操作培训怎么配置IO、怎么部署模型、怎么排查问题二是建模培训怎么把桌面模型改造成实时模型、怎么优化模型性能。这两方面的培训都很重要缺一不可。培训预算一般占设备采购预算的5%到10%。有些供应商会提供免费的基础培训但深度培训通常要收费。我建议在采购合同里明确培训内容和时长最好能到供应商的培训中心做一次系统培训然后再让供应商的技术人员到现场做一次实操指导。技术支持预算也要预留。设备用久了难免出问题出问题就需要技术支持。有些供应商的技术支持是免费的有些是按次收费的。采购时要问清楚技术支持的政策最好能签一个年度技术支持合同这样出了问题有保障。7.4 建立内部知识库避免人员流动导致能力断层HIL仿真器的使用经验是很宝贵的但这些经验往往存在个人脑子里人员一流动就流失了。我建议从项目一开始就建立内部知识库把设备配置、模型改造、问题排查的经验都记录下来。知识库的形式可以很简单一个共享文件夹加一个Wiki就够了。知识库的内容包括设备配置文档记录IO通道分配、网络配置、软件版本等信息模型改造指南记录从Simulink到HIL的改造步骤和注意事项问题排查手册记录遇到过的报错和解决方法测试用例库记录常用的测试场景和预期结果。知识库要定期更新每次解决新问题后都要补充进去。另外知识库要有人维护不能建完就放着。我一般指定一个人负责知识库的维护每季度检查一次确保内容不过时。7.5 最后分享一个选型决策的检查清单我在每次选型时都会用这个检查清单过一遍确保没有遗漏。检查项关键问题权重模型复杂度最大模型的步长和算力需求是多少高IO需求需要多少路模拟量、数字量、通信接口高实时性最小步长和抖动要求是多少高扩展性未来三年IO和算力需要扩展多少中故障注入需要哪些故障类型多少通道中技术支持响应时间、本地支持能力、备件供应高软件生态是否支持Simulink是否有HDL Coder高预算设备、培训、技术支持的总预算高团队能力团队有没有FPGA和实时系统的经验中项目周期项目周期多长是否需要租赁低这个清单不是万能的但能帮你把关键问题都过一遍。选型最怕的就是漏项漏了一项可能在项目中期才发现那时候补救的成本就高了。我在实际项目里用这个清单至少避免了三次选型失误。希望对你也有用。 HIL实时仿真器选型指南：从模型复杂度到硬件配置的工程实践
1. 买HIL之前先搞清楚你到底在仿真什么1.1 被“实时”两个字带偏的采购逻辑很多人第一次接触HILHardware-in-the-Loop硬件在环实时仿真器是被供应商的PPT带进去的。满屏的“微秒级步长”“多核并行”“FPGA亚微秒解算”看完之后肾上腺素飙升觉得只要把这台机器搬回实验室所有控制器的测试问题都能迎刃而解。结果设备到了发现连最基本的电机模型都跑不稳步长稍微调小一点就报超时这时候才意识到——买之前根本没想清楚自己要仿真什么。HIL的核心价值在于“实时”两个字但“实时”不是指仿真器跑得快而是指仿真器的解算节拍必须和真实控制器的时间节拍严格对齐。真实ECU电子控制单元每1毫秒发一次CAN报文你的仿真器就必须在1毫秒内完成模型解算、IO刷新、报文收发这一整套动作晚一点点控制器收到的就是过期数据测试结果直接失真。所以选HIL的第一件事不是看参数表而是把你手头那个控制器的时序需求先列出来。我见过太多团队在选型时把注意力全放在“能跑多快”上却忽略了一个更根本的问题你的被控对象模型到底有多复杂一个简单的DC-DC变换器模型和一个完整的整车多体动力学模型对仿真器的需求完全是两个量级。前者可能一颗中端FPGA就能搞定后者没有多核CPU加FPGA协处理根本跑不动。所以我在实际项目里总结出一条经验先定模型再定步长最后才去看硬件。1.2 从Simulink模型到实时硬件的鸿沟大部分人的HIL之旅都是从Simulink开始的。在桌面环境里拖几个模块连上Scope点一下运行波形漂漂亮亮地出来了。然后你信心满满地把这个模型往HIL里一灌发现完全不是那么回事。桌面仿真可以慢慢算算一天也没人管你实时仿真必须在规定的时间窗口内算完算不完就溢出溢出就报错报错就停机。这个鸿沟主要体现在三个地方。第一是求解器的选择桌面仿真常用变步长求解器比如ode45它会根据模型动态自动调整步长精度高但时间不确定实时仿真必须用定步长求解器每一步的时间是固定的这就要求你对模型的刚性有充分认识步长选大了精度不够选小了算不完。第二是代数环的问题桌面仿真里Simulink会自动迭代求解代数环实时环境里这种迭代会直接导致超时必须在建模阶段就消除代数环。第三是连续状态的离散化实时仿真器本质上是在离散时间点上计算连续系统的近似解离散化方法的选择直接影响仿真精度和稳定性。我个人的做法是在把模型部署到HIL之前先在Simulink里用定步长求解器跑一遍把步长设成你打算在HIL上用的值看看结果能不能接受。如果桌面定步长跑出来的结果和变步长差很多那说明你的模型对步长敏感上HIL之后大概率会出问题。这一步花不了多少时间但能帮你省掉后面大量的调试功夫。1.3 汽车HIL和PIL测试的本质区别热搜词里出现了“汽车hil和pil测试”这两个概念经常被混在一起说但它们的定位完全不同。PILProcessor-in-the-Loop是把控制算法代码放到目标处理器上跑被控对象模型还在桌面环境里仿真主要验证的是代码在目标硬件上的执行效率和数值精度。HIL则是把真实的控制器硬件整个接进来仿真器负责模拟被控对象和传感器执行器接口验证的是控制器在接近真实工况下的行为。举个例子你开发了一个电机控制器PIL阶段你关心的是FOC算法在目标DSP上跑一次需要多少微秒定点化之后电流环的精度够不够。到了HIL阶段你关心的是当电机模型出现堵转、缺相、过压这些异常工况时控制器的保护逻辑能不能及时响应。两者的测试目的不同对仿真器的要求也不同。PIL对仿真器的实时性要求相对低一些因为被控对象模型不需要和真实硬件同步HIL则必须严格实时因为控制器的时序是硬的。选HIL的时候一定要想清楚你是要做控制器功能验证还是要做系统级集成测试。功能验证可能只需要几个IO通道和中等算力的仿真器系统级集成测试可能需要几十个CAN通道、多路模拟量采集和故障注入单元价格差好几倍。别为了“以后可能用得上”去买一堆用不着的接口电子设备贬值快得很。2. 实时仿真器的核心指标哪些是真门槛哪些是噱头2.1 步长、抖动和IO延迟三个被混淆的概念供应商在介绍产品时最喜欢说“我们的步长可以做到1微秒”。这句话本身没错但步长小不等于实时性好。真正决定HIL性能的是三个指标最小步长、步长抖动和IO延迟。最小步长是指仿真器能稳定运行的最短解算周期步长抖动是指实际解算周期与设定值之间的偏差IO延迟是指从仿真器计算出输出值到物理接口真正输出信号的时间。这三个指标里步长抖动往往被忽略但它对测试结果的影响最大。假设你的步长设定是100微秒但实际抖动有20微秒那控制器收到的信号时间戳就是不准的做高精度时序相关的测试时结果完全不可信。好的HIL仿真器抖动应该控制在步长的1%以内也就是100微秒步长下抖动不超过1微秒。IO延迟则取决于接口类型模拟量输出的延迟通常比数字量高因为要经过DAC转换和滤波。我在选型时会要求供应商提供实测的抖动数据而不是只看数据手册上的标称值。实测方法很简单让仿真器输出一个方波用示波器测量上升沿的时间间隔连续测几千个周期看时间间隔的分布。如果供应商不愿意提供这个测试那就要打个问号了。2.2 FPGA在HIL里到底扮演什么角色热搜词里FPGA出现了很多次从“fpga实现频率测量”到“fpga高速adc采样”说明大家对FPGA在仿真领域的应用很关注。在HIL仿真器里FPGA主要承担三类任务高速IO管理、亚微秒级模型解算和自定义协议实现。高速IO管理是最基础的比如PWM信号的采集和生成、编码器信号的解码、高速ADC数据的读取。这些任务对时间精度要求高用CPU做会被操作系统调度打断用FPGA做可以保证纳秒级的确定性。亚微秒级模型解算是指把电力电子、电机控制这类动态快的模型放到FPGA上跑步长可以做到100纳秒甚至更小。自定义协议实现是指一些非标接口比如特定客户的私CAN协议或者自定义的同步串行接口。但FPGA不是万能的。它的开发门槛高用Simulink的HDL Coder自动生成代码虽然方便但生成的代码效率和手写的有差距。而且FPGA的资源有限一个中端FPGA能容纳的模型规模是有限的复杂的电机模型加上逆变器模型可能就把DSP slice用完了。所以我的建议是只有确实需要亚微秒步长的场景才上FPGA一般的毫秒级测试用CPU就够了。别为了“看起来高级”去买带FPGA的型号多花的钱可能几年都用不上。2.3 从“能跑”到“跑得准”精度验证的实操方法仿真器买回来第一件事不是跑项目而是做精度验证。我通常分三步走。第一步是开环验证给仿真器输入一个已知的信号看输出是不是符合预期。比如给一个正弦波看输出的幅值、频率、相位对不对。这一步主要验证IO通道的精度和延迟。第二步是闭环验证把仿真器和真实控制器接起来跑一个简单的闭环控制比如直流电机的速度控制。用示波器同时测量控制器的PWM输出和仿真器的转速输出看响应曲线和理论计算是否一致。这一步能发现很多问题比如IO延迟导致的相位滞后、量化误差导致的稳态误差。第三步是对比验证把HIL的测试结果和台架测试结果做对比。这是最有说服力的验证但成本也最高。我一般会选一个典型的工况比如电机的阶跃响应分别在HIL和台架上做把两条曲线叠在一起看。如果差异在可接受范围内说明仿真器的精度满足要求。如果差异大就要分析是模型的问题还是仿真器的问题。注意精度验证一定要在项目开始前做不要等到项目中期才发现仿真器精度不够那时候换设备成本就大了。3. 选型时必须算清楚的三笔账3.1 算力账你的模型到底需要多少GFLOPS算力是HIL选型里最容易被忽悠的地方。供应商说“我们的处理器有10 GFLOPS的浮点算力”听起来很厉害但你的模型到底需要多少算力很少有人认真算过。我一般用这个经验公式来估算模型的计算量FLOPs/步乘以步长频率步/秒就是需要的持续算力。举个例子一个包含电机模型、逆变器模型和简单车辆动力学的模型假设每步需要5000次浮点运算步长是100微秒那需要的算力就是5000除以100微秒等于50 MFLOPS。这只是一个粗略估计实际还要考虑IO处理、通信协议栈的开销一般留2到3倍余量。所以这个模型需要150 MFLOPS左右的持续算力。市面上主流的HIL仿真器CPU算力都在几个GFLOPS以上跑这个模型绰绰有余。但问题在于模型的计算量不是均匀分布的。有些步可能只需要几百次运算有些步可能需要几万次。如果仿真器的算力是平均分配的遇到计算量大的步就会超时。所以选型时要关注仿真器的峰值算力和任务调度机制看它能不能处理计算量的突发。3.2 IO账通道数和电气特性哪个更重要IO通道数是最直观的参数但电气特性往往更关键。同样是模拟量输出有的仿真器输出范围是±10V有的是0到5V有的输出阻抗是50欧姆有的是100欧姆有的支持电流输出有的只支持电压输出。这些电气特性决定了你的仿真器能不能直接和被测控制器对接。我遇到过一个问题仿真器的模拟量输出范围是±10V但被测控制器的ADC输入范围是0到3.3V。直接接上去要么烧ADC要么信号被截断。解决办法是加信号调理电路但调理电路会引入额外的延迟和噪声。所以选型时一定要把被测控制器的IO电气特性列出来和仿真器的IO规格逐条对比。数字IO也有讲究。有的控制器要求PWM输入是高电平有效有的是低电平有效有的要求上升沿触发有的是下降沿触发。这些都可以在仿真器里配置但前提是仿真器的数字IO支持这些配置。另外数字IO的驱动能力也要注意有的仿真器数字输出是3.3V TTL电平驱动能力只有几毫安直接驱动光耦或者继电器可能不够。3.3 扩展账现在够用和三年后够用是两回事HIL仿真器不是消耗品买一台通常要用五到八年。所以选型时不能只看当前项目的需求还要考虑未来可能的变化。我一般会从三个维度来评估扩展性IO扩展、算力扩展和协议扩展。IO扩展看仿真器有没有空闲的插槽能不能加装新的IO板卡。算力扩展看仿真器支不支持多机级联能不能通过实时网络把多台仿真器连起来跑更大的模型。协议扩展看仿真器支不支持新的通信协议比如从CAN升级到CAN FD或者从以太网升级到车载以太网。这里有个经验如果预算允许IO通道数至少留30%的余量算力至少留50%的余量。因为项目需求往往会膨胀今天只需要20路模拟量输入明天可能就要加40路。如果仿真器没有余量就只能换设备那成本比一开始就买大一点的高多了。4. 实操从开箱到跑通第一个闭环的完整流程4.1 硬件上电前的检查清单新设备到了别急着上电。我一般会先做一遍外观检查看看机箱有没有运输损伤板卡有没有松动接口有没有氧化。然后对照装箱单清点配件特别是线缆和转接头这些东西容易漏发少了任何一个都可能耽误进度。上电之前还要确认供电电压和接地。HIL仿真器通常是220V交流供电但有些型号支持宽压输入。接地一定要做好仿真器的模拟地和数字地要分开走最后单点接地。接地不好会导致模拟量输出噪声大严重的时候会烧板卡。上电之后先别接被测控制器让仿真器空跑一段时间用手摸一下机箱温度用耳朵听一下风扇声音。如果温度过高或者风扇声音异常可能是散热有问题要联系供应商处理。空跑的时候可以打开仿真器的监控软件看看CPU占用率和内存占用率正常情况下应该在10%以下。4.2 Simulink模型改造的五个关键步骤把桌面Simulink模型改造成能跑在HIL上的实时模型我一般按这五步走。第一步是替换求解器。把变步长求解器换成定步长求解器步长设成你打算在HIL上用的值。这一步会暴露很多问题比如代数环、过零检测、连续状态过多等。第二步是离散化连续模块。Simulink里很多模块是连续的比如积分器、传递函数、状态空间。实时仿真器只能处理离散模型所以要用离散化的版本替换。Simulink提供了自动离散化的功能但自动离散化的结果不一定最优关键模块最好手动离散化。第三步是配置IO接口。把模型里的输入输出端口和仿真器的物理IO通道对应起来。这一步要注意信号类型和量程的匹配比如模型里的转速是弧度每秒但仿真器的模拟量输出是伏特中间要加比例换算。第四步是设置任务调度。实时仿真器通常支持多任务调度不同任务可以有不同的步长。比如电机模型用100微秒步长车辆动力学用1毫秒步长。合理划分任务可以降低算力需求。第五步是代码生成和部署。用Simulink Coder或者Embedded Coder把模型生成C代码然后编译下载到仿真器。这一步要注意代码生成配置比如是否支持浮点运算、是否使用查表优化等。4.3 第一个闭环测试直流电机速度控制跑通第一个闭环是HIL调试的里程碑。我一般选直流电机速度控制作为第一个测试用例因为它足够简单出了问题容易定位。硬件连接仿真器的模拟量输出接控制器的速度给定输入控制器的PWM输出接仿真器的数字量输入仿真器的模拟量输出接控制器的转速反馈输入。注意信号地和电源地要共地。模型配置电机模型用一阶惯性环节加饱和参数根据实际电机设置。PWM输入解码用仿真器自带的捕获模块测量占空比和频率。转速输出用一阶滤波模拟传感器的响应延迟。调试步骤先开环测试给控制器一个固定的速度给定看仿真器输出的转速是不是稳定在对应值。然后闭环测试给一个阶跃给定看转速响应曲线。如果响应曲线有振荡先检查PWM解码是否正确再检查模型参数是否合理。我踩过的一个坑是PWM解码的采样率不够。控制器的PWM频率是10kHz仿真器的数字输入采样率是100kHz理论上够用但实际解码出来的占空比有±2%的波动。后来把采样率提高到1MHz波动降到±0.1%。所以数字输入的采样率至少要是信号频率的50倍以上。4.4 常见报错和排查思路HIL调试过程中最常见的报错是“步长溢出”意思是模型在规定的步长内没算完。排查思路是先看CPU占用率如果接近100%说明算力不够要么优化模型要么加大步长如果CPU占用率不高但还溢出可能是某个任务被阻塞了检查IO访问和通信是否正常。第二个常见报错是“IO超时”意思是仿真器在规定时间内没收到IO数据。排查思路是先检查物理连接看线缆有没有松动再检查IO配置看通道号和信号类型对不对最后检查被测控制器看它是不是在正常工作。第三个常见报错是“数值溢出”意思是模型里出现了无穷大或者NaN。排查思路是先检查模型里有没有除以零或者开根号负数的情况再检查积分器有没有饱和限制最后检查离散化方法是否合适有些刚性系统用显式离散化会发散。提示每次修改模型后先做一次离线仿真确认结果正确再部署到HIL。直接改HIL上的模型很容易引入新问题而且排查起来更麻烦。5. 那些供应商不会告诉你的坑5.1 实时操作系统的调度抖动HIL仿真器跑的是实时操作系统但“实时”不等于“零抖动”。任何操作系统都有调度开销任务切换、中断处理、内存管理都会引入抖动。好的实时操作系统抖动在微秒级差的可能在几十微秒。这个抖动会直接叠加到仿真步长上影响测试精度。我实测过几款不同品牌的HIL仿真器在同样步长下抖动差异可以达到一个数量级。有的仿真器标称步长10微秒实测抖动有5微秒有的标称100微秒实测抖动只有1微秒。所以选型时不要只看标称步长一定要问实测抖动。降低抖动的方法有几个一是减少任务数量把能合并的任务合并二是提高任务优先级把关键任务的优先级设到最高三是关闭不必要的后台服务比如日志记录、远程监控等。但这些方法都有副作用比如关闭日志记录会影响问题排查所以要权衡。5.2 模型编译的隐藏时间成本从Simulink模型到HIL可执行文件中间要经过代码生成、编译、链接、下载几个步骤。这个过程的时间成本往往被低估。一个中等复杂度的模型代码生成可能要几分钟编译要十几分钟下载要几分钟。如果模型改一次就要走一遍这个流程一天下来改不了几次。我一般会建议团队搭建一个持续集成环境把模型编译自动化。每次提交模型后自动触发编译编译结果自动部署到测试台架。这样开发人员只需要关注模型本身不用等编译。另外代码生成的配置也很关键开启并行编译、增量编译可以显著缩短编译时间。还有一个隐藏成本是模型版本管理。HIL上跑的模型版本和Simulink里的模型版本必须严格对应否则测试结果不可追溯。我见过一个团队因为模型版本混乱导致测试报告和实际模型对不上最后不得不重新跑一遍所有测试。所以从项目一开始就要建立模型版本管理制度每次部署都记录模型版本号和编译时间。5.3 故障注入功能的真实价值故障注入是HIL的一个重要功能可以模拟传感器故障、执行器故障、通信故障等异常工况。但很多团队买了带故障注入的仿真器却从来没用过。原因一是不知道怎么用二是觉得手动拔线也能模拟故障。手动拔线确实能模拟断路故障但模拟不了间歇性故障、参数漂移故障和复合故障。比如模拟一个传感器信号偶尔跳变手动操作根本做不到必须用故障注入单元。而且故障注入可以精确控制故障的发生时刻和持续时间这对于测试控制器的故障诊断逻辑非常重要。我建议在选型时把故障注入作为必选项但不要追求功能大而全。常用的故障类型就那几种开路、短路到地、短路到电源、信号偏移、信号卡滞。支持这几种就够了太复杂的故障类型可能几年都用不上。另外故障注入单元的通道数要和IO通道数匹配否则想注入故障的通道没有故障注入功能就尴尬了。5.4 技术支持和备件供应的长期考量HIL仿真器是精密设备出了问题往往需要供应商支持。选型时一定要考察供应商的技术支持能力响应时间多长有没有本地技术支持团队能不能提供远程协助。我遇到过一个问题仿真器的一个IO板卡坏了供应商在国内没有备件要从国外调货等了两个月。这两个月项目完全停摆损失远超过板卡本身的价值。备件供应也是长期考量。仿真器的生命周期通常是五到八年但供应商可能三五年就停产了。停产之后备件供应就成了问题。所以选型时要问清楚供应商的产品路线图看这个型号还能供货多久备件能供应多久。如果可能的话关键备件比如IO板卡、电源模块在采购时多买一套放着。注意不要只看价格选最便宜的供应商。HIL仿真器是长期投资技术支持和备件供应比初始价格重要得多。6. 不同预算下的选型策略6.1 入门级方案单机箱加基础IO预算在二十万以内的基本只能选入门级方案。这类方案通常是一个紧凑型机箱内置一个多核CPU配基本的模拟量和数字量IO。算力在1 GFLOPS左右步长最小可以做到50微秒适合跑一些简单的模型比如DC-DC变换器、小功率电机控制。入门级方案的优点是价格低、体积小、上手快。缺点是扩展性差IO通道数有限算力余量小。如果项目需求稍微复杂一点可能就捉襟见肘了。我一般建议入门级方案只用于教学或者预研不要用于正式的产品开发。选入门级方案时要注意有些低价产品用的是非实时操作系统抖动很大根本不能做HIL。判断方法很简单问供应商要操作系统的名称和版本查一下这个系统是不是实时系统。另外入门级方案的IO精度往往不高模拟量输出的精度可能只有12位对于需要高精度模拟的场景不够用。6.2 主流级方案多核CPU加FPGA协处理预算在五十万到一百万之间的可以选主流级方案。这类方案通常是多核CPU加FPGA协处理器算力在10 GFLOPS以上步长最小可以做到1微秒IO通道数在100路以上。适合跑电机控制、车辆动力学、电力电子等中等复杂度的模型。主流级方案的关键是CPU和FPGA的任务划分。CPU负责慢速的模型解算和通信管理FPGA负责高速IO和快速模型解算。划分得好整体性能可以提升好几倍划分得不好FPGA反而会成为瓶颈。我一般建议把步长小于10微秒的模型放到FPGA上步长大于10微秒的放到CPU上。选主流级方案时要重点关注FPGA的资源。不同型号的FPGA逻辑资源、DSP slice数量、内存大小差别很大。如果FPGA资源不够模型就放不进去只能退回CPU跑性能优势就没了。所以选型时要让供应商提供FPGA的资源使用报告看你的模型能不能放进去。6.3 高端方案分布式多机箱级联预算在一百万以上的可以选高端方案。这类方案通常是多台仿真器通过实时网络级联每台负责一部分模型整体算力可以做到几十甚至上百GFLOPS。适合跑整车级模型、大规模电力系统模型等复杂场景。高端方案的关键是实时网络的同步性能。多台仿真器之间要交换数据如果网络延迟大或者同步不好整体仿真精度就会下降。好的实时网络延迟在微秒级同步误差在纳秒级。选型时要问清楚网络协议和同步机制最好能提供实测数据。高端方案的另一个问题是复杂度高。多台仿真器的配置、调试、维护都比单机复杂得多。需要专门的团队来管理对人员的技术能力要求也高。我见过一些团队买了高端方案但因为没人会用最后只当单机用浪费了大部分性能。所以选高端方案之前先评估一下团队的技术能力。6.4 二手设备和租赁两个被低估的选项如果预算实在紧张可以考虑二手设备或者租赁。二手HIL仿真器的价格通常是新机的三到五折性能可能只落后一两代对于很多应用来说完全够用。但买二手设备要注意几点一是确认设备来源避免买到问题设备二是检查IO板卡的磨损情况特别是经常插拔的接口三是确认软件授权能不能转移有些供应商的软件授权是绑定硬件的。租赁适合短期项目或者预研阶段。租赁的好处是不用一次性投入大笔资金而且可以随时升级到最新型号。缺点是长期租赁的总成本可能超过购买而且租赁的设备通常不能定制。我一般建议项目周期在一年以内的考虑租赁超过一年的考虑购买。提示无论买新机、二手还是租赁都要在合同里明确技术支持和培训条款。HIL仿真器的学习曲线不低没有供应商的支持上手会很慢。7. 从选型到落地的个人经验7.1 先租后买用项目验证设备我现在的做法是在正式采购之前先租一台目标型号的仿真器用实际项目跑一遍。租期一般一个月足够完成一个完整的测试循环。这样做的好处是你能真实感受到设备的性能、稳定性和易用性而不是只看供应商的演示。演示环境都是精心调过的实际项目里会遇到各种意想不到的问题。租用期间要重点测试几个方面一是模型部署的便捷性从Simulink到HIL的流程顺不顺二是长时间运行的稳定性连续跑24小时看会不会出问题三是技术支持的响应速度遇到问题能不能及时解决。这些体验是参数表上看不到的但直接影响后续的使用体验。如果租用下来满意再谈采购。这时候你已经有实际使用数据了谈判的时候也更有底气。如果租用下来不满意换一家再租损失也就是一个月的租金比买错了设备再换的成本低多了。7.2 让实际使用人参与选型很多团队的选型是领导拍板实际使用人没有发言权。这是大忌。领导关注的是价格、品牌、参数实际使用人关注的是好不好用、稳不稳定、能不能解决问题。两者的视角完全不同。我见过一个团队买了某国际大牌的仿真器参数很漂亮但实际使用人发现软件界面反人类建一个简单的模型要花半天时间最后设备闲置了。所以选型时一定要让实际使用人参与最好让他们上手试用。试用的时候不要只跑供应商提供的demo要跑自己的模型。自己的模型才能暴露真实的问题。另外试用的时候要记录操作步骤和遇到的问题这些记录是选型决策的重要依据。7.3 预留培训和技术支持预算HIL仿真器不是买回来就能用的需要培训。培训包括两个方面一是设备操作培训怎么配置IO、怎么部署模型、怎么排查问题二是建模培训怎么把桌面模型改造成实时模型、怎么优化模型性能。这两方面的培训都很重要缺一不可。培训预算一般占设备采购预算的5%到10%。有些供应商会提供免费的基础培训但深度培训通常要收费。我建议在采购合同里明确培训内容和时长最好能到供应商的培训中心做一次系统培训然后再让供应商的技术人员到现场做一次实操指导。技术支持预算也要预留。设备用久了难免出问题出问题就需要技术支持。有些供应商的技术支持是免费的有些是按次收费的。采购时要问清楚技术支持的政策最好能签一个年度技术支持合同这样出了问题有保障。7.4 建立内部知识库避免人员流动导致能力断层HIL仿真器的使用经验是很宝贵的但这些经验往往存在个人脑子里人员一流动就流失了。我建议从项目一开始就建立内部知识库把设备配置、模型改造、问题排查的经验都记录下来。知识库的形式可以很简单一个共享文件夹加一个Wiki就够了。知识库的内容包括设备配置文档记录IO通道分配、网络配置、软件版本等信息模型改造指南记录从Simulink到HIL的改造步骤和注意事项问题排查手册记录遇到过的报错和解决方法测试用例库记录常用的测试场景和预期结果。知识库要定期更新每次解决新问题后都要补充进去。另外知识库要有人维护不能建完就放着。我一般指定一个人负责知识库的维护每季度检查一次确保内容不过时。7.5 最后分享一个选型决策的检查清单我在每次选型时都会用这个检查清单过一遍确保没有遗漏。检查项关键问题权重模型复杂度最大模型的步长和算力需求是多少高IO需求需要多少路模拟量、数字量、通信接口高实时性最小步长和抖动要求是多少高扩展性未来三年IO和算力需要扩展多少中故障注入需要哪些故障类型多少通道中技术支持响应时间、本地支持能力、备件供应高软件生态是否支持Simulink是否有HDL Coder高预算设备、培训、技术支持的总预算高团队能力团队有没有FPGA和实时系统的经验中项目周期项目周期多长是否需要租赁低这个清单不是万能的但能帮你把关键问题都过一遍。选型最怕的就是漏项漏了一项可能在项目中期才发现那时候补救的成本就高了。我在实际项目里用这个清单至少避免了三次选型失误。希望对你也有用。