将硬件在环测试应用于汽车控制系统

主要收获

• 当控制器时序、接口和故障处理是主要未知因素时，“硬件在环”方法的效果最为显著。
• 模型质量应与控制问题相匹配，且细节应足够丰富，以便再现影响控制器响应的动态过程。
• 台架试验和车辆试验的结果应相互印证并建立关联，而早期原型车试验则应首先消除基本的不确定性。

在工厂模型已解决基本控制问题后，汽车控制团队若采用硬件在环方法，便能更快地获得更优解。

汽车硬件在环测试将量产控制器与模拟被控对象置于闭环中，因此您可以在整车或台架测试环境准备就绪之前，先验证控制器的运行表现。这一点至关重要，因为现代控制软件直接影响安全结果。 电子稳定控制系统可将乘用车的单车致命事故风险降低49%，将运动型多用途车的单车致命事故风险降低59%。硬件在环测试虽有价值，但只有在被控对象模型已解答了关于控制律、控制极限及预期被控对象响应等基本问题之后，才能发挥最佳效果。

团队往往过早地采用台架测试，因为硬件给人的感觉更切实可靠，也更容易让人放心。当待解决的问题仍在于被控对象的行为而非硬件交互时，这种本能会拖慢项目进度。一个优秀的被控对象模型能让你更早地进行调优、故障模拟和案例重复测试，且无需过多准备工作，因果关系也更为清晰。硬件在环测试应部署在控制器接口、时序和故障处理成为主要风险的阶段。

汽车硬件在环测试实现了控制闭环

汽车硬件在环测试是将实际控制器与模拟的车辆或子系统被控对象进行交互，从而使您能够在可重复的条件下验证控制输出、输入处理和时序。该测试通过与量产硬件闭环，因此在系统集成方面比桌面仿真更具优势。

电机变频器控制器就是一个很好的例子。该控制器从仿真器读取速度、电流和温度信号，然后将脉冲和转矩指令发回至被控对象。这种设置可以让你知道控制器是否过早饱和、是否未达到限值，或者是否未能正确处理传感器故障。你不再需要猜测笔记本电脑上的代码在遇到实际的输入/输出通道时会如何表现。

这一差异至关重要，因为许多控制问题并非仅源于控制律本身，而是源于缩放、量化、延迟以及跨接口的故障信号传输。基于“硬件在环”（HIL）的汽车测试平台既能确保测试结果的可重复性，又无需等待车辆组装完成，同时还能确保控制器硬件的可靠性。虽然它无法取代被控对象建模，但能揭示纯软件仿真所掩盖的集成问题。

当接口时序至关重要时，请使用硬件在环技术

当主要不确定性在于控制器时序、信号接口、任务调度或网络通信时，“硬件在环”是正确的选择。一旦理解了被控对象的行为，就应转入“硬件在环”阶段，以验证控制器在实际执行约束条件下是否仍能正常工作。

假设有一个电动车轴控制器，它在桌面仿真中能产生正确的扭矩，但在总线流量达到峰值时却未能响应扭矩减小请求。虽然控制律本身没有问题，但调度器和通信时序却形成了一条故障路径。硬件在环测试将揭示这一问题，因为真实的控制器会在与您计划投入使用的负载结构相同的条件下执行任务、转换输入并发布输出。

这就是台架试验大显身手的时候。如果你还在问轮胎打滑、电机电感或冷却液温度如何影响控制目标，那就继续使用被控对象模型吧。一旦问题变成“在当前时序和接口负载下，控制器能否仍达到控制目标”，那么硬件在环（HIL）测试就成了更合适的步骤。

模型保真度决定了每次测试的数值

被控对象模型的保真度决定了硬件在环测试实际上能够验证什么。你需要足够的细节来再现对控制器至关重要的被控对象动态，但并非每个测试用例都需要完整的车辆模型。

以电池冷却控制器为例。如果目标是验证风扇状态逻辑和温度阈值处理，集中参数热模型就足够了。如果目标是验证在激进驱动循环中随着电芯温度升高而产生的转矩降额，则模型必须考虑热滞后、传感器布置以及执行器限制。在错误的地方采用低保真度模型，只会得到干净的图表和薄弱的证据。

应将保真度直接与控制问题挂钩，并确保模型范围与该需求保持一致。在无关的子系统中追求过高的细节会浪费精力并拖慢测试执行速度。若控制环路附近的动态特性未被纳入模型，则会产生虚假的信心。优秀的“硬件在环”（HIL）汽车仿真工作，应以一个具有选择性、透明度高且与待测特定行为相匹配的模型为起点。

“一旦问题变成‘在这样的时序和接口负载下，控制器是否还能达到目标’，那么硬件在环就成了更优的选择。”

围绕可衡量的控制问题构建工厂模型

模型的构建应从通过与失败标准、命名的信号以及预期的控制器响应入手。相比于一个无法解释测试为何通过或失败的大型模型，一个具有清晰可测量输出的简洁模型能带来更大的价值。

