什么是汽车 SIL 测试？

核心要点

• 当您在硬件引入额外变量之前，利用SIL来验证面向生产的软件行为时，它能带来最大的价值。
• 正确的SIL配置应与目标接口、调度器假设以及通过/失败阈值相一致，以确保结果在后续阶段仍具有实用价值。
• SIL 和 HIL 最好作为相互关联的阶段来实施，其中 SIL 可尽早排查逻辑故障，而 HIL 则用于验证时序和硬件集成。

汽车领域的SIL测试通过将生产软件与模拟的车辆和工厂进行对比验证，从而在硬件导致开发进度放缓之前，及时发现逻辑故障。

软件在环 控制软件已足够稳定，能够运行闭环控制，但电子控制单元、传感器或实验室测试台尚未就绪，或投入成本过高软件在环 ，团队会采用软件在环 。这一时机至关重要，因为在软件缺陷演变为时序问题或接口问题之前进行修复，成本要低得多。证明自动驾驶车辆 比人类驾驶员安全20% ，根据兰德公司（RAND）的分析，如果仅依赖实际道路里程，可能需要约110亿英里的行驶里程。

只有当你将SIL视为一个严肃的验证步骤，而非简单的模型检查时，它才能发挥应有的作用。在投入时间进行硬件实验室测试之前，你已经证明了嵌入式软件、其接口及其控制逻辑能够经受住边界情况的考验。这种方法缩短了反馈循环，并为后续的硬件在环（HIL）工作提供了更清晰的起点。如果你能有条不紊地开展SIL工作，不仅能加快开发进度，还能对结果更加放心。

SIL测试通过工厂模型对嵌入式软件进行验证

“在任何目标硬件进入测试链之前，先在主机上作为软件运行控制器代码，并检查其对模拟的车辆状态、故障以及驾驶员操作的响应情况。”

SIL测试通过与数学被控对象模型进行闭环交互，对编译或自动生成的嵌入式软件进行验证。 制动扭矩控制器对此进行了清晰的说明。该软件从被控对象模型接收车轮转速、踏板指令以及路面摩擦系数估计值，随后将扭矩指令发回至同一仿真。如果在结冰路面上制动时，控制器出现饱和、振荡或状态转换失效等情况，SIL 能在代码仍易于检查的阶段揭示这些行为。开发团队利用这一阶段验证控制逻辑、校准规则、诊断路径以及故障处理机制。 您能快速获得关于软件设计意图的反馈，这正是后续台架测试在硬件时序问题出现之前所需要的。

SIL在模型设计后、硬件集成前进行

SIL测试应安排在算法设计稳定之后、硬件集成开始占用进度之前。当软件结构已能充分反映目标行为，足以测试接口、状态流和故障响应，但电子控制单元或测试台尚未准备就绪时，应进行SIL测试。在这个时间点进行测试，能带来最佳的投入产出比。

发动机气路控制器便是常见的例子。控制团队已经就估计器逻辑、任务速率和校准钩子达成一致，但硬件团队仍在最终确定输入/输出映射和电路板可用性。此时运行SIL测试，无需等待测试台位，即可暴露不稳定的状态逻辑、不合理的默认值或薄弱的故障恢复机制。 跳过这一阶段的团队往往会在后期遇到同样的问题，届时每次故障的重现都需要花费更长时间。您希望在硬件引入额外变量之前，先解决软件方面的问题。

SIL 框架应反映目标软件的边界

一个强大的SIL框架应准确反映目标控制器上将存在的软件边界。模型、调度器假设、信号缩放、诊断以及通过/失败标准应充分体现生产意图，以确保代码迁移到硬件后，测试结果仍具有实际意义。如果这些边界发生偏移，信心将迅速下降。这就是为什么框架设计与测试数量同样重要的原因。

以一个电动助力转向控制器为例，该控制器包含用于扭矩请求、助力逻辑和诊断的独立模块。一个有效的SIL配置应确保这些模块相互隔离，通过后续预期采用的相同接口契约向其提供数据，并以与任务相关的采样率记录输出结果。使用OPAL-RT等平台的团队 通常会确保从桌面执行阶段到后续实验室阶段，场景定义和接口假设保持一致，从而在控制器进入硬件阶段时减少返工。 您构建的是一个验证路径，而不是一次性的仿真。清晰的边界使故障更易于追踪，结果也更值得信赖。

闭环场景能更早地发现逻辑故障

闭环测试场景能更早地暴露逻辑故障，因为软件必须持续应对自身输出的后果。开环检查只能验证单一功能，而只有闭环测试才能揭示，当车辆物理特性产生反作用时，状态转换、时序假设和故障响应会如何表现。当边界情况层层叠加时，这一差异至关重要。在压力下，控制意图便显露无遗。

