什么是软件在环 （SIL）？

核心要点

• “软件在环”能让你在早期阶段最清晰地验证控制软件的行为，因为被控对象始终处于仿真状态，迭代过程也十分迅速。
• 在硬件在环系统处理时序、I/O 和通信问题之前，SIL 应先排除逻辑、数值和集成方面的故障。
• 完善的工厂模型和稳定的接口决定了SIL值得信赖的程度，以及您的团队能否顺利过渡到台架验证阶段。

软件在环 为您提供了一种成本最低的方式，可在硬件时序和布线开始掩盖基本故障之前，验证控制代码。

一辆现代汽车可能包含超过 1亿行代码，这使得早期验证不再是狭义的软件任务，而是变成了一个系统级问题。当如此庞大的逻辑与标定参数、被控对象模型及通信信号相互作用时，微小的错误会迅速在整个程序中扩散。软件在环 ，是因为它能在模拟的被控对象上运行您编译或生成的软件，而此时修复工作仍能快速实施。您将直接了解到软件在环 真正目的：在台架硬件开始影响测试结果之前，验证系统的行为表现。

“软件在环（Software in the Loop）是指在工厂、传感器和执行器保持模拟状态的同时，控制软件作为代码运行。”

“软件在环”测试在仿真环境中对编译后的控制软件进行测试

软件在环 是指控制软件作为代码运行，而被控对象、传感器和执行器则保持在模拟状态。您不再需要在纸上验证方程，而是通过闭环系统验证软件的行为。这就是工程师所采用的“软件在环”的实际定义。

逆变器控制器清晰地展示了这种差异。电机、电池和负载以模型形式存在，而控制逻辑则以生成的 C 代码或编译后的软件构建形式运行。您可以逐步调试扭矩请求、电流限制和故障状态，而无需等待电子控制单元到位。这种设置通过具体实例而非抽象概念，解答了“什么是 SIL”这一常见问题。

这种价值源于在联系表 测试软件联系表 您计划发布的软件一致。模型检查依然重要，但SIL更接近实际执行，因为它能揭示数值效应、任务交互以及接口假设。当被控对象的反馈快速变化时，您将能观察到代码是否行为正确。此外，您还能发现那些在联系表 看似简洁的控制逻辑，在循环运行时是否联系表 出现波动。

SIL在台架测试开始前就发现了集成故障

SIL能够揭示单元测试和模型审查所遗漏的故障，因为完整的控制堆栈是在任务时序、可扩展性和被控对象反馈的条件下运行的。故障可能出现在信号路由、调度器顺序、饱和处理以及状态转换中。这些故障会在您预订测试台时间之前就显现出来。正是由于这一时间优势，SIL才应位于HIL之前。

牵引力控制功能即使通过了设计评审，一旦代码生成改变了数值精度，仍可能出现故障。模拟车辆请求扭矩，控制器截断了该请求，且保护状态始终无法复位。您无需连接测试台或等待ECU插槽，即可发现此类故障。正是这种可视性，赋予了仿真 独特的实用优势。

早期暴露的缺陷通常符合少数几种重复出现的模式。这些缺陷往往出现在软件与接口、时序以及各种限制条件交汇之处。识别这些模式至关重要，因为这能缩短调试时间。下文列出了开发团队最常遇到的故障类型。

• 工厂输出与控制器输入之间的信号量程不匹配。
• 任务顺序会改变状态更新的顺序。
• 数值限制会引发隐性饱和或溢出。
• 通信中的假设会导致消息丢失或延迟。
• 故障恢复逻辑进入安全状态后便无法退出。

每种情况都指向不同的解决路径。缩放问题需要清理接口，而调度器问题则需要进行任务设计工作。由于团队在开始测试时遇到的基础软件意外情况较少，您将节省测试台时间。这样，HIL测试就可以专注于硬件交互，而不是首次软件调试。

早期SIL测试通过尽早发现缺陷来降低成本

早期软件集成测试（SIL）能降低成本，因为它能在测试台搭建、硬件预订以及跨团队调试等环节开始增加阻力之前，就消除缺陷。美国国家标准与技术研究院估计，软件测试基础设施不足每年给美国经济造成 595亿美元。同样的逻辑在此同样适用。缺陷发现越晚，成本越高，因为此时涉及的人员和设备越多。

电池管理控制器提供了一个简单的例子。如果在SIL阶段，电池平衡例程过早地切换了状态，你只需修改代码、重新运行系统模型，当天就能解决问题。但如果同样的缺陷出现在测试台上，你现在就得涉及实验室排期、供电硬件、安全规程以及测试监督等环节。软件缺陷本身并未改变，但围绕它的成本却急剧攀升。

