基于模型的设计通过早期验证最大限度地发挥优势

基于模型的设计 （MBD） 通过仿真测试执行验证和确认。尽管许多组织使用某种形式的建模，但太多的组织以不利用潜在验证优势的特殊方式应用模拟（参见图 1）。

图 1：整个开发阶段的故障传播成本说明了一些组织如何没有利用仿真的验证优势。

为了最大限度地发挥 MBD 的优势，成功的组织实施了四种有助于完成早期验证的关键实践：

· 在规范阶段创建和模拟高级系统模型。在 MBD 中，系统模型用作可执行规范。该模型的早期模拟突出了不完整和不一致的要求和规范。

· 从第一天开始就使用多域模拟进行测试。通过开发多域模型和执行闭环仿真，工程师可以在产品创意成型的同时开始测试。这些仿真使工程师能够研究系统的所有方面，包括算法、组件、工厂模型和环境。

· 创建对系统施加压力的虚拟测试套件。仿真使工程师能够进行一系列难以或不可能在嵌入式系统本身上执行的测试。像所有测试一样，这些测试应该尽早运行。

· 在整个开发过程中使用模型和测试套件作为参考设计。构建良好的模型可以在整个开发过程中使用，然后再用于未来的增强和衍生设计。

这些实践应作为四个维度并行使用，以成功使用 MBD 进行早期验证。

创建和模拟高级系统模型

作为可执行规范，高级系统模型必须反映系统的抽象行为。该模型可能不包括完整的接口定义，但它必须指定系统的动态行为。在需求规范阶段模拟系统行为有助于确保团队对系统需要做什么有一个完整和共享的理解。

使用 MBD，工程师首先使用子系统或离散状态组装架构。这些子系统内的动力学最初应使用最简单的方法进行建模。在此活动的同时，其他工程师可以创建场景或形式化需求，为尽早测试动态做准备。

运行第一次测试时，建模功能行为的工程师将更多地了解系统和需求的真正含义。同样，创建测试场景或形式化需求的工程师将了解需求是否一致和完整。每一组应将他们的发现传达给另一组，以确保没有误解。

从第一天开始使用多域模拟进行测试

系统行为不仅由嵌入式控制软件定义，还由电子和机械组件定义，包括连接的传感器和执行器。执行架构的早期模拟在使用工厂或环境模型在闭环中执行时提供了更多的洞察力。

与开环仿真或在实际工厂硬件上进行测试相比，带有工厂模型的闭环仿真具有多个优势。一个优点是模型比金属、电线和 C 代码更容易更改。带有工厂和环境模型的闭环仿真降低了多个开发阶段的成本。与由钢、电线、电路和其他硬件构建的机械和电气设备相比，模型更容易重新配置和复制。工程师可以在物理模型的版本之间快速切换，而不会产生制造成本。通过简单地更改杆的长度或电动驱动器的最大扭矩等参数，团队可以评估权衡并针对成本、速度、功率和其他要求优化整个系统。

系统级优化需要多域仿真。通过一次调整一个参数来优化当今复杂的系统是不可能的。为了以最低的材料成本提供最高的能源效率和最高的性能，工程师必须优化整个系统，而不仅仅是嵌入式软件。

工厂模型提供了系统的另一个视角。对系统的非软件部分进行建模可以让工程师从另一个角度了解系统行为。工程师通常可以通过仿真而不是从真实系统中了解更多关于系统动力学的信息，因为仿真提供了力、扭矩、电流和其他在实际硬件上难以或不可能测量的值的详细信息。

创建工厂模型需要工程努力，但这种努力往往被高估，而工厂建模提供的价值却被低估了。在开发工厂模型时，最佳实践是从高级抽象开始并根据需要添加细节。选择一个足够详细以产生所需结果的抽象级别可以节省建模工作和仿真时间（参见图 2）。

图 2：作为基于模型的设计一部分的早期验证通过建模、仿真和自动代码生成简化了嵌入式控制设计。

创建对系统施加压力的虚拟测试套件

