什么是软件在环 （SIL）？

核心要点

• “软件在环测试”是在硬件进入测试路径之前，通过可执行代码验证其是否仍符合系统设计意图的实际检查点。
• 当您利用SIL尽早隔离软件缺陷、实现回归测试自动化，并使HIL专注于与硬件相关的问题时，SIL可降低验证成本。
• SIL 测试能否取得可靠结果，取决于时间、接口和数值假设的准确性，因为不严谨的仿真 只会带来虚假的信心，而非有用的证据。

软件在环 （软件在环 ）使您能够更早、更经济地验证嵌入式软件，并能更准确地定位故障，而无需等待硬件就绪。

这一点之所以重要，是因为随着电动汽车和自动化平台的规模不断扩大，现代控制系统中的软件内容也在持续增长。2023年，全球电动汽车销量超过1400万辆，使总保有量达到约 4000万辆。如今，越来越多的程序依赖于能够跟上频繁软件更新步伐的控制代码、工厂模型和回归测试。SIL作为模型验证与硬件集成之间的桥梁效果最佳，因为它能在实验室硬件拖慢团队进度之前，就揭示出逻辑错误、接口缺陷和需求缺口。

“软件在环”技术在仿真环境中运行生产代码

“软件在环”（SIL）是指可执行软件在模拟的传感器、执行器和被控对象行为环境下运行，而非在物理硬件上运行。您测试的是已实现的代码，而不仅仅是控制模型，因此SIL能为您提供首个有力证明，表明软件行为在编译和集成后仍与系统设计意图相符。

发动机控制器便是一个简单的例子。控制代码读取模拟的曲轴角、节气门位置和温度值，然后将喷油器和点火指令写回被控对象模型。如果扭矩限制、断油逻辑或诊断标志出现异常，您可以直接检查确切的信号和时序路径，而无需接触台架控制器或车辆线束。这使得软件故障的定位比在后续的共享实验室环境中要容易得多。

SIL 的价值在于：代码生成、编译器设置、数据类型和模块接口都会引入某些行为，而仅凭功能框图是无法揭示这些行为的。模型看起来可能很简洁，但生成的代码却可能截断值、误读缩放因子，或者以错误的顺序调用任务。SIL 能在这些实现问题尚可快速修复且可追溯的阶段将其捕获。正是这一阶段，软件才真正成为可测试的工程证据，而非仅仅是设计假设。

SIL在HIL验证之前进行模型验证

SIL应位于模型验证之后、硬件在环验证之前。一旦控制逻辑在模型层面上运行正确，SIL 就会根据相同的功能意图，对生成的或手动编写的代码进行验证。这种顺序可以防止代码缺陷影响后续的硬件测试，从而避免浪费测试时间。

一个制动控制器清晰地展示了这一序列。模型验证证实，仿真，滑移控制、压力请求和备用状态均能正确运行。随后，SIL测试会将实际的软件构建版本应用于相同的被控对象案例，以确认实现结果仍符合这些规则。接下来是HIL测试，此时需要验证控制器如何处理目标I/O时序、网络流量以及硬件接口约束——这些是纯软件执行无法完全再现的。

当进度紧张时，团队往往会省略某些步骤，但这种捷径通常会适得其反。如果直接从模型仿真跳到硬件在环（HIL）测试，台架测试中的故障可能源于软件逻辑、代码生成、调度器配置或I/O接线，而实验室无法告诉你究竟是哪一个环节最先出现故障。系统在环（SIL）测试能在硬件投入使用前缩小故障排查范围。它并不能取代HIL测试，也不需要取代。它的作用是为HIL测试做好准备，确保硬件测试能解答与硬件相关的问题。

当软件更新速度超过硬件供应速度时，请使用SIL

当软件迭代速度快于硬件准备就绪时，SIL便是最合适的下一步选择。它为您提供了一个稳定的环境，用于运行日常构建、测试故障路径以及验证接口契约，即使此时测试平台、原型机或目标控制器仍处于延迟、共享或不完整状态。

有几个迹象表明，在进行更多实验工作之前，应先进行SIL：

• 您的硬件发布计划落后于软件发布节奏。
• 您的工厂模型已经能够再现您所关注的运行状态。
• 代码合并后，您的团队需要每天进行回归测试。
• 在仿真 环境中进行故障注入仿真 在实验室设备上更安全。
• 模块之间的接口契约每周都在变化。

汽车动力总成团队经常会遇到这种情况。逆变器控制软件的开发工作在持续推进，但下一版控制器和动力计测试时段还要再等几周才会到来。SIL 验证机制确保了验证工作的持续进行，因为代码仍可针对速度斜坡、扭矩阶跃、限速返航工况以及传感器故障进行测试。当您试图让软件质量与积极的开发进度保持同步，而不是等待硬件瓶颈消除时，这种节奏至关重要。

“软件在环（Software in the Loop）是指可执行软件在模拟的传感器、执行器和被控对象行为上运行，而不是在物理硬件上运行。”

SIL通过更早地定位缺陷来降低验证成本

SIL 能够降低开发成本，因为它能在涉及原型部件、实验室预约和测试台技术人员之前，就将软件缺陷隔离出来。您可以利用一夜时间运行覆盖面广泛的回归测试，将故障追溯到具体信号，并在代码修改成本较低且负责工程师仍记得该变更时进行修复。

