面向工程师的“硬件在环”与“软件在环”指南

核心要点

• 软件在环 设计变更仍频繁发生时承担逻辑验证的早期工作，因为它能保持较高的测试覆盖率。
• 当目标硬件上的时序、电气输入输出以及控制器执行成为主要风险时，硬件在环（HIL）的高成本便物有所值。
• 共享模型基线比阶段偏好更为重要，因为模型对实物模型的拟合度较低会破坏两条测试路径。

软件在环 选择软件在环 SIL），只有在必须验证时序和输入/输出行为时，才转为“硬件在环”（HIL）。

该流程有助于减少浪费，因为软件在环 测试台、布线和故障注入硬件准备就绪之前，就为代码和控制逻辑软件在环 快速反馈。轻型车辆通常使用 70 至 100 个电子控制单元，因此在最终集成之前，分阶段验证至关重要。当每个测试阶段专注于验证特定风险，而非要求单一阶段解决所有问题时，您将获得最佳结果。

软件在环 目标硬件进入初始化阶段之前软件在环 控制器逻辑。”

SIL可在没有目标硬件的情况下测试软件行为

软件在环 在目标硬件进入初始化阶段之前，该方法会先对控制器逻辑进行验证。您将编译或解释执行的控制软件应用于模拟的被控对象模型。这使得该方法成为检测状态、限值和顺序故障最快捷的途径。但它无法验证最终控制器上的电气接口或硬时序。

牵引力控制算法便是很好的例子。你可以在工作站上，仅用数小时的时间，就将车轮转速输入值、滑移率估计值和扭矩请求值，与成千上万种路况和轮胎组合进行匹配。这能迅速揭示不合理的阈值、不稳定的增益选择或错误的故障锁定机制。由于你是在安全的数字环境中观察软件行为，因此修改成本低廉，测试覆盖率也能快速提升。

当您的设计仍处于每日迭代阶段时，这种速度至关重要。校准团队可以调整限值，软件团队可以修复逻辑缺陷，系统工程师则可确认预期的控制响应依然有效。如果过早将硬件投入测试台，实验室就会成为瓶颈，而任何布线或固件刷写问题都会占用本应用于实际验证的时间。SIL 作为逻辑可靠性的首道筛选机制效果最佳，尤其是在需求尚未最终确定时。

HIL测试通过物理输入输出通道验证控制行为

硬件在环（Hardware-in-the-loop）通过物理输入/输出通道对控制器进行测试，而被控对象则保持在仿真状态。控制器可以是实际生产设备，也可以是与其高度相似的目标板。这种测试方案能够揭示调度器抖动、信号缩放以及接口故障等问题。它能够解答那些软件在环 确切解答软件在环 、涉及硬件耦合的问题。

变频器控制器能清晰地展现这些差异。脉冲指令、模拟反馈、离散故障以及通信数据都会通过实际的电路路径传输，因此您可以直观地观察控制器如何应对时序偏差或噪声输入。在台架测试中，您会发现，即使软件逻辑此前看似正常，电流传感器偏移仍会导致保护跳闸。当台式测试掩盖了电气细节时，此类疏漏便屡见不鲜。

HIL 还能为您的团队提供一个共享平台，以便在原型车或测试台架准备就绪之前，对故障处理进行测试。您可以模拟传感器失效、总线错误和超出范围的数值，而无需冒损坏昂贵硬件的风险。实验室时间的成本更高，因此重点不仅在于测试量。关键在于通过有针对性的验证，确保当真实信号和硬件执行纳入控制回路后，控制器能够正确工作。

当设计变更频繁时，请从SIL开始

软件在环 您的控制器架构、需求或标定参数仍频繁变更软件在环 ，建议从软件在环 （SIL）开始。这种方法无需在实验台上进行返工即可吸收修改，并让工程师能够专注于控制质量。每次代码修订后，您都可以运行全面的回归测试。这使其成为设计不稳定阶段的理想起步阶段。

电动汽车的扭矩仲裁功能就符合这一模式。在早期版本中，功率限制、驾驶员需求、牵引限制和热降额参数往往会发生变化。您可以更新控制模型，重新运行相同的驾驶循环，并在当天比较其行为表现。如果使用硬件测试台，则会拖慢这一迭代周期，因为固件烧录、I/O 设置和实验室使用时间将占据大部分日程安排。

在此阶段，团队还能获得更清晰的反馈。如果测试在SIL阶段失败，通常能明确问题出在逻辑、数据处理或被控对象假设上，而非接线、调度器或模拟量缩放。这种清晰度有助于软件和控制团队在减少干扰的情况下加快工作进度。只有当逻辑足够稳定，且风险主要源于硬件问题而非设计变更时，才应结束SIL阶段。

当时间风险成为问题时，应转为HIL模式

