2026年硬件在环（HIL）测试指南

核心要点

• HIL 的价值源于闭环，因为只有当被模拟的被控对象对其自身输出作出响应时，控制器才会揭示反馈不稳定性和保护故障。
• 在HIL之前，模型、软件和处理器在环中分别剔除了一类不确定性，因此跳过一个阶段只是将调试成本推迟到后续阶段，而非消除它。
• HIL结果的可靠性取决于系统模型和时间步长，这使得模型验证和版本控制与测试台上的硬件同样重要。

硬件在环测试将真实设备与它所控制的机器的实时仿真 形成闭环，从而使其表现与在最终产品中的表现完全一致。

仿真 在硬件预期的同一微秒内响应每一条指令，这正是HIL与仅回放预先记录轨迹的测试方案之间的区别。2025年，美国监管机构记录了997起安全召回事件，涉及超过3100万辆汽车；如此大规模的召回行动之所以成本高昂，是因为故障已经蔓延到实际使用环境中。如果能在测试台上发现，只需进行固件更新即可解决。

HIL是程序中模型与物理硬件最终必须达成一致的环节。若将其视为最后阶段的核对项，系统集成速度就会变慢；若将其视为对控制软件进行最严苛测试的阶段，那么最后几个月的工作节奏就会明显放缓。

“硬件在环”测试对工程师而言究竟意味着什么

硬件在环测试（Hardware in the Loop）是将真实控制器与仿真 中其连接的所有设备进行交互，双方均实时更新状态。被测单元向仿真器发送指令，仿真器计算出物理设备会如何响应，该响应再通过实际布线在固定的时间步长内返回。

电池管理控制器将这一构想付诸实践。无需将其连接到实际的电池组，而是将其连接到一个模拟器上，该模拟器能够模拟尚未组装的电池组的电芯电压、电流和温度。控制器会读取这些信号，就如同电芯就摆在它面前一样，从而决定何时接通接触器，而模拟器则会据此重新计算电池组的状态。

闭环才是关键所在。记录的波形虽然能证实控制器对输入信号作出了响应，但无法显示当控制器自身的输出改变了其所测量的系统时会发生什么。只有当被控对象产生反馈时，才会出现反馈不稳定性和相互抵消的保护逻辑。

“只有当被控对象作出响应时，才会出现反馈不稳定和自我冲突的保护逻辑。”

循环内部包含什么，以及什么会被保留下来仿真

回路内的物理硬件通常包括控制器、其输入和输出级以及生产固件。任何昂贵、危险或尚未建成的设备都位于仿真 中，这通常指的是工厂。两者之间设有一个信号调理层，以确保信号电平符合设备的要求。

一个电动驱动测试台展示了该线路通常的运行状态。牵引逆变器控制板是实体部件，而功率级、电机、负载和电池则位于仿真器中。控制器仍以10 kHz或更高的频率切换栅极信号，而仿真器必须对每个开关沿作出响应。

如何划定这条界限，将决定测试能证明什么以及所需成本。信号级HIL将所有参数维持在低电压、低电流状态，因此控制器接收到的只是真实物理量的毫伏级模拟信号。功率级HIL则将边界向外扩展并增加了一个放大级，从而允许真实的电机或并网变流器在额定功率下接入控制回路。这样就能捕捉到第一种方案永远无法捕捉的热行为。

HIL 与“模型在环”和“软件在环”有何区别

“硬件在环”（HIL）与其前几个阶段的主要区别在于实际存在的硬件。模型在环和软件在环完全在计算机上运行，因此它们是对逻辑进行测试，测试对象是数学模型化的被控对象。而HIL则增加了生产硬件、其时序特性及其电气接口。

这些阶段是顺序进行的，而非可选的。牵引控制策略首先以与车辆模型进行比对的框图形式出现，随后转化为编译后的代码，最后在目标处理器上执行。只有在完成这三个阶段后，最终的单元才能通过其自身的连接器与模拟车辆对接。

跳过某个阶段会白白浪费数周时间。一个在“模型在环”运行中几分钟就能发现的缺陷，一旦受到编译器行为、调度器抖动和信号调理的影响，就会演变成长达两天的调试过程。

工程师如何构建和布线硬件在环测试台