制动控制器开发团队在构建模型之前，可能会定义车轮速度误差、滑移目标、压力上升率以及故障锁存时序。这些参数能帮助您确定哪些状态、延迟和非线性特性应包含在被控对象中。在此阶段使用 SPS SOFTWARE 的团队通常能从可编辑的方程和可视化参数中获益，因为测试模型必须支持推理，并生成可供解读的跟踪信息。

在连接控制器之前，还需要就采样时间、信号缩放和故障插入点达成一致。这些准备工作可以减少后续在实验台上浪费的时间。当你能用一句话表述控制问题，并指出能回答该问题的信号时，就说明你的被控对象模型已经准备好进行硬件在环测试了。

硬件在环测试将控制器与模型连接起来

硬件在环测试将物理控制器、其输入/输出接口、通信通道以及运行子系统或车辆动力学的模拟被控对象连接起来。由此形成一个闭环系统，使您能够在可重复的运行和故障条件下观察控制器的行为。

变速箱控制器的典型配置包括模拟和数字I/O映射、网络消息、执行器仿真、故障注入点以及同步日志记录。您可以注入缺失的传感器脉冲、电压降或偏移的校准值，然后观察控制器的响应，而无需担心造成硬件损坏。正是这种可重复性，才是团队选择使用硬件在环（HIL）而非直接跳转到车辆时间模式的实际原因。

下面的检查点有助于将常见的汽车控制系统相关问题归类到正确的初试阶段。

测试场景应遵循控制风险和故障暴露原则

测试用例应根据控制风险、故障暴露程度和安全后果来选择。自动化难易程度应作为次要考虑因素。最佳的硬件在环（HIL）计划应侧重于那些控制器必须在延迟、噪声、饱和和传感器性能退化等情况下正确响应的状态。

自动紧急制动就是一个明显的例子。配备城市及城际自动制动功能的前方碰撞预防系统，可将前车与后车之间的碰撞减少约50%。此类控制功能必须涵盖传感器失效、误判目标、摩擦力降低以及执行器延迟等场景，因为任何被忽略的边际情况都会直接导致安全风险。

基于风险的筛选也能提高效率。如果五个棘手的案例已经能够暴露控制器的薄弱环节，那么就没有必要再测试数百个轻微且相似的案例。与安全目标、运行状态和恢复逻辑相关联的故障矩阵，所能提供的证据比出于方便而编制的冗长测试清单更为有力。良好的硬件在环测试应具有选择性且有条不紊。

在模型中回答完控制问题后，才应引入测试台架

在系统模型已降低了对控制策略的不确定性，且闭环硬件已验证了执行行为之后，台架测试才最能发挥作用。如果过早将硬件引入台架，就会花费时间组装夹具来解答那些本可以通过模型更快得到解答的问题。

这些迹象通常意味着你应该再坚持使用该植物模型一段时间：

• 植物的预期反应目前仍存在争议。
• 尚未定义您的通过和未通过信号。
• 该控制律仍需进行基本增益或限幅调整。
• 故障情况目前尚未与明确的控制器操作相关联。
• 实验台的搭建工作量比所提出的问题要大。

冷却回路控制器会显示跳过此指令所带来的代价。如果泵的动态特性与传感器延迟仍不确定，台架试验将产生模棱两可的结果，导致人们为此争论不休数日。一旦过程模型消除了这些影响，台架试验便能用于管路布局、设备封装以及硬件公差检查。这样，您将减少追查症状的时间，而将更多时间用于验证已知的预期结果。

“清晰、基于物理原理的植物模型有助于您更早地提出更精准的问题，因此‘硬件在环’技术被应用于能创造最大价值的环节，而车辆测试时间则用于相关性验证，而非基础控制调试。”

硬件在环测试仍需进行车辆相关性验证

硬件在环测试存在局限性，因为每个模型都会有所遗漏，而且每个控制器都会遇到难以完全建模的噪声、公差和耦合效应。因此，仍需进行台架与车辆的关联性验证，以确认所模拟的被控对象能否足够准确地反映实际测量行为，从而支持预期的结论。

轮胎力变化、机械顺应性、热稳态、布线噪声以及传感器生产公差，都可能在硬件在环测试看似顺利通过后，导致测试结果发生偏移。一个转向辅助控制器可能通过所有实验室测试场景，但在粗糙路面上却会出现轻微振荡，这是因为在仿真模型中简化了转向齿条摩擦和路面输入耦合。这并不意味着硬件在环阶段失败了，而是说明该阶段成功解答了其设计旨在解答的问题。

顶尖的汽车研发团队将模型、硬件在环、台架试验和整车测试视为一个逐步缩小不确定性的过程。SPS SOFTWARE恰恰与这一工作流程自然契合。清晰且基于物理原理的被控对象模型，能帮助您在更早阶段提出更精准的问题，从而使硬件在环技术应用于能创造最大价值的环节，并将整车测试时间用于相关性验证，而非基础控制调试。