您还能在那些不那么显眼的地方减少浪费。校准工程师无需再为软件故障导致的异常结果而烦恼；测试工程师无需再重新构建本应在仿真就被发现的测试场景；而由于逻辑风险已得到降低，管理者也能更清晰地掌握实际硬件风险。这就是SIL测试在实践中如何降低开发成本的。

SIL 与 HIL 的区别归根结底在于接口保真度

软件在环 （HIL）软件在环 主要区别在于接口保真度。SIL 通过模拟被控对象来验证代码行为，其路径中不包含物理 I/O。HIL 则增加了实际控制器、I/O 时序以及通信硬件。您应先使用 SIL 消除逻辑风险，随后再使用 HIL 消除接口风险。

制动控制器能清晰展示控制流程。SIL测试可验证在多种路况下，滑移目标、压力指令和故障逻辑是否按预期运行。随后进行的HIL测试则可验证，当总线时序、I/O延迟和硬件调度因素介入后，控制器是否仍能正常工作。如果跳过SIL测试，测试时间将耗费在那些本无需硬件即可发现的缺陷上。

汽车SIL工作流程始于闭环控制器模型

一套可行的汽车SIL工作流程始于控制器模型、代码生成、被控对象连接、自动化测试用例以及回归审查。每个步骤都保留相同的信号和通过标准，这些内容随后将应用于台架测试。在OPAL-RT上准备台架的团队，若能从一开始就保持这些接口的稳定性，将从中受益。这种规范性做法有助于在进入实验室测试阶段时减少返工。

电动驱动程序为您指明了明确的开发路径。控制器代码基于软件基线构建，随后与涵盖电机、逆变器、电池及车辆负载的系统模型相连接。测试用例涵盖启动、再生制动、热降额及故障恢复等场景。在进行任何硬件预留之前，工程师会审查状态转换、控制误差及限值处理的相关跟踪数据。

该工作流的优势在于可重复性。一旦接口确定，每次软件更新都能重新运行相同的闭环测试用例，并展示具体发生了哪些变化。您不再需要依赖记忆或临时记录的实验笔记。您正在建立一道门槛：只有当软件在同一组条件下表现一致时，才配得上进入HIL阶段。

“当未解决的问题涉及执行时序、I/O 硬件、通信抖动或 ECU 的特定行为时，应转为硬件在环仿真。”

不完善的工厂模型会降低SIL结果的可信度

SIL系统的可靠性完全取决于其背后的被控对象模型和信号假设。一个不准确的被控对象模型可能会让优秀的软件表现不佳，或者让劣质的软件看似稳定。在控制逻辑发生状态切换的工作点附近，模型的准确性尤为关键。而虚假的信心往往就源于此。

如果工厂模型对转矩纹波进行了平滑处理，并忽略了传感器延迟，那么电机控制团队可能会忽略一个严重的问题。在SIL测试中，控制器看似稳定，但随后在低速过渡区域，物理系统却出现了振荡。这并非软件在台架测试中突然表现不佳，而是模型掩盖了本应更早对其造成压力的运行工况。

您应将系统模型视为一种测试资产，其重要性不亚于控制器代码，理应受到同等程度的严格审查。一个合适的模型并不需要在所有地方都做到极致精细，但必须在控制决策敏感的环节具备恰当的细节。噪声、延迟、非线性极限以及模式转换等因素，其重要性远胜于视觉上的整洁。如果这些环节存在薄弱之处，闭环测试所提供的信心也只能是片面的。

一旦出现延迟或保真度限制，请切换至HIL

当未解决的问题涉及执行时序、I/O 硬件、通信抖动或 ECU 的特定行为时，应转为硬件在环测试。安全完整性等级（SIL）无法以足够高的保真度呈现这些影响。一旦软件逻辑稳定，台架测试应针对剩余的接口风险进行。这种顺序能确保实验室工作保持专注且客观。

动力总成控制器是一个很好的参考指标。如果SIL阶段已经验证了扭矩逻辑、故障处理和回归测试覆盖率，那么接下来的未知因素通常是采样时序、总线负载以及硬件调度下的传感器响应。这就是台架测试物有所值之处。当你在扎实的SIL阶段之后转入OPAL-RTHIL测试环境时，讨论的焦点通常会从显而易见的软件缺陷，转向时序裕度和系统在高负荷条件下的响应表现。

优秀的团队将SIL视为一个具有明确标准的关卡，而非实验室开放前需要打勾的任务。这种做法确保硬件测试环节始终聚焦于只有硬件才能解答的问题。此外，它还能在软件、控制和测试团队之间建立信任，因为每个人都能看到相同的测试流程和相同的证据。如果需要一条简单的准则，那就是：使用SIL来验证软件行为，使用HIL来验证接口行为。