今天，大多数为工程应用程序开发软件的团队都认识到传统(瀑布)方法的缺点。这些包括在项目的后期阶段发现缺陷和设计问题，无法适应需求中的变化，以及交付不满足客户需求的系统的风险。
为了克服这些缺点，许多团队采用了一种将敏捷方法与基于模型的设计相结合的方法。
对基于模型的设计和敏捷方法的考察表明，基于模型的设计补充了工程应用程序的敏捷，甚至使敏捷成为可能。与敏捷一样，基于模型的设计也起源于支持快速迭代。金宝app它还能应对仅靠敏捷无法解决的系统工程挑战:
- 如何在没有设备的情况下进行早期测试
- 如何管理工程系统的复杂性
- 如何降低在昂贵的硬件上测试未经验证的软件的风险
- 如何满足功能安全和其他标准的要求，包括DO-178B/C和ISO 26262
本文通过一个将基于模型的设计与敏捷方法和Scrum框架相结合的自适应巡航控制示例，解释了基金宝app于模型的设计如何支持敏捷开发的核心价值。
敏捷和基于模型的设计:基础
敏捷软件开发方法是建立在敏捷宣言，出版于2001年。今天，敏捷开发中最广泛使用的框架之一是Scrum。在Scrum中，开发以一系列被称为冲刺，在这种情况下，团队在一段时间内(通常在一两个星期到一个月之间)处理项目backlog中的功能子集。在每个sprint中，团队开发、测试、集成并记录工作软件(图1)。
图1所示。使用Scrum框架进行敏捷开发。
基于模型的设计是一种以模型为中心的系统开发方法。基于模型的设计在整个开发过程中使用模型，而不是依赖于物理原型和文本规范进行通信。该模型包括与系统行为相关的所有组件——算法、控制逻辑、物理组件和环境。一旦模型被开发(细化)，它就可以用来生成代码(C/ c++， HDL，或结构化文本)，报告和其他类型的文档。基于模型的设计的核心组件是系统级和组件级的设计和仿真、自动代码生成以及持续的测试和验证。
将敏捷的核心价值映射到基于模型的设计
敏捷宣言定义了开发软件的四个核心价值观：
- 过程和工具上的个人和交互
- 工作软件胜过全面的文档
- 合同谈判中的客户协作
- 响应变化胜过遵循计划
宣言的作者指出，“结束”并不意味着“没有”。他们提出的是重点的转变:“虽然右边的项目有价值，但我们更重视左边的项目。”
让我们看看这些敏捷值如何映射到基于模型的设计。
关注个人和互动
基于模型的设计中的过程和工具——特别是建模和模拟——促进了个人和团队之间的有效交互。该模型可以在Simulink中直接共享金宝app®，在一份报告或网页，使所有利益攸关方使用它作为一个共同的参考点和单一的真相来源。模拟结果清晰可见，可以促进设计决策、Scrum规划以及与涉众的讨论。
专注于客户合作
客户协作是敏捷方法的核心。每个sprint都以计划会议开始，以评审会议结束，评审会议通常邀请客户提供意见。建模和仿真不仅支持高效的客户协作，还支持跨团队、领域和学科的协作。hardwa的工程师重新设计、系统设计、功能和组件开发都有一种通用语言，可以集中精力协同工作，而不用担心工具。金宝app
专注于工作软件
对于使用敏捷的团队来说，基于模型的设计(Model-Based Design)的主要优势之一是，即使嵌入的目标、植物、传感器或其他硬件不可用，也能够从早期的sprint开发系统的工作版本。通过金宝app仿真验证的Simulink模型可以作为工作软件在整个项目中。模型充当开发中的系统的可执行规范。在早期的sprint中，当硬件可能不可用时，模拟结果可以与客户共享，而不是硬件测试结果，并用于评估进度、征求支持或计划下一个sprint。模型还提供了一种清晰和方便的方法来衡量进展。随着模型的细化，它可以用于生成软件在环(SIL)、处理器在环(PIL)、硬件在环(HIL)测试以及实时原型和生产系统的代码。
该模型还可作为全面文档的基础。在基于模型的设计中，文档是设计过程的输出，而不是离散的任务，文档和报告可以根据需要从模型生成。
专注于应对变化
瀑布式开发的一个主要障碍是无法充分响应不断变化的需求和条件。敏捷开发和基于模型的设计解决了这一缺点，使团队能够更有效地响应更改。对于工程应用程序中的任何重要更改，使用基于模型的设计的工程师可以修改修改模型，然后简单地重新生成代码。在实施任何更改之前，团队可以运行假设分析，以确定适应特定更改请求的最佳方式。在模型中进行更改后，工程师可以运行回归测试模拟，以确保更改不会导致系统中的意外行为。and当模型与需求相关联时，团队可以进行影响分析，以了解模型某一部分的变更将如何影响其他部分。
用例:结合敏捷方法和基于模型的设计开发自适应巡航控制器
在本例中，一个汽车工程团队正在为带有传感器融合的自适应巡航控制系统开发软件。该系统融合来自车载雷达和视觉传感器的输入数据，以识别最重要的物体及其与车辆的距离，以适应速度并保持安全距离。
在这个项目中，一组工程师负责开发控制算法，另一组则负责开发驾驶场景和合成传感器数据。这些合成数据将使工程师能够在实际传感器数据可用之前开发和测试算法。使用合成数据的早期模拟可以为设计决策提供信息，例如车内传感器的类型、数量和位置。
在第一个sprint中，每个子团队(或工程师组)使用一个共享的系统级Simulink模型来协调他们的工作，为其各自的子系统建模(图2)。即使在这个早期阶段，他们也可以运行仿真来查看控制器在各种条件下的行为。金宝app在编写或生成一行代码之前，它们会调试控制器，识别要优化的参数，并从系统的工作版本中可视化关键性能指标。
图2.带有传感器融合金宝app的自适应巡航控制系统的Simulink模型。
审查会议期间与客户第一sprint快结束的时候,他们共享模型和仿真结果(图3)。该模型和结果提供一个具体的工作软件的例子中,通过举例说明如何另一辆车后车辆的速度减少转移到车道上。
图3。对自适应巡航控制模型进行了仿真。
在随后的冲刺中，团队根据客户反馈完善或增强模型，例如，通过调整安全跟车距离或改变车辆加速或减速的速率，并优化代码生成和部署到ECU。生成的代码可以按原样使用，也可以作为更大系统的一部分与遗留代码集成。与Jenkins的持续集成（CI）™ 用于连续检查生成代码和手动代码的集成，在模型上运行测试，检查是否符合建模标准，然后对生成的代码执行测试。所有这些活动的结果都会自动报告，以跟踪进度，并供未使用开发工具的利益相关者使用。
在后期的sprint中，团队将更严格的验证和验证活动纳入其中，包括SIL、PIL或HIL测试，以确保设计满足需求。他们还检查模型和代码是否符合已建立的标准和指导方针，使用静态分析和正式方法来证明关键运行时错误的缺失，并生成报告和其他工件，为标准认证做准备。
随着项目的进展，客户需求可能会发生变化。例如，客户可能会请求模型预测控制，而不是经典的控制算法，因为先进的MPC控制器使车辆能够对环境中其他车辆更激进的操纵作出反应。由于本项目使用的是一个系统模型，因此算法团队可以轻松地用新开发的模型预测控制器替换原有的控制算法，并保持模型的其余部分不变。团队重新运行模拟并与客户共享结果。然后，可以就是否继续进行设计变更或恢复到以前的方法作出明智的决定。
这个团队在他们的敏捷开发工作流中使用基于模型的设计，并在涉及硬件之前就交付了可工作的软件。建模和模拟使团队能够基于客户反馈不断改进设计，甚至适应项目后期的重大需求变更。
