“模型在环”测试在V模型的早期阶段能带来什么

核心要点

• “模型在环”测试在验证控制意图时最为有效，因为此时软件和硬件尚未给诊断结果引入干扰。
• 需求可追溯性赋予MIL测试结果持久的价值，因为相同的证据可以应用于“闭环软件”和“闭环硬件”中。
• 设计方案与实际生产的一致性较差以及覆盖范围较窄，会带来虚假的自信，从而将基本的设计缺陷推迟到后期更昂贵的阶段。

“模型在环”测试能带来早期收益，因为它能在代码、硬件和实验室测试耗费大量时间之前，就发现需求缺口和控制缺陷，从而避免后续修复成本高昂。

这种早期回报之所以重要，是因为软件质量低下在 美国在2022年至少损失了2.41万亿美元。对于开发控制系统的团队而言，这些浪费中的很大一部分早在物理测试开始之前就已经产生了。基于模型的测试能在设计仍易于审查的阶段，通过将逻辑与需求进行比对，从而减少这种浪费。您将获得更快的反馈、更清晰的故障原因，并为进入后续验证阶段铺平道路。

“模型在环”测试在实现之前就对行为进行验证

“模型在环”测试是在开始实现之前，将控制器模型与被控对象模型进行匹配。它能在一切仍处于数学模型阶段时，检查逻辑、状态转换、限制条件和响应。您可以尽早观察到预期行为，并在代码结构或硬件时序掩盖设计缺陷之前予以修正。

牵引力控制的设计能清晰地体现这一价值。控制器模型可以读取来自模拟车辆系统的车轮速度信号，并决定在打滑路面上何时切断扭矩。如果打滑阈值设置错误，或者状态机在不同控制模式之间振荡，那么问题就会在设计层面显现出来。您无需编译后的代码或测试台架即可发现这一问题。

正因如此，MIL 应置于严格验证流程的初期阶段。它应作为早期验证阶段，而非简单的模型演示。有效的 MIL 验证计划会根据预期输出、故障响应以及需求阈值来检查系统行为。它还能揭示被控对象模型是否过于简单而无法信赖。一旦出现这种情况，正确的解决方法通常是改进建模，因为额外的测试运行无法弥补被控对象模型的缺陷。

“模型在仿真 与早期的V模型仿真

“模型在仿真 V模型的左侧，即系统需求转化为控制逻辑和可执行设计这一阶段。它仿真 软件构建开始之前，为您提供一个可测试联系表 。这一时机至关重要。由于涉及的实现细节较少，早期缺陷更容易被定位。

电池管理控制器很好地展示了这一流程。需求定义了电压限值、温度响应以及接触器逻辑。随后，MIL会根据充电、放电和传感器故障等条件，对照电池工厂模型对这些规则进行验证。如果在过热情况下接触器断开得太晚，团队就会意识到设计有误，并明白在开始软件开发之前需要修正模型逻辑。

V模型通常被描绘成一条清晰的链条，但能力较弱的团队却将MIL视为可选环节，因为代码和硬件给人的感觉更为具体。这种习惯会延缓验证进程。如果V模型的早期工作包含可执行的设计检查，那么后期阶段就无需花费太多时间来验证基本意图，而是将更多时间用于软件执行质量、集成时序以及物理接口的准确性。

可执行的工厂模型能让控制器行为在早期阶段就显而易见

可执行的 plant 模型能够直观展示控制器的工作行为，因为它们提供了静态分析无法呈现的动态输入、状态反馈和运行约束。这些模型将控制逻辑转化为一个闭环系统。您可以观察到随时间推移而发展的相互作用。正是在这种情况下，不稳定、延迟或矛盾的响应才会显而易见。

假设有一个具有限流、调速和过热保护功能的电机驱动控制器。被控对象模型可以再现控制回路中的负载阶跃、传感器噪声和饱和效应。如果在突然出现转矩请求时，限流器与调速器产生冲突，则这种相互作用可在 仿真中可测得。在预约变频器或测功机进行测试之前，您就能提前发现超调、延迟或振荡现象。

被控对象的质量决定了MIL值的上限。简化的被控对象虽然可以用来验证状态逻辑或阈值处理，但无法揭示那些依赖于更强物理效应的耦合效应。应根据具体研究问题调整仿真保真度。如果测试目标是瞬态控制质量，则被控对象必须以足够高的精度再现瞬态行为，使其结果具有实际意义。

测试用例应能直接追溯到系统需求

MIL 中的测试用例应与系统需求直接对应，以便每个结果都能解答一个关键的设计问题。这种可追溯性使测试失败具有可操作性。它还能防止基于模型的测试沦为一长串虽有趣但缺乏验证价值的图表。如果一个测试与需求没有关联，它就很难为后续的工程步骤提供指导。

制动混合控制器就是一个很好的例子。您可以根据扭矩分配限制、再生制动切断规则、踏板响应时序以及故障备用状态来构建测试用例。这些关联使团队能够专注于系统义务，并确保工作与验证紧密结合。首次测试通常应涵盖以下与需求相关的检查：

