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

核心要点

• 软件在环 该方法适用于早期控制验证，因为它能快速发现逻辑问题，且能在较低的配置成本下支持广泛的回归测试。
• 一旦时序、I/O 和嵌入式接口能够改变控制器的行为，硬件在环（HI-LOOP）技术就变得必不可少。
• 当SIL、PIL和HIL在各个阶段共享模型、测试意图和通过标准时，团队才能获得最佳的验证流程。

当您面临的下一个风险涉及控制逻辑时，请选择软件在环 ；当您面临的下一个风险涉及时序、I/O和嵌入式集成时，请选择硬件在环（Hardware-in-the-Loop）。

当团队忙于争论标签，而非根据需要排查的故障来确定相应的测试阶段时，就会浪费时间。软件质量低下使美国在2020年至少损失了 2.08万亿美元。这个数字在此至关重要，因为缺陷发现过晚通常意味着需要返工、进度延误以及反复校准。有效的验证应按照从软件模型到编译代码再到硬件时序的顺序进行，以此以最小的阻力消除下一个风险。

SIL在物理I/O发生之前对控制行为进行验证

软件在环 在目标控制器或功率级送达试验台之前，先根据模拟的被控对象验证控制器逻辑。您可以将控制系统作为模型代码或主机软件运行。故障信息始终可见且易于追踪。SIL 适用于早期设计、标定和回归测试工作。

电机控制团队可以在变频器硬件接线之前，利用SIL来测试电流限制、转矩上升率以及故障恢复功能。这一点同样适用于必须抑制传感器噪声且不引起振荡的飞行控制律。每种失效情况都能追溯到相应的方程、增益或状态逻辑，您可以通过完全访问信号来检查这些内容。这种可视性大大缩短了用于推测行为偏离目标原因的时间。

SIL 还能以低成本实现反复测试。您可以在一夜之间运行数千种场景，修改一个参数，并在午餐前比较测试结果。当需求仍在确定中、代码每天都在更新时，这种速度尤为重要。而常规硬件会拖慢这一循环，因为每次重新测试都需要刷写设备、检查接线以及进入实验室。

HIL 在实时约束条件下对嵌入式接口进行验证

硬件在环（HIL）将实际控制器与实时运行的被控对象模型相连接，从而使您能够在与实际运行时相同的时序和I/O条件下验证软件的行为。验证重点由此从算法意图转向执行结果。HIL能够揭示未及时响应、信号处理错误以及接口故障等问题。

制动控制器就是一个很好的例子。系统模型将车轮转速、踏板输入和液压状态发送至电子控制单元（ECU），随后以严格的周期时序接收回阀体控制指令。2022年，美国机动车事故共造成42,514人丧生 2022年，美国。安全功能需要在车辆或赛道测试开始前，通过台架验证来发现时序和接口故障。

当你的主要未知因素处于软件与硬件的交界处时，HIL就变得至关重要。ADC量程调整、PWM延迟、CAN消息处理以及故障引脚响应，这些在桌面模型中往往看起来没问题，但在实验台上却会失败。正是这种差距，使得团队将HIL视为一种集成过滤器，而不仅仅是一个更先进的仿真器。它能为你提供证据，证明在时钟严格受限且信号为物理信号的情况下，控制器仍能正常工作。

时序精度是SIL与HIL之间的分界点

“软件在环 与硬件在环（Hardware-in-the-Loop）的主要区别在于确定性时序以及电气交互。”

SIL 在主机上通过灵活的执行方式对逻辑进行验证。HIL 则在固定的采样时间和物理接口条件下对执行过程进行验证。这一界限决定了您能够捕获哪些故障，又会遗漏哪些故障。

电池管理控制器能清晰地显示该线路的情况。电池均衡逻辑在SIL测试中可能表现得完美无缺，但在HIL测试期间，嵌入式单元仍可能出现中断定时处理不当或模拟前端缩放错误的情况。正因如此，定时精度才是决定性因素，而非模型名称或团队偏好。一旦时钟精度和物理接口影响到测试的通过与否，你就已经进入了HIL测试领域。

当代码变更的速度超过硬件访问速度时，SIL 才能发挥最佳效果

当软件版本更新速度超过您的测试台能够处理的范围时，SIL 便是最合适的首选方案。您无需等待电路板、线束或实验室测试槽，即可验证功能意图、调整参数并扩大回归测试覆盖率。这使得 SIL 成为设计迭代频繁时的务实之选。它让工程师能够专注于逻辑设计，而非设置工作带来的额外负担。

储能控制团队可以利用一个代表电池组和逆变器的系统模型，对充电限值、热阈值以及模式切换进行测试。新的控制分支在提交到版本控制系统当天即可进行验证。测试用例还可以与需求建立关联，因此一旦更新失败，系统会直接指向受影响的逻辑路径。一旦共享硬件测试台被纳入开发计划，这种开发周期就很难再实现了。

SIL 还适用于那些若在物理设备上强制执行会显得棘手或不安全的故障测试场景。您可以注入不可能出现的传感器尖峰、错误的状态估计或极端的负载过渡，而无需担心造成硬件损坏。这些情况能在接口开发工作开始前就对控制器进行优化。跳过这一阶段的团队通常会将基础逻辑故障推迟到后期的测试中，届时排查这些故障将耗费更多时间。

