在这里，我们假设已经由一个组织仔细介绍了MBD的方法。因此我们假设引入MBD方法的驱动因素非常强。如果驱动因素弱，或如果不进行正确的方式采用MBD技术，那么这些好处不能指望。驱动因素和成熟MBD工具可用性或已建立方法之间的不匹配，可以解释引入MBD方法时的一些问题^[82]。鉴于这些先决条件，MBD可以提供以下好处^{[2、7、48、50、54、58、63、66、69、78、82、85]}：

·投入市场所需的时间。提高生产率可以通过直接和间接的方式来实现，其中一个关键因素就是提供更高效的决策。一个直接效果的实现，就是通过采用并行工程和在完整产品完工之前的设计概念（例如控制、软件或硬件）的评估。通过自动的研发步骤，尤其是那些烦琐、容易出错而且消耗大量的努力——以测试、分析和模型的操纵/转换活动为代表，也可以取得直接的效果。间接效果是通过改进记录以及开发人员/利益相关者之间的交流来实现——意味着工作本身可以成为更有效率（例如，一致信息的更快速度检索）和更有效果（例如，增加所涉及的利益相关者的相互了解）。另一个改进是通过早期的错误检测和质量反馈、特别是支持通过模型分析和早期的基于模型的集成努力来取得。这种努力使得研发中的迭代次数以及生产中、生产后的问题最小化。因此，与非MBD方法相比，一个成熟的MBD方法可以期待减少开发时间。另一方面，更快的迭代意味着赢得的时间（例如）可以用于提高系统的质量或包括更多的功能方面。

·减少各类费用。通过计算机辅助优化，MBD可以有助于降低生产成本，它是通过更具成本效益的解决方案的选择来实现的。MBD还可以提高产品的质量，从而降低了维护成本。汽车嵌入式系统的开发成本正在增加。使用合适的工具可以帮助开发人员更好地管理日益增加的复杂性，从而使得研发更具成本效益。

·质量保证和质量增强。正如上面所提到的，自动化可以减少故障的发生。通过改善对设计中系统的理解，使用模型也有间接的效果——从而使质量保证工作更有效。用模型形式化系统的工作也可以简单地提供便利：通过改进设计中系统的理解并作为一种对系统的审查。然后可以进一步取得增强验证：通过基于模型的系统分析和测试，帮助确保所需的系统质量，并在相互冲突的质量中取得平衡。基于模型的方法在某些安全关键系统中可能是强制性的，它为安全论证提供了一个良好平台。也可以使用基于模型的方法优化系统质量。一些调查指出这样的事实：复杂系统设计中的主要问题是需求工程。这里MBD可以协助需求更易于管理、交流和分析。

·功能内容增加。提供更多的功能来应对复杂性（通常涉及更多的利益相关者、关注）、和相应的信息、分析、折中的增加。这些问题正是MBD要解决的目标，从而为它们提供支持。

·创新性。有经验迹象表明：MBD的方法也可以支持企业的创新，就是生产新产品、功能和/或解决方案的能力^[2、57]。据了解，根据CAD系统早期经验：适当的CAE工具可以支持开发者的创造力，有利于他们的探索和概念与解决方案的评估。MBD工具（例如通过仿真和快速成型）也为嵌入式系统支持快速验证和确认（V＆V）。实证研究结果也支持正确使用MBD也可以帮助促进多学科团队之间的交流的观点^[2，49]。理想情况下，一个系统级的信息/知识管理系统应该支持存储、检索、思路和解决方案的匹配，从而提高创新能力。(www.daowen.com)

建模需要额外的努力，以初步建立模型，除非它们已经被创建，并且可以重复使用，但此后可能产生与整个开发过程有关的时间与成本节约的二次效应。为了这些目的，必须分配资源和时间。对于以前一直没有采用MBD的企业，改善流程效率（开发时间和/或成本）可能会发生，但不能指望在第一个项目上出现。

为了评估MBD的优点，与工程中常见的替代方案进行比较也是有用的^{[30、41、56]}，其中替代方案包括“社会设计”和“利用纸质文件设计”。当MBD采取明确的和计算机化的模型时，社会设计依赖社会隐性知识、社交网络、熟练的和常驻人员，以及使用物理样机和测试。基于文档的方法介于社会设计和MBD之间。也可以采用模型，但不是那种适用于计算机操作的模型。信息的粒度可以被认为是粗粒度的，在于文档提供了信息所提供的粒度。MBD强调使用正式的和计算机化的模型作为中心思想的载体。信息粒度可以是粗粒度或细粒度，细粒度实体对应设计工件，如个别规定或软件实体。改进后的文档减少了对个体的依赖关系^[30]。

在一个典型的和传统的嵌入式系统的开发方案中，使用文本文档，编写和编译C代码到微控制器中。这种做法虽然对于一个简单的系统可能足够了，但是随着复杂性的增加，局限性也是相当明显的。因此，针对这种方法的工作，复杂性需要以另一种方式来处理，例如，通过使用一个约束的体系结构，限制太复杂功能的引入。MBD方法在模型提供的文档中处理这个复杂性，使用工具支持分析和集成，在抽象中通过隐藏的详细分析来维护全貌。

合适的产品架构构成了主要成分，而不管哪一种做法。现有的汽车架构一直是基于硬件级别的模块化，并在网络层面采用接口。这样一个计划在很长一段时间内已经证明是令人满意的，但不能妥善处理日益增加的、电子控制单元（ECU）依赖的交叉性，同时也不能为包含软件和硬件的产品线提供基础。目前，软件架构在汽车开放系统架构（AUTOSAR）举措中是强调的，并提供软件架构以及用来描述和配置软件/硬件组件的方法^[31、94]。这种基于组件的软件方法前进了一步，但仍然不够，因为功能与非功能性的质量、系统内容并不在建模工作范围之内^{[17、40、81]}。

因此，一个组织有在这三种方法之间做出选择的可能性。一旦做出决定选择MBD方法，那么就存在一个战略需要——就是如何从现有的、目前占主导的方法迁移到MBD方法上。在实践中，也有关于如何使方法并存的战略需要。提到MBD的优点不容易，它们确实需要努力、战略选择、语境需求的理解。这些语境需求是下一节的话题。