成本问题远不止一个实验室的预算那么简单。软件质量低下给美国经济造成的损失至少达到 2.41万亿美元。SIL 虽无法彻底消除这一问题，但它针对了其主要成因之一：缺陷被发现得太晚，而在这种情况下，每次故障都会消耗宝贵的人力、硬件和进度缓冲。

一套牵引力控制回归测试套件使这一点得以具体体现。您可以在一个自动化批处理中运行干沥青路面、压实雪地、传感器偏差以及看门狗重置等测试用例，然后在下一版代码发布之前，将输出结果与预期行为进行对比。如果代码合并后车轮速度滤波器出现故障，团队能够迅速发现并修复该问题，从而避免该缺陷占用测功机测试时间或引发令人困惑的HIL调查。通过更早地定位问题，测试便从瓶颈转变为过滤器。

SIL 依赖于软件接口的时序准确性

只有当接口时序、采样、量化和任务调度与目标软件环境相近时，SIL才能给出有用的结果。如果这些细节处理得不够严谨，代码在仿真 看似正确仿真 一旦遇到更严格的I/O时序、中断负载或异步任务交互，仍可能出现故障。

扭矩控制器即使通过了所有额定测试，如果软件读取了过时的电流反馈值，或者在任务执行延迟一个周期后才写入控制指令，仍可能出现故障。当采样时间、缓冲区更新和速率转换未被如实反映时，就会出现此类问题。定点缩放同样至关重要。使用浮点运算的模型可能会掩盖溢出、饱和或分辨率损失等问题，而部署后的软件会立即遇到这些问题。

使用OPAL-RT或任何仿真 团队仍需谨慎定义这些接口假设，因为仅靠计算速度无法弥补薄弱的时序契约。您需要在测试框架中明确指定调度器行为、信号延迟以及数值约束。当 SIL 能够足够准确地反映软件环境时，故障才具有实际意义；反之，通过测试可能会产生虚假的信心，这将在后期带来更大的代价。

“软件在环”与“硬件在环”

“软件在环”（SIL）与“硬件在环”（HIL）的主要区别在于被测对象。SIL 是在模拟的输入和输出条件下运行软件，而HIL 则是将控制器连接到物理 I/O 和硬件接口。SIL 能更早地解答逻辑和软件集成方面的问题，而 HIL 则能在更接近实际部署的阶段解答硬件交互方面的问题。

电池管理团队通常会按此顺序同时使用这两种测试循环。SIL 能及早发现平衡逻辑缺陷、估算器的边界情况以及故障阈值问题，随后 HIL 会在发布前检查目标设备的 I/O 时序、网络消息以及与测试台硬件的交互情况。如果让 HIL 同时承担这两项任务，您将花费更多时间在发现软件问题成本最高的地方进行故障诊断。

汽车领域的SIL工作流将需求与可执行测试联系起来

一个有效的汽车SIL工作流以需求为起点，以与软件构建版本关联的自动化通过/失败结果为终点。该工作流的结构很简单：选择需求、定义场景、在 plant 模型上运行可执行代码，并将输出结果与可量化的验收规则进行对比。

车道保持控制器使这一流程清晰可见。一项需求规定，当传感器出现信号丢失时，控制器必须限制转向扭矩，同时保持安全的备用状态。团队将该需求转化为一个测试用例，其中包含模拟道路、车辆模型、信号丢失事件以及预期的软件响应。软件构建在SIL环境中运行，测试套件记录内部状态和输出，并将结果与原始需求关联起来，从而使故障能够得到有效处理。

该工作流之所以有效，是因为它保持了证据链的完整性。您不仅是在验证代码能否运行，更是在验证在代码集成、校准更新和接口变更之后，特定需求是否仍然成立。这种可追溯性在汽车项目中至关重要，因为安全审查、软件发布和校准签核都依赖于可重复验证的证据。当SIL成为持续回归测试的一部分时，每次代码变更都将符合统一的可执行标准，而非依赖于记忆和手动测试的惯例。

当时序假设掩盖了集成缺陷时，SIL会失败

当团队认为功能正确性就足够了，而忽视了时序、数值精度或接口行为时，SIL就会失败。即使测试套件通过了，仍可能掩盖了未被检测到的中断、缩放错误、调度器冲突以及异步故障——这些问题可能会在后续的台架测试或车辆测试中显现出来。

一个电机控制团队可能在额定扭矩和转速工况下测试通过，但一旦诊断任务在不恰当的时机抢占了控制环路，就会遇到问题。另一个团队可能将传感器数据建模为无噪声且同步的，从而漏检了仅在消息延迟和数据过时的情况下才会出现的故障。这些疏漏并非因为SIL级别不足，而是因为针对所测试软件风险的仿真 过于薄弱。

“规范的SIL通过建立HIL，能够提出更具针对性的问题，并合理利用实验室时间。”

正因如此，OPAL-RT 与工程团队的讨论往往首先聚焦于求解器的精度、接口响应时间以及可重复的自动化流程，而后才涉及吞吐量。良好的 SIL 实践能随着时间的推移赢得信任，因为它用可执行的证据取代了依赖大量假设的测试，当进度紧张时，这些证据足以支撑你的论点。