电池管理控制器便是一个很好的例子。一种测试场景可以同时包含快速负载变化、温度传感器偏移以及低电压事件，而系统模型会在每个步骤中更新电池单元的行为。这种设置能在安排台架测试之前很久，就揭示出不稳定的热降额逻辑或延迟的故障锁存问题。仿真 同样重要。道路交通事故每年导致约 119万例死亡，这说明了为什么团队需要的场景覆盖范围，不能仅靠实际行驶里程来提供。闭环SIL可让您将场景覆盖范围压缩到一个切实可行的验证周期内。

选择SIL还是HIL取决于验证问题

SIL 与 HIL之间的主要区别在于控制器代码的位置以及所需的验证依据。SIL 是将控制器作为软件在模型上运行，而 HIL 则是将实际的控制单元与模拟的被控对象行为及物理 I/O 时序相连接。这两种方法分别针对不同的验证问题。如果选错了方法，就会浪费时间。

电动驱动控制器清晰地展示了这种差异。在SIL环境中，可以针对数千种速度和负载组合，对扭矩仲裁、限速行驶规则以及模式切换进行测试。一旦需要验证目标时序、模拟输入调理以及诊断引脚在实际控制单元上的行为是否正确，HIL测试就变得必不可少。您应根据当前面临的问题选择相应的方法。

只有当模型的保真度可信时，测试速度才重要

测试速度只有在工厂模型足够可靠、能够像车辆实际运行那样对软件提出挑战时才重要。高速运行看似高效，但如果将传感器延迟、执行器限制、噪声和故障动力学简化到失去实际意义的程度，就会产生虚假的信心。你需要一个能够真实反映待验证行为的模型。如果缺乏保真度，提高速度只会让错误提前显现。

“一种忽略电芯不平衡或传感器延迟的电池管理模型，一旦硬件引入这些影响，该模型所批准的软件就会立即失效。”

当离合器充填动力学被过度简化，且换挡逻辑从未遇到过生硬的换挡过程时，变速箱控制中也会出现同样的问题。优质的SIL模型应聚焦于塑造软件行为的动力学特性，而非表面细节。车辆的每个部件并不需要完美的物理模型，但控制路径确实需要具备足够的保真度，这样当模型脱离桌面环境时，“通过”或“失败”的结果才具有实际意义。

糟糕的接口会在团队察觉之前就削弱SIL的成果

糟糕的接口会在团队察觉之前就削弱SIL测试结果，因为软件看似稳定，而测试环境却悄无声息地掩盖了集成故障。错误的信号缩放、遗漏的调度器假设、过于宽松的默认设置，或是模糊的故障时序，都可能让一个性能欠佳的控制器看起来运行正常。只有严格遵守接口规范，才能让SIL从单纯的模型演练转变为有用的软件验证。细微的不匹配会造成巨大的盲点。

电机控制程序往往最先暴露出这一问题。在SIL阶段，电流请求限值看似正确，但后续的台架测试却显示出不稳定的行为，原因在于调度器周期、传感器滤波或故障去抖逻辑从未符合目标假设。尽早审查接口细节的团队能够避免这一陷阱。在添加更多场景或扩大回归测试覆盖范围之前，通常应优先关注这些检查项。

• 信号缩放完全符合软件规格要求。
• 任务速率反映了目标控制器上使用的调度器。
• 默认值绝不会掩盖缺失的传感器输入。
• 故障标志采用与生产诊断相同的定时机制。
• 合格与不合格的标准反映了车辆的要求。

SIL 应将控制权干净利落地移交给 HIL 执行

SIL 应通过共享场景、稳定的接口契约以及在迁移至目标硬件后仍可保留的通过/失败规则，将执行任务无缝移交至 HIL。当 SIL 尽早消除逻辑缺陷，而 HIL 专注于控制器时序、物理 I/O 以及集成验证时，团队才能获得最佳回报。这种顺序使验证工作更有针对性，同时也确保了实验室时间的有效利用。

以牵引逆变器项目为例。在SIL阶段通过的相同加速请求、故障注入和热保护场景，在HIL阶段只需更改控制器执行上下文即可直接沿用。如果团队在不同阶段之间重新构建所有内容，就会失去可追溯性，并重复已经付过费的工作。 OPAL-RT 恰好符合这一原则：当工程师需要使用相同的验证逻辑，从软件执行阶段过渡到硬件耦合测试阶段时，无需重建整个测试环境。优质的SIL测试之所以有价值，是因为它能为后续提供清晰的验证依据，而非仅仅因为它增加了一个孤立的测试阶段。