PIL 与 HIL

核心要点

• PIL 应在目标处理器上验证编译后的控制器软件，以免在集成阶段耗费宝贵的 HIL 测试台时间。
• 当时序、I/O 和接口行为成为主要剩余风险源时，HIL 便发挥其作用。
• 当保真度分阶段提升而非一次性提升时，团队能够更快地定位故障，并使验证进程更加平稳。

PIL 和 HIL 分别用于不同的验证任务，依次使用它们可以减少实验室调试工作，并提高可信度。

“处理器在环测试”是在完整的硬件测试平台准备就绪之前，在目标处理器上对编译后的控制器代码进行验证。现代车辆中可能包含约 1亿行代码，这说明了为何在软件开发后期才发现问题会浪费时间和金钱。“处理器在环”（PIL）与“硬件在环”（HIL）的主要区别很简单：PIL验证软件在处理器上的执行情况，而HIL则在时序和输入/输出约束条件下验证闭环系统的行为。PIL应首先排除软件故障，随后由HIL确认系统时序是否符合要求。

“在V模型中，PIL的阶段早于HIL，因为它能在硬件集成引入干扰之前，将软件执行进行隔离。”

“处理器在回路中”旨在实现编译后控制软件的行为

PIL 测试是在目标处理器上对编译后的控制软件进行测试，同时保持系统处于仿真状态。它能帮助您确认，无论是生成的代码还是手动编写的代码，在遇到生产控制器的实际指令集、数据类型、内存限制和调度器时序时，是否仍能正常运行。

电机控制团队可以在从控制模型生成代码后立即使用PIL。该软件在微控制器上运行，同时由模拟的电机和逆变器提供输入并接收输出。这种设置可以在功率级或传感器硬件就绪之前，就揭示出定点溢出、编译器副作用以及任务超时等问题。您不再仅依赖模型层面的结果。

这一点很重要，因为模型行为与处理器行为很少完全一致。数据类型转换、量化、中断负载以及编译器优化都会以桌面仿真 捕捉的方式改变结果。PIL 在测试平台其余部分仍处于虚拟状态时，能够隔离软件故障，从而使后续的验证工作能够专注于系统问题，而非基础代码缺陷。

硬件在环（HIL）旨在实现受硬件约束的闭环时序

HIL通过模拟被控对象和物理输入/输出接口，在闭环环境中对控制器硬件进行测试。它要解答的问题与 PIL 不同：实际控制器（包括其布线、传感器、总线和时序路径）在与高保真系统模型进行实时交互时，能否正确工作？

牵引逆变器控制器说明了这一点的重要性。该生产控制器从仿真器读取编码器脉冲、电流信号和故障输入，然后通过真实的I/O将栅极命令发回。此时，延迟、抖动、缩放误差和通信延迟都会影响稳定性和保护逻辑。这种级别的交互超出了“处理器在环”测试的范围。

HIL 在符合实际条件的约束下对系统集成进行验证。信号调理、总线流量、执行器饱和以及故障处理等因素均被纳入考量。您还将发现一些仅在多个子系统作为整体运行时才会出现的问题，例如 CAN 调度冲突或欠压后的复位行为。由于 HIL 需要更多的测试台时间和调试工作，因此当软件行为已经稳定，且后续风险主要集中在时序和接口方面时，HIL 才能发挥最佳效果。

V型模型将PIL置于HIL之前，以实现干净的隔离

在V模型中，PIL的实施时间早于HIL，因为它能在硬件集成引入干扰之前，将软件执行过程进行隔离。这种顺序安排能明确缺陷的责任归属。您可以先将故障归因于代码生成、处理器限制或调度选择，随后在未知因素较少的情况下，再转向系统时序和接口验证。

典型的流程是从“模型在环”（Model-in-the-Loop）开始，接着是“ 软件在环 ，然后是“过程在环”（PIL），最后是“硬件在环”（HIL）。电池管理控制器可以在PIL阶段就明确控制逻辑和处理器执行方式，从而避免团队将宝贵的HIL测试时间浪费在故障注入和电池组级接口时序上。这种顺序有助于节约实验室测试时间。

那些颠倒这一顺序的团队，往往会在HIL阶段花费大量时间去排查那些本应在PIL阶段就已暴露的问题。保持正确的测试顺序能确保因果关系的清晰，从而使故障诊断更快捷、修复更轻松。

当代码成熟度超过硬件可用性时，应使用 PIL

当控制软件已准备好进行执行测试，但最终的硬件测试平台尚未完成、已被占用或仍不稳定时，应使用PIL。PIL能够确保验证工作持续进行，因为它将目标处理器作为软件行为的主要参考源，而无需等待每个传感器、执行器和接口板就位。

