汽车嵌入式系统的异质性，就不同领域、特点和性能而言，已经上升到一个非常大量的建模形式化、技术和工具来支持MBD。这些技术中的每一个只各自涵盖限定的系统关注点。这些技术并不总是整合，缺乏一个共同的术语和理解相结合的事实，可能会导致严重的问题。在MBD领域存在大量的研究课题，包括建模语言、模型的集成和管理方法、方法学、用于分析的具体技术、系统的细化、从系统规范生成的测试案例、优化和综合技术、逆向模型工程（其中现有的软件/硬件的模型可以用系统的方法创建）、建模重构系统、表示复杂系统的人机界面（HMI）、部件模型和平台。几个主题也是相互关联的。这个不断发展领域的一个挑战，是由于其多学科性；该主题在许多领域内进行了探索，包括系统工程、嵌入式软件、电子设计自动化、可靠性和安全工程、控制工程、机电一体化、汽车工程，以及更多，它们大多出现在相应的会议和期刊上。在下面，我们将专注于上述前三个议题，并强调在嵌入式系统工程方向上的努力。

10.5.2.1 嵌入式系统的建模语言

如图10.3所示，在嵌入式系统的研发中有或已经存在大量的语言。在这里，我们专注于两类语言，即ADL和行为建模语言。为了支持设计和系统集成，存在嵌入式系统标准化描述的强烈需求，这已促使了ADL的发展。一个典型的情况就是针对一个系统集成商，他应该指定和集成大量组件（功能、软件、电子、传感器和执行器）。系统描述语言可以使这样的集成系统实现通信、记录和协调，以及正式的分析和系统自动综合。一个综合的典型案例就是生成粘贴代码/逻辑，例如支持软件组件之间的交互。ADL的重点是系统结构，它们可能处于不同抽象层次上。然而，通常还提供一些行为方面，使得系统级分析能够进行。存在若干种相关ADL的工作案例，它们包括AADL、AUTOSAR、CAR-DL、EAST-ADL以及相关的OMG语言和工作^{[1、13、17、87、89、93、94、111]}。我们在本章不进一步探讨这些工作，因为有单独的一章专门讨论ADL话题，因而我们建议有兴趣的读者参考它们。

行为建模语言共同的愿望就是提供高层次的行为抽象，并在软件/硬件实施级之上。更进一步的共同点，包括渴望捕捉到许多不同类型的行为（计算模型）和嵌入式系统的属性，转换或改进的进展，其中抽象模型可以转换成软件或描述哪些硬件可以综合。此类别中的语言通常支持行为模拟、分析和综合。一个研究的挑战是支持多个MOCS在同一框架内，同时又提供良好的分析和综合的基础。一个相关研究的挑战是支持分布式嵌入式计算机系统的行为模型的细化。在这个类别中，存在几种商用语言，包括Simulink、Modelica和SystemC^{[102、106、112]}。研究方法的案例包括Ptolemy、Forsyde、Milan、Metropolis和其他协同设计工作^{[68、69、83、104、108]}。下面我们描述Metropolis这一类的研究工作，并作为一个例证。ADL和行为建模语言的连接和/或集成构成了一个有趣的研究挑战。

当UML1和UML2缺乏许多嵌入式系统建模所需的属性时，存在几种OMG的进展，它们试图解决这些问题，补充UML2规范。有一种方式来处理这样的扩展，就是利用现有的UML扩展机制，来定义一个UML2轮廓。EAST-ADL的工作是一个例子，其中通过使用UML2的扩展机制，把UML2语言调整到特定域，并且更正式。当今OMG的征求方案——MARTE就是为解决这一问题而来，其目的在于针对实时嵌入式系统定义一个新的UML轮廓，比如添加用于指定时序要求和组件行为的属性^[101]。另一个OMG的工作就是最近的SysML标准——针对系统工程应用的可视化建模语言^[111]。SysML支持规定、分析、设计和范围广泛系统的V＆V，以及系统的系统。它被当做一个UML2的轮廓来实施，增加了一些图表和结构到UML2中（主要与要求和参数关系有关）。SysML提供了一个有趣的框架，但仍然需要证明是嵌入式系统领域的。

Metropolis是一个用于嵌入式系统研发的环境，从规范到实施具有“平台为基础的”方法和连续的细化^[69、103]。这种方法起源于电子设计自动化领域，且想法是探索经过验证的硬件综合的概念是否可以扩展到嵌入式系统。其目的是为了满足对复杂的控制和检验不断增长的需求，并提供规范和实现之间定义良好的语义链接。重点是通过正规方法的分析和综合，以及对异构模型的集成。Metropo-lis提供了计算的元模型，它是形成表达常用MoC的基础。Metropolis中的系统建模包括抽象行为规范、架构、行为映射到架构元素，以及表达对数量的限制，如时间和活力。在架构模型中，计算和通信部件的特点由服务和费用（比如能源）来表征。映射对应于行为的细化，它提供了新兴的属性。在Metropolis中探索的做法是支持优化设计与分析、验证工具相结合。