当集成风险转移到接口时，HIL便能发挥作用

当您面临的主要不确定性从软件逻辑转向时序、布线、总线和嵌入式I/O时，HIL测试便彰显其价值。当调度器、中断、换流器 以及通信功能同时运行时，测试台将验证控制器是否仍能正常工作。这与SIL测试所解答的问题不同。它测试的是系统在高压条件下的运行表现。

功率电子控制器很好地说明了这一点。栅极指令、跳闸信号和电流反馈在主机模型中看起来可能都很正常，但在测试台上却可能暴露出量程截断、采样延迟或死区时间处理不当等问题。传感器仿真还允许您注入线路故障、缺失脉冲或噪声测量数据，而无需冒高功率测试装置受损的风险。这些测试至关重要，因为接口故障往往隐藏得很深，直到控制器遇到物理信号路径时才会显现出来。

与仅使用广域仿真 相比，HIL还能更好地支持最终确认会议。您可以展示控制器引脚上的精确响应时间、总线负载以及故障恢复情况。这些证据有助于技术负责人判断系统是否已准备好进行台架试验、试验台测试或现场测试。虽然该方法的成本高于SIL，但当集成问题是导致延误的主要原因时，其投入便能获得回报。

PIL 在进行全面硬件集成之前会检查编译后的代码

“处理器在环”（Processor-in-the-Loop）位于软件模型与完整的硬件测试平台之间。它在目标处理器或代表该处理器的电路板上运行编译后的控制器代码，而被控对象仍保持在软件环境中。这可以揭示代码生成问题、数值差异以及基本的时序效应。PIL 能够验证编译后的代码是否仍符合模型设计意图。

定点控制子程序就是一种常见的情况。模型在浮点环境下可能表现良好，但一旦编译后的代码在处理器上运行，就会出现溢出、量化误差或调度器抖动等问题。PIL 能在您花费时间搭建完整的 HIL 测试平台之前就发现这种变化。对于自动编码的控制器而言，这尤其有用——这类控制器虽然模型看起来正确，但生成的实现方案仍需验证。

PIL 无法取代 HIL，因为它无法涵盖完整的电气 I/O 或台架级接口行为。不过，它能消除一个成本高昂且充满不确定性的中间层。善用 PIL 的团队在进入 HIL 阶段时，代码生成过程中的意外情况会更少，时序基准也会更清晰。这使得后续的集成工作范围更窄，调试也更容易。

工作流的连续性比任何单一测试阶段都更为重要

SIL、PIL 和 HIL 之间交接环节的失误，所浪费的时间比单个阶段内出现的不理想结果还要多。您需要一致的模型、可重复的测试用例以及可比的通过标准，这样每个阶段才能为验证提供依据，而不是导致返工。最完善的工作流程能够将设计意图从桌面端的仿真 一直保留到台架测试执行阶段。这种连续性正是进度纪律的来源。

一个控制团队可以在所有阶段保持一个 plant 模型、一个场景库和一套命名规则。在 SIL 阶段失败的扭矩限制测试，在PIL 和 HIL 阶段也应能被识别，而无需重新编写验收逻辑。OPAL-RT 能够满足这一执行需求，因为团队可以将基于模型的验证（仿真 ）工作直接迁移到实时测试平台，而无需每次都重建完整的工作流。这种连续性缩短了调试循环，并确保了不同工具和实验室之间的故障证据保持一致。

当测试链保持完整时，也能维护工程团队的信任。如果每个阶段采用不同的假设，团队就会在评审时围绕测试环境设置而非行为表现展开争论。清晰的连续性使问题上报变得更简单，因为每次失败都有可追溯的记录。这对实验室经理和技术负责人尤为重要，他们需要的是证据，而不仅仅是测试活动本身。

选择能够消除下一个风险的测试方法

“值得你花下一小时去尝试的方法，就是那种只需最少的准备工作就能揭示下一次失败的方法。”

正确的结论很简单：SIL用于逻辑和校准，PIL 用于编译代码检查，HIL 用于时序和接口验证。团队在选择下一阶段时，应根据失效模式而非惯例来决定，这样才能获得更好的结果。这种方法能使成本、实验室时间以及调试工作量保持协调一致。

• 当模型访问和场景规模最为关键时，请选择 SIL。
• 当生成的代码需要处理器级别的证明时，请选择 PIL。
• 当采样时间和物理I/O可能会影响结果时，请选择HIL。
• 只有在当前阶段消除了其主要不确定因素后，才能继续前进。
• 在各个阶段保持相同的测试意图，以确保证据的可比性。

一份严谨的验证计划在纸面上看起来可能平淡无奇，但在实际操作中却能节省最多时间。过早地将每个测试都放到硬件测试台上并不能带来成功，而在时序已成为主要风险后仍固守软件阶段也同样行不通。在这种背景下，OPAL-RT具有其合理性，因为有些团队需要在同一个执行流程中兼顾这两条路径——从早期的模型检查到严格的实时测试台。