工程软件开发的敏捷和基于模型的设计

如今，大多数为工程应用开发软件的团队都认识到传统(瀑布)方法的缺点。这些包括在项目的后期阶段发现缺陷和设计问题，不能适应需求的变化，以及交付不能满足客户需求的系统的风险。

为了克服这些缺点，许多团队已经采用了一种将敏捷方法与基于模型的设计相结合的方法。

对基于模型的设计和敏捷方法的研究表明，基于模型的设计补充了工程应用的敏捷，甚至使敏捷成为可能。与敏捷一样，基于模型的设计起源于支持快速迭代。万博1manbetx它还满足了敏捷无法单独解决的系统工程挑战:

• 在没有设备的情况下如何进行早期测试
• 如何管理工程系统的复杂性
• 如何降低在昂贵的硬件上测试未经验证的软件的风险
• 如何满足功能安全和其他标准的要求，包括DO-178B/C和ISO 26262

本文通过一个将基于模型的设计与敏捷方法和Scrum框架结合起来的自适应巡航控制示例，解释了万博1manbetx基于模型的设计如何支持敏捷开发的核心价值。

将敏捷的核心价值映射到基于模型的设计

敏捷宣言为软件开发定义了四个核心价值:

• 个人和交互胜于过程和工具
• 工作软件优于全面的文档
• 客户合作胜过合同谈判
• 对变化做出反应，而不是遵循计划

宣言的作者指出，“结束”并不意味着“不”。他们提出的是重点的转移:“虽然右边的项目有价值，但我们更看重左边的项目。”

让我们看看这些敏捷价值是如何映射到基于模型的设计的。

关注个人和互动

基于模型的设计的过程和工具——特别是建模和仿真——促进了个人和团队之间的有效交互。该模型可以直接在Simulink中共享万博1manbetx^®，或作为一个网页，使所有利益相关者使用它作为一个共同的参考点和唯一的真相来源。模拟结果是清晰可见的，可以促进设计决策、Scrum计划以及与涉众的讨论。

注重客户协作

客户协作是敏捷方法的核心。每个sprint以计划会议开始，以评审会议结束，在评审会议中经常邀请客户提供输入。建模和仿真不仅支持高效的客户协作，而且还支持跨团队、领域和规程的协万博1manbetx作。来自硬件设计、系统设计以及功能和组件开发的工程师使用一种共同的语言，可以专注于一起工作，而不是担心工具。

专注于工作软件

对于使用敏捷的团队来说，基于模型的设计的主要优势之一是能够从他们最早的冲刺阶段开发系统的工作版本，即使嵌入式目标、工厂、传感器或其他硬件不可用。通过万博1manbetx仿真验证的Simulink模型可作为工作软件贯穿整个项目。模型充当正在开发的系统的可执行规范。在早期的sprint中，当硬件可能不可用时，模拟结果可以与客户共享，而不是硬件测试结果，并用于评估进度，征求购买，或计划下一个sprint。模型还提供了一种清晰方便的方法来衡量进展。随着模型的详细阐述，它可以用于为软件在环(SIL)、处理器在环(PIL)和硬件在环(HIL)测试以及实时原型和生产系统生成代码。

该模型还可以作为综合文档的基础。在基于模型的设计中，文档是设计过程的输出，而不是一个离散的任务，并且文档和报告可以根据需要从模型中生成。

专注于应对变化

瀑布式开发的主要障碍是无法充分响应不断变化的需求和条件。敏捷开发和基于模型的设计解决了这一缺陷，并使团队能够更有效地响应变更。对于工程应用程序中的任何重要更改，使用基于模型的设计的工程师可以修改模型，然后简单地重新生成代码。在实现任何变更之前，团队可以运行假设分析，以确定适应特定变更请求的最佳方法。在模型中进行更改之后，工程师可以运行回归测试的模拟，以确保更改不会在系统中引起意外的行为。当模型链接到需求时，团队可以执行影响分析，以了解对模型一部分的更改将如何影响其他部分。

用例:结合敏捷方法和基于模型的设计开发自适应巡航控制器

在这个例子中，一个汽车工程团队正在开发带有传感器融合的自适应巡航控制系统软件。该系统融合来自车载雷达和视觉传感器的输入数据，以识别最重要的目标及其与自我车辆的距离，以适应速度并保持安全距离。

在这个项目中，一组工程师致力于开发控制算法，另一组则开发驾驶场景和合成传感器数据。这些合成数据将使工程师能够在实际传感器数据可用之前很好地开发和测试算法。使用合成数据的早期模拟可以为设计决策提供信息，例如车内传感器的类型、数量和位置。

在第一个sprint中，每个子团队(或工程师组)对各自的子系统建模，使用共享的系统级Simulink模型来协调他们的工作(图2)。即使在这个早期阶段，他们也可以运行模拟来查看控制器在各种条件下的行为。万博1manbetx在编写或生成一行代码之前，他们调试控制器，确定要优化的参数，并从系统的工作版本中可视化关键性能指标。

在第一个sprint结束时与客户的回顾会议上，他们分享模型和仿真结果(图3)。模型和结果提供了工作软件的具体表示——例如，通过说明在另一辆车进入其车道后车辆的速度如何下降。

在随后的sprint中，团队根据客户反馈改进或增强模型(例如，通过调整安全跟随距离或改变车辆加速或减速的速率)，并优化模型以生成代码并部署到ECU。生成的代码可以按原样使用，也可以作为更大系统的一部分与遗留代码集成。使用Jenkins™的持续集成(CI)用于持续检查生成的代码和手动代码的集成，在模型上运行测试，检查是否符合建模标准，然后对生成的代码执行测试。自动报告所有这些活动的结果，以跟踪进展，并为未使用开发工具的涉众提供帮助。

在后面的sprint中，团队会合并更严格的验证和验证活动，包括SIL、PIL或HIL测试，以确保设计满足需求。他们还检查模型和代码是否符合已建立的标准和指南，使用静态分析和正式方法来证明没有关键的运行时错误，并生成报告和其他工件，为标准认证做准备。

随着项目的进展，客户的需求也会发生变化。例如，客户可能会要求模型预测控制，而不是经典的控制算法，因为先进的MPC控制器使车辆能够对环境中其他车辆更激进的机动做出反应。由于在这个项目中使用了一个系统模型，算法团队可以很容易地用新开发的模型预测控制器替换原来的控制算法，而模型的其余部分保持不变。团队重新运行模拟，并与客户共享结果。然后可以做出明智的决定，决定是继续进行设计更改还是恢复到以前的方法。

该团队在他们的敏捷开发工作流中使用基于模型的设计，并在涉及硬件之前交付了可工作的软件。建模和仿真使团队能够基于客户反馈不断地改进设计，甚至在项目后期适应重大的需求变更。