软件在环 主要区别在于，HIL 能在目标时序和接口条件下验证系统行为。一旦逻辑运行稳定，执行时序便成为最重要的风险因素。HIL 能够展示控制器如何应对延迟、量化误差和信号调理。这正是台架测试物有所值的关键所在。

当扭矩和保护逻辑每周都会停止工作时，电动驱动控制器往往会进入这一阶段。2021年，轻型车辆平均使用了 949个半导体器件，因此接口时序和信号完整性很快将不再只是理论问题。HIL测试台会显示电流限制触发晚了一个采样周期，或者在受噪声干扰的传感器恢复后，故障位清除速度过慢。SIL测试很少能以足够的确定性揭示此类问题。

当集成团队需要验证软件和电子元件能否作为一个整体协同工作时，你也应及时采取行动。通信延迟、输入滤波、脉宽调制时序以及中断负载等因素都至关重要。如果拖延太久，发布前夕的台架测试就会堆积如山，而本应早些解决的逻辑错误却会耗费昂贵的硬件测试时间。合理的阶段规划能让HIL测试专注于验证时序和I/O，而非用于修复软件问题。

随着实验室规模的扩大，HIL的成本也随之增加

硬件在环（HIL）的成本更高，因为每次有价值的测试都依赖于硬件、接口板、测试台配置以及实验室协调工作。软件在环 消耗计算时间和建模工作量。HIL则增加了设备投资和人工配置时间。但这并不意味着HIL是可选的，您应当以更明确的目的来使用它。

• 工作台五金件需要购买、维护和备件。
• 信号调理和故障注入增加了设置的复杂性。
• 控制器闪烁和校准操作会占用技术人员的时间。
• 实验室的排程限制了同时进行测试的团队数量。
• 故障分析通常需要使用示波器并进行总线走线分析。

电池管理团队对此深有体会。在SIL环境中重新运行一次软件修订只需几分钟，而在测试台上进行同样的修改，一旦涉及通道映射、安全检查和数据采集，则可能需要数小时。如果问题涉及硬件响应，这种成本仍是合理的。只有当团队使用HIL来解答那些本可以通过工作站更快、更经济地解决的早期逻辑问题时，这种做法才显得浪费。

一个模型基线可确保两个测试阶段保持一致

共享的系统模型基准可确保软件在环 SIL软件在环 硬件在环”软件在环 HIL）软件在环 保持一致。您希望在从桌面验证到台架测试的过程中，始终采用相同的假设、接口和故障定义。这种连续性使故障更易于解读，同时也避免了工程师们就“哪种测试环境的结果更准确”而产生争论。

电机控制团队可以先针对桌面回归测试编译同一被控对象，随后在时间要求变得关键时，将其迁移到实时目标平台进行闭环台架测试。只要模型方程、信号名称和故障工况保持一致，测试意图也就保持一致。这样，您就可以将SIL阶段的通过结果与HIL阶段的失败结果进行对比，并快速确定是硬件时序还是电气I/O导致了这种差异。当团队需要在两个阶段使用相同的模型结构时，OPAL-RT非常适合这种工作流程。

应将模型治理视为测试策略的一部分，而非善后工作。版本控制、接口契约和可重复的测试向量能确保各环节的交接紧密衔接。若缺乏这种规范，SIL 和 HIL 将沦为各自为政、标准不一的独立项目。只有当两个阶段从一开始就使用相同的技术语言时，整合的工作流才能有效运作。

软件在环 负责验证逻辑可靠性，硬件在环（HIL）应负责验证硬件可靠性，二者都应基于一个您所信赖的系统模型。”

植物保真度低会导致两个测试阶段的结果都具有误导性

如果被控对象的建模精度不足软件在环 是在软件在环 硬件在环软件在环 ，都会误导您。一个不准确的模型可能会让不稳定的控制看起来很稳定，或者让运行正常的控制器显得失效。如果被控对象的物理特性建模有误，再漂亮的图表也无济于事。对工作流的信任始于对模型的信任。

忽略死区时间、传感器噪声或饱和现象的仿真模型是一个常见的陷阱。由于被控对象过于理想化，SIL仿真会显示出平滑的电流控制曲线。如果同样弱小的被控对象通过完美的通信通道将信号传给控制器，HIL仿真仍可能带来虚假的安全感。最终，你会发现自己是在用一个虚构的情景来验证控制器，然后在项目后期花费大量时间解释为何台架测试结果与系统实际行为不符。

这个有用的判断标准很简单：软件在环 负责验证逻辑正确性，硬件在环（HIL）应负责验证硬件正确性，二者都应基于一个值得信赖的被控对象模型。遵守这一原则的团队不仅能减少实验室时间的浪费，也能避免在讨论测试失败的原因上耗费过多精力。在注重一致性的场景中，OPAL-RT是最理想的选择，因为当模型质量被视为验证过程的有机组成部分而非事后考虑时，整个执行链才能保持其可靠性。