基于在更成熟的工程领域积累的经验可以知道，为了实现经济有效的复杂系统的开发，模型的使用是一个基本步骤，案例详见参考文献[58，78，85]。工程中一直在使用模型。模型中隐含工程师的思维定式，其中建立的物理模型/原型和符号/数值模型，比如几何、运动或传热模型，是为了说明和评估系统的特定方面。计算机辅助工程（CAE）工具的问世开辟了创建虚拟产品的完全新的设计方法的道路，可用于评估和与利益相关者沟通设计，并作为系统实现的基础。这样的技术早就在机械工程三维车辆模型支持设计、分析和可视化（简称为数字/虚拟原型机或数字样机）中得到了确立，详细内容见参考文献[46，74，85]。

在CAE设置中的不同类型的符号和数值模型，允许属性和方案设计的评估先于物理样机研发。这些努力旨在以较低的成本较早实现设计迭代，从而明确地支持早期设计阶段，降低项目风险。开发早期可执行模型的能力意味着可针对系统利益相关者验证该模型的行为。它所具有的重要意义在于：系统内容、假设以及要求将有一个更好的机会被正确捕捉到，并在开发的早期，内在要求的折中能够做到更加明确。与此相关的是虚拟产品和快速成型的概念往往使得开发中的并行工程成为可能，例如允许概念评估在物理硬件可用之前。

众所周知，根据系统工程的观点，建模和仿真并不是最终目的本身，它们应该添加容易处理的值。建模与仿真在系统工程中，通常被称为降低风险的技术，并显示了在支持系统决策中的应用。从系统和机械工程的经验教训也表明，所有类型的模型——包括心理、生理以及象征性模型，都有它们自己的作用和位置，但同样计算机模型正在慢慢取代物理样机^[78，85]。

本章讨论专注于嵌入式系统的计算机辅助建模。在这个方面，有几个学科/领域促进了MBD的发展。案例包括“基于模型的控制设计”——其中控制系统是基于受控环境的模型设计；“模型驱动的设计”——强调软件的图形描述及模型转换的概念；“基于模型的信息管理”——其中模型用于说明和构建信息实体；以及“基于模型的测试”——其中设计或环境的模型是测试中使用的，比如硬件在环测试，或模型用于推导测试案例。其他相关的条款包括：基于模型的系统工程、形式化方法和模型驱动的工程。这些及其他的MBD解释，反映出考虑MBD的是以“领域/学科工程”（比如控制、软件设计）、“系统工程”（与整体嵌入式系统设计或“管理流程”比如信息化管理有关）为目的。

已经完成的若干种模型、建模语言、方法和方法论分类，它们反映了不同目的MBD的方法^{[10、20、21、48、51、66、71]}。案例包括区别：

•建模目的，比如分析、描述说明，或基于模型的设计。

•形式的程度和形式化的类型。

•不同的建模范围和抽象的层次，例如，系统内容建模相对于系统结构或行为建模，或规范建模相对于实际行为建模。

形式模型也可以称为数学或分析模型，它们已经表明是非常重要的澄清和解决工程问题的工具。针对预测系统性能目的，形式模型强调行为和结构。形式模型的案例包括计算机辅助设计（CAD）中的几何描述、用来描述动态系统输入输出（I/O）特性的传递函数、描述部分级数与有限状态机器的离散数学。

概念模型最经常以图形的形式来证明在传达和记录复杂软件和系统方面有价值。这样的概念模型的例子包括架构描述语言（ADL）和统一建模语言（UML）^[114]。概念模型的形式可以有所不同，例如，允许语法和一致性检查，但不允许对软件逻辑的正确性进行形式分析。(www.daowen.com)

建设性模型侧重于系统的操作行为，并形成了设计本身（从详细说明开始，一直到解决方案）的直接依据。软件和电子设备多年来的复杂性的增加，带来了进行中的系统设计的抽象层的发展。这方面的例子包括编程语言的发展：从汇编到高级语言、编程平台、库函数和中间层，并从门跨过寄存器、传输到系统级的硬件设计。其结果就是：系统设计由建设性行为模型规定，其中的中心思想是从高层次模型到实施的步骤实现自动化。

所有这些类型的模型紧密相关，且有时会部分地重叠。深刻地反映在这些类型的诠释和分类上：就是具有不同的目标、目的和建模工作范围，以及事实上一个单一的建模语言不能处理嵌入式系统的所有方面。汽车嵌入式系统的开发需要多个专家，他们中每一个的关注点各有侧重，例如：软件、电子、机电一体化、车辆动力学、电磁干扰和安全。每个群体提供包括工具在内的专门的方案，解决他们所从事领域内的问题。因而架构和集成就成为关键问题。

对于汽车的嵌入式系统来说，所有这些类别的模型都发挥了重要作用。在本章中，我们试图提供一个全面的MBD框架。只要形式模型、设计模型以及概念模型用成文的语法和语义构成明确的系统描述，且其中的模型语法和语义必须足够正式，满足计算机操作和一定程度的自动化分析，那么该框架允许形式模型、设计模型以及概念模型存在。

模型可以看作认知工具，可以对设计过程中需要的推理和决策方面帮助研发人员。特别地，模型的使用通过提高抽象层次，并提供对系统描述的专业看法，可以帮助开发者降低感知系统的复杂性。MBD还支持早期工作的复用、确定设计步骤的自动化和系统性能的预测。为了实现高效，模型因而构成实际或想象系统的抽象表示。为了实现有效，模型需要保留并带来与一个或多个与明确目标有关的此系统基本性质。

至于其他条款，存在很多的推荐MBD的定义。除了分辨模型的形式层次以及它是否适用于分析、设计与交流的目的，模型也可以被应用到系统的不同部分，应用在不同的抽象层次中，并应对不同的性质和设计参数。下面的章节将阐述这些内容和不同的诠释。

我们把MBD解释为：在基于模型的研发中，计算机模型作为系统开发的一部分，被用来支持交流、记录、分析和综合。在这种方法中，模型因而形成了不同机构团队之间互动的基础、同一研发阶段与不同研发阶段之间的信息流的基础，并形成制定设计决策的基础。

有趣的是MBD的一些定义或诠释包含了关键字“驱动”。研发可以还是应该由模型来驱动以及在何种意义上？从产品数据管理（PDM）和机械工程领域，提供了一个试探性的答案。在这些领域中，术语模型驱动涉及使用的不同类型的模型，它们包括技术产品模型（在设计过程中，代表如车辆的几何形状和动力学的产品的不同方面）、产品的信息模型（描述产品配置、零件和元数据）和开发过程模型（描述研发阶段、工作、事件和涉及人的角色）。当设计研发过程模型且在PDM系统中实施时，它实际上可以驱动设计，例如，在设计完成后尽快通知测试人员，或一旦有效的配置可以建立时，可以促使软件自动重建。因此，这种模型驱动工程概念覆盖了若干类型的产品模型以及流程模型。针对本章的目的，考虑到目前该领域的发展成熟性，我们发现越来越有充分的理由表明我们选择的术语MBD的合理性。

MBD方法意味着在一个机构中合理地利用一些技术。引入MBD本质上需要机构中对MBD熟悉的技能人才，需要理解采用诸如目标、驱动程序、需求与范围的背景。MBD方法可能需要对现存的流程与机构做出改变。同样重要的是，为针对MBD的技术与相关理论如何使用提供指导方针的方法论的有效性与发展。合理采用MBD，可以提高功能与产品质量，并促进研发更快、资源更省（这些目标存在冲突，合理选择MBD方法将能够突出一个或多个目标）。