高效的测试需要关注点分离。组织应该在不同的开发阶段测试软件实施的不同方面。在测试算法之前测试通信和硬件效果会导致难以隔离和识别设计中的缺陷来源。

在最合适的地点和时间应用测试，使团队能够在每个开发阶段的正确级别上评估设计。在每个阶段，测试结果都应立即反馈给开发人员，以使设计能够持续改进。

功能测试涉及使用多域环境模型模拟控制器模型。功能测试中使用的测试向量基于形式化要求或记录的驾驶操作等场景。这些测试向量可以重复用于回归测试和完整的模型覆盖测试。

快速控制原型 （RCP） 为测试方案增加了实时验证和用户体验。RCP 可帮助工程师快速部署算法并在车辆中对其进行测试，以确定功能是否正确。在目标快速原型设计和功能快速原型设计平台的支持下，RCP 可以成为设计理念的丰富来源，但不应作为验证功能的主要方法。

稳健性测试旨在评估系统在软件参数变化、制造过程差异、机械和电气硬件在系统生命周期内退化以及类似影响的情况下的稳健性。最佳实践是在虚拟系统（包括控制器和环境）上运行参数扫描。随着对系统在边界条件下的性能有了更透彻的了解，工程师可以选择缩小硬件供应商的规格范围，或者得出结论认为具有稍高差异的较便宜的部件可以满足他们的设计需求。

硬件在环 （HIL） 测试使工程师能够在实验室而不是在真实环境中测试真实的控制器或控制器网络。HIL 测试可用于测试稳健性（例如，通过插入故障）或诊断大型控制器网络中的控制器间通信。它涵盖了无法轻松建模的硬件和通信效果。

与 RCP 一样，HIL 测试是系统验证所必需的，但不应将其用作功能测试的主要手段。这是因为 HIL 测试是在非常低的抽象级别上进行的——接近真实系统——因此结合了许多不同的影响，阻碍了有效的功能测试。

HIL 测试需要对硬件进行投资，范围从带有专用数据卡的标准 PC 到高端硬件机架。在这样的系统上执行的测试比在纯软件中执行的测试更少，因为软件测试可以更容易地在多台计算机上复制。这是确保在 HIL 测试之前验证功能的另一个原因。如果工程师在 HIL 测试中发现算法缺陷，那么上游验证过程可能是不够的。

使用模型和测试套件作为参考设计

在 MBD 中，所有关键开发任务都在模型级别执行。这意味着对生成的代码所做的任何修改也必须在模型中进行。在整个开发过程中使用模型和测试套件作为单一的事实来源，可以促进模型和测试的清晰沟通和有效重用，不仅适用于当前项目，而且适用于未来的增强和衍生设计。

将所有工件置于配置管理之下

软件工程师认识到配置管理系统 （CMS） 中版本控制代码的价值。MBD 中的关键工件——模型、测试和模拟结果——也应该在 CMS 中维护。在 CMS 中管理工件使团队可以轻松地重新运行虚拟测试并将当前测试工具与以前的模型状态或以前的测试向量进行比较。

当模型结构是模块化的而不是单一的时，版本控制模型效果最好。模块化模型结构还可以通过允许多个工程师并行处理同一系统的不同部分并启用并行代码生成来加速开发。

执行回归测试

软件工程师使用夜间构建来编译和测试源代码的最新版本。这种方法也应该应用于建模和仿真。一旦工程师定义了一个新的测试来验证特定的模型行为，该测试应该集成到夜间构建中，以确保特定行为在所有后续建模迭代中仍然有效。如果测试在某个时间点失败，则要么已识别出缺陷，要么功能已从根本上改变，并且测试不再适用。

尽早并经常验证

本文中概述的最佳实践使工程师能够实现早期验证，减少在开发周期结束时花费的时间测试和调试他们的设计。此过程的关键是 MBD，它可以将验证用作在整个开发过程中发生的并行活动。在开发过程的每个步骤中执行测试和验证意味着在引入错误时发现错误。与传统流程相比，可以更快地重复、修复和验证设计。

作者：Guido Sandmann，Joachim Schlosser，Brett Murphy

审核编辑：郭婷