10.5.2.2 嵌入式系统的模型集成和管理

正如本章前面所述，嵌入式系统的开发中使用的不同类型的工具之间存在许多可能的关系。这些依赖关系和研发进程可以用来识别不同的集成模式^{[22、34、76]}。需要集成的一个典型的案例就是需要支持几种类型的分析。由于工具和分析技术是零散的，需要开发用于提取和映射异构类型信息的支持。通过常见的格式或元模型以及通过支持工具接口和互操作性，可以实现集成。

处理信息的方法之一是采用PDM方法，其中信息既可以集中存储，也可以存储在域工具中。无论采用何种方法，重要的是要认识到：模型有部件和结构，它们需要进行版本控制、配置和记录。在这个过程中面临的一个挑战，就是处理和整合不同来源的信息。所产生的挑战就是提供管理工具，它们支持全方位的嵌入式系统开发，允许细粒度信息管理。作为管理的基础，产品信息模型是重要的。在今天，在机械工程领域存在标准化模型，但不是针对嵌入式系统的。嵌入式系统建模语言的进展可以为建立标准提供基础。(www.daowen.com)

相关研究工作的案例在下面给出（见文献[11]）：

•GeneralStore是一个平台，它启动一个研发过程运行——从模型变成可执行代码，其中集成了异构的CASE工具（例如，Matlab/Simulink和ARTiSAN RT Studio^[90]）和相关的代码生成工具。UML模型用于整个系统的设计，其子系统模型可以在离散和连续时间域内描述。这是通过提供UML中CASE数据的元级定义来实现的，然后将在MOF的对象库中集成元模型。CASE工具之间的数据交换由XML支持。GeneralStore提供配置管理支持^[65]。

•ToolNet是一个集成平台，它管理域工具的集成——针对具体的设计阶段或嵌入式软件系统的各个方面，如DOORS^[97]和Matlab/Simulink。这种方法把域数据留在各自的工具处。数据集成是通过就域工具数据（然后它在关系库中存储和管理）关系和一致性限制而言，指定虚拟对象空间来实现的。标准化的API，用于支持工具访问和基于XML的工具数据输出。ToolNet提供了一个用于导航的图形用户界面^[25]。

·模型集成计算。在Vanderbilt大学的研究中，方法和MBD原型工具套件包括模型的集成和管理工具已经研制成功。该方法强调使用特定域的建模语言，以及采用不同工程工具用于集成的模型转换。通过个别模型的元模型的映射实施转换。为了支持工具数据交换，不同的工具连接是基于CORBA/COM技术的。当每个工具有一个接口适配器提供数据访问（例如通过一个数据文件或COM接口）和语法操作时，系统就提供了一个集中的语义翻译（或转换）服务，它用于保留正在交换的工具数据的语义^[35]。

10.5.2.3 MBD的方法论支持

支持嵌入式系统MBD的方法论是需要的。作为方法论的一部分，需要定义应该如何在研发过程中使用模型，以及不同类型的模型如何与建模语言关联。方法论应该提供准则：何时以及如何处理不同的产品现象。主要的挑战是支持成本效益、系统的设计与验证（由模型和分析技术支持）方法的发展。与汽车机械工程的集成，面临系统和机电一体化工程道路上一些挑战。今天，虽然它们的交货时间较短，但软件和电子产品在产品开发过程中往往被视为滞后。当子系统和部件进行了优化时，并不意味着整个系统进行了优化。

研究和方法论的发展是一个有趣的领域，应借鉴系统工程、并行工程及相关学科的经验^{[8、12、27、58、61、62、78、85]}。这些方法的一个共同的假设是，管理得当的流程带来满意的产品和效率。另一方面，在强调工程的管理方面时，所有这些方法都假设产品以及必要的领域知识（例如汽车工程）都描述清楚并提供了^[24]。为了管理各种问题、保证产品质量、获得利益相关者的共识、改进流程和规划好机构资源，正确捕获这些信息就显得尤为重要。例如，为了允许并行工程，产品信息和传统上与特定研发阶段相联系的专业知识做成透明的，并在每一个研发阶段可用，这点非常必要。这些方法还需要考虑适应软件和嵌入式系统的性能。同样，方法的研发也应该借鉴现有的软件工程流程^[39、52]，但是适应和考虑嵌入式系统的特点需要进一步的工作。在文献中存在若干篇和对嵌入式系统MBD方法有贡献的文献（见参考文献[4、10、19、28、42]）。一个例子是基于平台的设计，其方法来自电子产品的设计，其中概念性的想法就是提供在不同层次的抽象级的可重复使用的平台。平台约束了设计，且与此同时在每个抽象层次处，构成一种产品线。留下的一个挑战是在不同的抽象层次之间与在集成描述不同系统方面的模型中，如何支持正式的细化^[69]。