航空航天控制团队往往很早就达到这一阶段。飞行控制律已经通过了模型仿真，目标处理器板已就绪，而作动器试验台仍在组装中。PIL 使团队能够针对模拟的飞机模型，验证代码时序、栈使用情况、数值限制以及调度器行为。这避免了软件成熟度与试验台就绪之间出现较长时间的间隔。

当您的进度风险主要源于硬件准备情况而非代码准备情况时，这种方法尤为重要。您仍然需要一个准确的工厂模型和严谨的测试用例，但PIL能将缺陷控制在源头附近。如果您的固件开发进度依然很快，而硬件却出现延迟，那么PIL就是您接下来应该采取的正确步骤。

当时序延迟影响控制器性能时，应使用HIL

当闭环时序、I/O 处理和接口行为将决定测试结果是“通过”还是“失败”时，应使用 HIL。一旦控制器软件足够稳定，且剩余的主要风险主要集中在采样延迟、通信时序、故障响应以及与物理控制器硬件的交互方面，HIL 便成为合适的方法。

电网变流器控制器便是很好的例子。保护跳闸、相位锁定环路和PWM定时，都依赖于与测量信号及市场活动微秒级别的交互。仅靠处理器测试，无法展现当模拟前端、总线定时和外部故障同时作用于控制器时会发生什么。HIL测试则能清晰地呈现这些瞬态过程。

此时，执行基础设施就显得尤为重要。在这一阶段，OPAL-RT通常部署在实验室环境中，因为仿真器必须在满足严格时序要求的同时，准确模拟I/O和故障场景。如果延迟和接口保真度会影响控制器的行为，那么HIL就值得投入时间进行测试。

随着软件故障的减少，测试保真度应随之提高

只有在低级别软件缺陷已缩减至可控范围后，才应提高测试保真度。这种渐进式方法能确保每个验证阶段都保持高效。应从成本较低且孤立性更强的检查开始，当未解决的问题确实需要处理器执行、硬件时序或完整的闭环交互时，再提高保真度。

一支纪律严明的团队在向上推进之前，会先寻找明确的信号。其目标是使测试成本与剩余风险相匹配。以下五个迹象表明，控制工程师已准备好从PIL（物理集成实验室）转向HIL（硬件在环）：

• 在目标处理器上执行代码的过程在您的核心测试用例中具有可重复性。
• 数值缩放和定点选择不再导致无法解释的输出漂移。
• 在预期中断负载下，任务调度仍能控制在预算范围内。
• 接口假设已记录得足够详细，足以让我们放心地进行测试台的接线工作。
• 目前已发现的缺陷表明，问题出在时序或集成方面，而非基础软件逻辑上。

这一流程有助于节省预算并集中精力。您肯定不希望动用整套HIL测试平台，却只是为了验证查找表的缩放比例不正确，或者调度器周期配置有误。只有当简单的测试无法再发现简单故障时，更高保真度的测试才真正派上用场。

跳过 PIL 通常会使 HIL 成为调试的瓶颈

“跳过PIL通常会迫使HIL承担本不该由其承担的软件调试工作。”

测试台上堆积着各种各样的故障模式，而你需要的信号则被I/O设置问题、时序交互以及本应早些时候就已排查出的基本代码缺陷所掩盖。

动力总成团队很快就能发现这个问题。控制器通过线缆连接到HIL测试架上，扭矩响应看起来有异常，但没人知道问题是出在数值转换、ADC量程、被控对象假设还是总线时序上。软件测试基础设施的不足，据估计每年给美国经济造成 595亿美元，这充分说明了当各个测试阶段相互重叠时，后期发现缺陷所带来的代价是多么高昂。

HIL测试台价格昂贵，是因为它们集成了稀缺的设备、工厂模型和专家工时。当基础软件故障发展到这一阶段时，故障诊断速度会变慢。PIL能在这些问题影响闭环调查之前将其排除，因此团队可以将更多时间用于验证那些真正需要硬件在环（HIL）的技术需求。

分阶段的验证路径可缩短建立系统可信度的周期

从仿真 再到HIL的分阶段流程缩短了建立信心所需的时间，因为每种方法都能解答不同的问题。PIL在处理器上验证编译后的软件；HIL则在闭环时序和接口压力的条件下验证控制器。按此顺序使用这些方法，既能精准定位故障，又能提高实验室工作的效率。

从那些能按计划推进的嵌入式程序中，可以发现一种共同规律。它们不会等待测试平台满负荷运行时才来发现代码问题，也不会将处理器测试资源浪费在依赖模拟I/O或总线延迟的问题上。验证流程始终严格有序，因此当需求变得更加严格时，项目进展反而更为平稳。这种判断比任何单一工具的选择都更为重要。

OPAL-RT 正契合这种思维方式，因为相关工作是以各步骤的执行保真度、测试时长和可信度为核心来组织开展的。将 PIL 和 HIL 视为不同阶段的团队，能够更快地完成验证，并更合理地利用测试台。