在设计一个嵌入式系统的过程中，模型可以在许多方面帮助设计师。随着系统复杂性的增加，MBD最终会变成一个支持系统设计必需的方法。因此，采用MBD的一个核心动机就是作为补救措施，以管理系统的复杂性。

汽车嵌入式系统的研发必须处理（至少）三个方面的复杂性：工艺复杂性、产品复杂性和组织复杂性。研发过程面临着一些挑战、冲突和不断变化的需求。比如，一个这样的例子可以是一个主动安全系统给驾驶人提供制动辅助。嵌入式系统的研发必须考虑驾驶人舒适性、安全性、可靠性和性能的要求，以及紧张的硬件成本预算和现有的功能、组件/平台、技术与机械设计所施加的限制。不同的需求通常与几个利益相关者联系起来，需要建立起一种相互理解和利益折中平衡。进一步的发展涉及协同和利用多个领域的一些技术、工具和活动。其中集成是必不可少的，但受到不同研发速度（硬件与软件）、不易实现交换操作的工具、分布信息以及分布在不同的组织实体中任务的挑战。汽车嵌入式系统技术异质性也带来复杂性。该系统行为通常是非平凡预测，因为存在许多类型的实体和相互作用以及由此产生的大的系统状态空间。组织方面关注的是从不同的工程团队和组织资源的整合（人、工具与信息等）。

为了管理这种复杂性，MBD的方法可以为设计师提供四个主要的研发活动的支持：交流、记录、分析和设计综合。一个MBD的方法，通过它隐含的相关技术和理论，提供了几种手段来支持这些活动，它们包括抽象化、形式化、预测和自动化。基于对这些活动的支持，可以总结出：迭代和组合比如说用于变更管理活动也可以提供支持。

10.2.1.1 交流的想法和设计

图片描述的软件和系统已使用了几十年，表明需要使用简化的系统描述来进行交流——“图片可以说明一千多字，或代替数行代码”。由于系统复杂性的增加，图片描述的作用已经变得越来越重要^{[10、14、48、73]}。提供一个或多个共享系统在模型方面的意见是设计的核心概念传达给其他利益相关者的一个重要途径。通过提供一种语言和术语标准化、建立一致系统模型，还可以促进开发人员之间的交流。如果模型包括一个可执行的行为描述，那么这将实现可视化，也就是可以看到系统是如何进行交流的。这个属性被认为是非常重要的，它支持各种利益相关者进行的特性确认——“这是一个理想的产品特性吗？”可执行的模型可以用于所需的或预期的设计特性的交流，从而也可以构成人的分析和决策的基础。应该指出的是，图表或图片并不总是能提供最充分的表示。已经提出了许多其他的符号，它们包括设计结构矩阵和表格表示^[15、75]。

10.2.1.2 记录和管理设计信息(www.daowen.com)

考虑到它们的生命周期包括开发、生产、维护和退役，文档对于诸如汽车嵌入式系统这样的产品来说是极为重要的。合适的记录对于支持维护、系统变更、已经开发出来的系统设计/组件的复用等是必不可少的。随着产品复杂性的增加，记录将不再满足于使用基于文本的文档了。特别是，管理文档的变化和发布一个巨大的文件版本将变得非常烦琐，它可能会延误其他零部件的开发。它也会变得难以处理重叠和相对于其他设计构件的依赖关系，例如，需求文档和设计规范（要求的变化将需要更新，或至少检查受影响的部分设计）之间的依赖关系。设计实体的不同版本和产品配置的变种版本进一步带来了复杂性。可能的部件组合数量，造成很难为一个完整的产品线设置一个有效的通用文档。汽车系统研发中的并行工程带来了更多的挑战，因为当多次访问相同信息和相同信息发生变化时，需要保证信息的一致性^[38，50]。利用信息模型描述涉及的信息实体以及它们之间如何相关的基于模型的信息化管理，可以促进复用和维护。基于模型的信息管理方法，通过记录基本原理、设计的假设以及设计实体的状态，可进一步提高复用和维护功能。通过附加约束、引用和设计实体属性（包括“元数据”的描述，例如谁负责设计），做到这点是有可能的。另一方面，需要额外的工作来提供元数据，以及规范的开发流程来支持MBD方法。

10.2.1.3 设计系统的支撑分析

分析可以为了设计空间探索的目的进行，以验证系统符合规定或验证的目的，以保证要求和期望的行为确实是那些系统利益相关者的预期。分析对于嵌入式系统特别重要，这是因为它们的异质性（存在许多实体与相互作用的类型）和可靠性所要求的。困难的、昂贵的、甚至无法人工检查的属性案例，包括系统的逻辑修正（甚至较小的嵌入式系统也可以有一个大得离谱的状态空间）、系统时序行为（特别针对分布式系统）、系统的错误行为（出错的来源有很多，通过什么方式错误可能传播）。此外，嵌入式系统与它的环境深入互动，因而要求嵌入式系统的建模和分析与它的环境放在一起。MBD可以是传统验证技术的一个非常重要的补充，它包括了审查、测试（通过启动仿真、快速成型、基于模型的自动化测试）和正式验证。许多汽车的嵌入式系统的品质或环节是互相依赖的。比如，系统结构的改变提高了系统的灵活性，但降低了性能。给定一个正式的系统模型，允许用一个更加系统化的方式探讨系统设计参数和品质之间的依赖关系，提高设计折中的品质。为支持所有这些类型的分析，需要捕捉待分析系统的相关方面的系统描述，比如所需的特性、功能和实现的设计以及环境特性。

10.2.1.4 综合解决方案和支持文件

我们使用术语综合是为了反映设计和支持文件，比如文档的创建（或组合）。此创建可手动或或多或少自动化。综合的第一步是捕捉设计师的想法（心智模式）或其他信息，比如计算机模型中的约束。给定的形式化模型，可以通过使用交流和分析模型或添加的目的在于随后使用或复用的信息。人工创建和操纵的设计（其中新的和现有的元素组合在一起，从而形成一个整体）由建模语言（用文字或图形表示）和提供模型编辑器的工具支持。当规则已定义了如何创建模型后，自动综合是有可能的。存在几个自动综合的案例是可能的。一个案例是系统解决方案生成，其中计算机工具用于搜索或派生系统解决方案，如一个可行的调度或分布式嵌入式系统中的任务最优分配（见参考文献[6]）。另一个案例是从模型生成代码。行为设计开发往往用图形化建模语言/工具，如Matlab/Simulink^[102]。这些模型可用于分析功能的行为，且以后被用作相应实施的规范。在许多情况下，这种实施是由其他团队来实现的，因而留下了对规范误解的空间。这可能会导致设计和执行之间的差异，并在执行中可能出现失败，这些问题都可以使用代码生成来缓解。代码生成可以被用于多种用途，可以适用于应用逻辑、粘接代码或平台的功能部分。尽管逆向工程构成了嵌入式系统的一个研究领域，但逆向工程（创建模型以更好地了解现有的系统，例如，从观察到的行为到任务行为模型）还是综合的另一个实例。综合的其他案例包括文档、测试信息和分析模型的生成。