一个HIL测试台由四个部分组成。实时仿真器以固定的时间步长求解被控对象模型，输入和输出层负责在数字值与物理信号之间进行转换，布线和信号调理与该单元的引脚排列相匹配，而主机则存储模型和测试序列。

模型准备工作占用了大部分精力。各团队在Simulink中构建系统，然后通过OPAL-RT公司的RT-LAB等软件将其编译到仿真器目标平台，该软件负责管理CPU核心与FPGA之间的任务分配。 快速切换任务以亚微秒的时间步长在FPGA上执行，而机械和热力学动态则以50至100微秒的时间步长在CPU上处理。实验台规模取决于模型，因此OP4512机箱适用于单控制器系统，而OP5707XG则能满足多变流器系统所需的通道密度。

故障注入是大多数团队最容易低估的部分。通过在仿真器与设备之间的继电器组，你可以切断传感器线路、将信号短路至地，并观察诊断代码的响应。如果在真实硬件上进行此类操作，可能会导致设备损坏；而在行驶中的车辆上操作则存在安全隐患。而在试验台上，这只需运行一个脚本，过夜即可完成。

HIL测试在各工程行业中占据一席之地的原因

只要控制器需要控制那些成本高昂、制造周期长或一旦损坏便会造成严重后果的系统，HIL技术就会派上用场。汽车动力总成、飞机飞行控制、铁路牵引、电网换流器 以及工业驱动系统都依赖于它，而原因始终如一：物理测试样机数量稀缺，而控制软件却每周都在更新。

电力系统中这一趋势表现得尤为明显。在美国计划于2026年投产的86吉瓦新增发电容量中，太阳能、电池储能和风能占到了93%，而这些电厂均通过运行各自控制代码的逆变器接入电网。该代码中的抗故障运行或保护故障无法通过给带电馈线通电来检测，因此制造商转而使用模拟电网对控制系统进行测试。

航空航天领域在更严格的认证规则下同样遵循这一逻辑。飞行控制计算机基于模拟的气动数据和作动器模型进行运行，因此在飞行测试之前，会针对机翼表面卡死等故障进行数百次模拟演练。随后，飞行测试将验证台架试验已得出的结果。

导致HIL结果难以令人信服的常见错误

HIL测试中最令人失望的结果往往源于模型问题，而非硬件问题。一个运行平稳但无法准确反映实际工艺过程的测试台，可能会通过一个在实际运行中表现异常的控制器，而直到调试阶段，才有人发现这一问题。时间步长、信号保真度和模型验证决定了该测试的可信度。

有五种习惯导致了工程师日后不得不推翻的大部分结果。

• 在时间步长过粗（以至于超过控制器开关频率）的情况下运行 plant 模型
• 将仿真器的输入和输出视为理想状态，忽略传感器噪声、偏移量和接地路径
• 对系统模型进行一次验证后，就不再将其与实际硬件的测量结果进行比对
• 编写的测试用例仅覆盖正常运行情况，因此未引入降级模式
• 让测试平台与生产版本保持差异，从而确保被测单元并非最终出货的版本

每种情况的预防成本都很低，但若发现得太晚，代价却很高。在项目初期将您的仿真模型与实际设备进行对比，并在每次硬件版本更新后再次进行对比，这样才能确保测试结果的可靠性。模型和测试套件的版本控制与固件的版本控制同样重要，因为只有当您能明确指出具体运行了哪些内容时，通过测试的结果才具有实际意义。

“HIL测试中最令人失望的结果大多是模型问题，而非硬件问题。”

在整个项目中，有条不紊的HIL实践是怎样的

能够从HIL中获得持久价值的团队，会将测试平台视为一项永久性资产，而非一次性投入。测试模型随产品共同发展，测试套件随着每个现场问题的出现而不断扩展，且每次固件构建后都会进行回归测试。这种累积的测试覆盖率使得项目最后几个月的进展变得从容平稳。

成果并非一次惊人的发现，而是持续消除意外情况，从而使集成阶段成为验证过程，而非发现问题。 一个团队如果连续六个月每晚运行数千个自动化故障测试用例，那么在进行现场测试时，就已经清楚软件在极限条件下的表现，剩下的问题都是物理层面的。能否达到这一阶段，与其说取决于仿真器的规模，不如说取决于围绕仿真器所建立的严谨流程。处理特定控制问题的工程师可以向OPAL-RT申请HIL演示，并将自己的模型映射到测试台上。