• 正常工作点应与规定的控制目标相符。
• 传感器丢失时，应触发相应的备用状态。
• 执行器的限位应确保在规定范围内保持系统稳定性。
• 启动和关闭流程应遵守时序规则。
• 故障恢复应在通过有效检查后才恢复控制。

当MIL结果进入评审阶段时，可追溯性同样大有裨益。与需求相关的测试失败会提供精确的问题描述、预期响应以及证据链。这既能缩短讨论时间，也有助于团队就接下来必须修复的内容达成共识。如果没有可追溯性，测试失败往往会演变成关于模型假设的争论，而非针对性的设计修正。

“模型在环”与“软件在环”有何区别

“模型在环”（MIL）与“软件在环”（SIL）的主要区别在于：MIL 测试可执行的设计，而 SIL 测试软件的实现。MIL 旨在验证控制意图是否正确，SIL 则旨在验证代码是否保留了该意图。每个阶段都回答不同的验证问题。

速度控制器使这种分离一目了然。MIL 可以验证增益调度、防饱和逻辑和故障状态在针对被控对象模型的测试中是否按预期工作。随后，软件在环（SIL）测试会检查，无论是生成的软件还是手动编写的软件，在相同的输入和时序假设下是否产生相同的输出。如果 SIL 测试中出现不一致，则表明存在实现、数据类型、求解器或代码生成方面的问题。

“MIL询问控制意图是否正确。”

MIL的结果应为向SIL的过渡奠定基础

MIL 结果应为向SIL的过渡提供框架，因为它们在代码执行成为重点之前，就已明确了预期输出、验收范围、边界情况以及状态覆盖率。这种框架能减少关于“软件成功”定义的争议。您已经知道预期响应是什么。随后，SIL 会检查实现是否保留了该响应。

主动悬架控制器提供了一套实用的测试序列。MIL 测试可识别车辆驶过坑洼、车身侧倾以及传感器失效时预期市场活动减震器控制指令。这些场景在 SIL 回归测试中则转化为带有数值公差和通过标准的测试用例。对于在后续执行阶段使用OPAL-RT的团队而言，当 MIL 测试结果已按该级别规范详细描述了接口、采样时间和验收限值时，他们将获得更大的价值。

只有当你保存的内容不仅限于测试用例时，这种交接才能发挥最佳效果。请将输入集、预期状态转换、信号容差以及故障说明存储在一个联系表 ，联系表 软件联系表 能够重复使用。这样，你将减少重建测试所花费的时间，而将更多时间用于检查有意义的差异。SIL 应该被视为一种更严格的实现检查，它复用了 MIL 中的同一套证据基础。

MIL 验证可降低 HIL 测试前的硬件测试风险

MIL 测试结果有助于降低硬件在环测试前的硬件测试风险，因为它能排除那些物理测试台难以诊断的设计缺陷。在时序、接口和电子元件纳入测试范围之前，它就能缩小未知因素的范围。这节省了昂贵的实验室测试时间。此外，它还能使 HIL 测试专注于集成行为，而非基础控制逻辑。

一个电动助力转向控制器便能说明这一点。如果MIL（模型在环）测试已经验证了助力曲线、故障锁存和扭矩叠加规则，那么HIL（硬件在环）测试就可以专注于传感器延迟、总线时序以及执行器接口行为。如果硬件到位时这些基础问题仍未解决，那么每次故障的定位都会变得更加困难。届时你只能困惑地自问：问题究竟出在设计、代码、布线还是测试台设置上。

HIL 的作用不同，若在早期设计阶段就承担设计不确定性，成本将过于高昂。测试台资源、技术人员和仪器使用时间都十分有限。当 MIL 提供证据证明预期控制行为稳定时，便能保护这些资源。随后，团队便会将 HIL 用于其最擅长的领域：在物理约束和接口时序条件下验证执行情况。

MIL的保障缺口会在后期阶段造成虚假的安全感

当模型虽然通过了常见场景的测试，却遗漏了边界条件、故障处理或需求边界时，MIL测试覆盖率的缺口会带来一种虚假的安全感。这种通过率虽然令人安心，却具有误导性。在后续阶段，原本应该在更早阶段就发现的基本设计问题便会暴露出来。这种疏漏通常会导致返工、延误和技术债务。

一款热管理控制器即使通过了标称冷却测试，仍可能在传感器冻结、水泵性能退化或阈值抖动等情况下表现极差。这些疏漏往往源于测试范围过窄或对工厂工况的假设不充分。它们极少是出于恶意。与软件质量低下相关的技术债务在 1.52万亿美元。隐藏的验证漏洞正是导致技术债务悄然累积的原因之一。

“出色的MIL工作能赢得信任，因为它明确界定了哪些内容已涵盖、哪些尚未涵盖。”

应记录未支持的运行区域、简化的厂址假设以及仍在审查中的需求领域。这种坦诚的态度使得后续出现的故障不那么令人意外，也更容易定位原因。OPAL-RT非常契合这一严谨的流程链，因为将早期建模与后续的实时验证视为一条连续的验证路径时，二者才能发挥最佳效果。