在 IBM Rational Systems Developer 中进行 AUTOSAR 系统建模

文档选项 未显示需要 JavaScript 的文档选项 英文原文

级别： 中级

Manoj Paul, 系统软件工程师, IBM

2008 年 11 月 17 日

IBM® Rational® Systems Developer 与 AUTOSAR 的集成能够使您对汽车系统进行建模。它能够同时支持基于 UML 的建模和面向遵从 AUTOSAR 汽车软件的领域专用建模技术。该工具还支持从 UML 到领域专用语言（domain-specific language，DSL）的双向模型到模型的转换，让您具备能够选择在两者任意一个环境中建模的灵活性。

引言

本文简要介绍了汽车系统开发的 AUTomotive Open Systems ARchitecture（AUTOSAR）标准。本文讨论了通过一组 IBM® Rational® Systems Developer 中的插件提供的汽车系统的模型驱动开发（Model Driven Development，MDD），和领域专用的建模支持。本文介绍了以下特性：

• 基于 UML 的 AUTOSAR 系统开发
• AUTOSAR 的领域专用的建模支持
• 利用 MMI（Meta-Model Integration）框架的 AUTOSAR 领域元素的可视化
• AUTOSAR UML 和 DSL 模型的双向转换

回页首

汽车开放系统架构

革新的车辆应用程序的出现，以及对当今车辆的高级特性的不断增长的需求导致了车载系统的复杂软件和电子系统的开发。在开发它们的过程中缺乏标准引发了许多问题。专用软件应用程序成为了针对硬件的，这限制了它们在其他硬件平台上的使用，使得软件应用程序的管理变得复杂。开发成本也增加了。

AUTOSAR 是开放且标准化的汽车软件架构，是由汽车生产商、供应商，和工具开发人员联合开发的。这个联盟的目的是创建车辆内部的软件基础架构和体系结构的实际标准，允许：

• 不同硬件平台上的软件组件的移植
• 基本软件组件的复用
• 在车辆生命周期中更容易地软件更新和升级
• 面向 OEM 和供应商的新的商业和协作模型

该标准将作为未来车辆应用程序实现所基于的平台，并且将最小化复用和维护它们的目前的屏障。因此，它将能够将车辆功能和功能网络映射到不同的硬件环境中。

回页首

AUTOSAR 系统建模

AUTOSAR 已经指定了其自己的 DSL，允许汽车工程师以熟悉的方式对车辆的电力和电子系统进行建模。该语言有四个主要部分，它们称为模板。它们是：

• 并入虚拟功能总线（Virtual Functional Bus，VFB）概念和行为的软件组件（Software Component，SW-C）
• 硬件描述的电子控制单元（Electronic control unit，ECU）
• 用于 ECU 拓扑，和将逻辑组件映射为物理组件的系统
  • 取决于 SW-C 和 ECU 模板
• 用于描述基本软件配置的 ECU 配置

此外，已经指定了一个描述使用磨边描述、构建，和配置 ECU 的过程的方法。

本部分探究了用于 AUTOSAR 系统建模的统一建模语言（Unified Modeling Language，UML）的可用性，以及将要面临的可能挑战。

AUTOSAR 系统的基于 UML 的建模

Rational Systems Developer 中的 AUTOSAR 建模支持探究了从 AUTOSAR 元模型 2.1 到 UML 2.1 的可能映射。对于一些模板，在这两个领域之间存在很好的重叠。利用 UML 和概要文件的 AUTOSAR 系统开发已经在 Rational Systems Developer 中实现了。它有许多优点，因为您可以容易地使用 IBM® Rational® Software Modeler 提供的图和分析支持。

图 1 显示了利用带有 AUTOSAR 概要文件的 UML 结构图的 VFB 视图。

Rational Systems Developer 的 AUTOSAR 建模支持允许您创建用于创建模型元素的定制的菜单（如图 2 中所示的那些），这意味着您可以直接创建 AUTOSAR 原型化的 UML 元素。您可以使用 UML 类或结构图来对 AUTOSAR 软件组件建模，并且对 ECU 建模（在某种程度上）。您可以很好地利用 UML 结构图获得软件组件的 VFB 结构。

UML 的局限性

虽然您可以利用 UML 来捕获 AUTOSAR 建模的一些方面（像软件组件模板），但是其他 AUTOSAR 模板（像 ECU 或 System 模板）不能完全地用 UML 建模，如图 3 所示。这生成了 AUTOSAR 领域专用建模的需求。下一个部分将讨论为 AUTOSAR 领域专用问题的建模而设计的 DSL 工具。

回页首

AUTOSAR 领域专用语言工具

如前面部分中讨论的，只有 UML 不足以捕获 AUTOSAR 建模的每个方面。这引发了在建模工具中增加领域专用建模（domain-specific modeling，DSM）支持的需求。DSL 是要执行 DSM 的领域的底层模型，并且一般以元模型形式获取。AUTOSAR 元模型可以利用 Eclipse 建模框架（Eclipse Modeling Framework，EMF）实现。根据 Rational Systems Developer 设计的 DSL 利用 ecore 模型提供领域专用的建模支持，直接从主 AUTOSAR 元模型生成。

EMF 持久层

作为 AUTOSAR 标准的一部分，模型文件格式是基于一组联系到元模型的持久规则而定义的。EMF 原本不支持这种 AUTOSAR 专用的格式或 schema，因此，需要定制的 EMF ResourceManager。致力于 eclipse 的许多组织正在构建相同的持久功能，因此有人正在试图将这个部分标准化。这种工作的一个实例是开放工具框架（Open Tool Framework，OTF）。图 4 显示了用于创建 AUTOSAR DSL 模型的 Rational Systems Developer 的项目浏览器的集成。

对于创建 AUTOSAR 领域元素的菜单支持（如图 5 所示）让您有领域专用的建模体验，这帮助您避免 UML 原型的混乱和其中涉及的复杂性。您可以在此进行任何 AUTOSAR 模板的详细设计，要不然，只利用基于 UML 的建模支持是不可能的。

定制化的视图

您可以利用 Rational Systems Developer 中对 AUTOSAR 的领域专用建模的支持来创建详细且复杂的模型。有时候，通过大型模型导航并找到一个对象和另一个之间的关系是一个难题。

对于 AUTOSAR 的一个这样的问题是包含其他软件组件的软件组件。在 AUTOSAR 中定义包含许多软件组件的复合的软件是可能的。复合的软件对象可以用作组件软件对象，这些可以进一步组合形成其他复合的类型。仅仅通过模型导航很难追踪这类层次关系。因此，图 6 中显示的 Hierarchical View 用于获取软件组件的层次结构。它允许您通过软件组件的层次导航，因而让您更好地观察软件到 ECU 映射。

它还用于查看按照类型分组的模型对象。如果您知道对象的分类或类型，它可以帮助确定并定位模型对象。Category View（如图 7 所示）实现此目的。这些定制的视图已经扩展为支持 AUTOSAR UML 模型。您可以根据原型来对元素分类，并且还可以显示软件组件的包含结构。

AUTOSAR DSL 对象可视化

不像 UML 标准那样，AUTOSAR 不提供对建模的任何图支持。Rational Systems Developer 中对 AUTOSAR 系统的领域专用建模的支持克服了这个缺陷，利用 IBM Rational 的 MMI 框架的可视化概念，使用一些其他领域的标记元素帮助可视化一个领域的元素。AUTOSAR 的源领域需要映射到 UML 的目标领域，这依赖于您需要如何可视化领域专用的对象。

部分利用 UML 类图来将一些 AUTOSAR 元素（软件组件、客户端/服务器和发送者/接收者接口，等等）可视化为类。图 8 显示被可视化为类图中的类的元素。对于一些 AUTOSAR 元素，尽管它们可以被可视化为类，但是方法部分或属性部分（或两者）都没有传达任何内容。UML 标记元素可以定制为使之适应领域专用的需求。

VFB for AUTOSAR Software Component（ASC）—— 在抽象层次上定义 ASC 之间通过端口的交互 —— 可以用 UML 2.1 结构图用图解法获取。图 9 显示了对于一个 ASC（RainSensing）的结构图。软件组件之间通过端口的交互已经被获取为汇集和委托连接器。

ASC 的行为建模需要安排 RunnableEntities（它是可以直接转换为代码的系统的组件）。RunnableEntities 的执行安排不可能用现有的 UML 图适当地获得。利用图形建模框架（Graphical Modeling Framework，GMF）的领域专用的图用于提供对 ASC 行为建模的基于图的支持。该图（如图 10 所示）帮助指定 RunnableEntity 读取或写入的数据元素。Properties 视图支持帮助安排 RunnableEntity 的执行事件。

回页首

DSL 模型到 UML 模型的双向转换

如之前讨论的，您可以利用 UML 对一些 AUTOSAR 模板建模，但在 DSL 工具中需要更多详细的设计。有了 Rational Systems Developer 中的 UML 建模支持，您（作为系统工程师）可以开始利用 UML 进行高层设计。然而，当提到详细的设计时，您需要将模型转换为 DSL 模型。

Rational Systems Developer 上的 DSL 工具提供模型到模型的转换支持，能够让您将 UML 模型（带有 Profile）转换为 DSL 模型。该转换支持一组来自 AUTOSAR 的元素的子集。同样也支持从 DSL 到 UML 的逆转换（带有引信功能），以便在任何阶段您都可以将 DSL 模型转换为 UML 模型。图 11 显示了转换配置，其中 UML 模型设置为源，AUTOSAR 模型设置为目标。该方法应该带来以下优点：

• 提供在选择的领域中建模的灵活性
• 利用两种领域的好处

回页首

您学到了什么

本文为您概括了 AUTOSAR 系统建模和 Rational Systems Developer 对它的支持。文中讨论了 UML 的局限性，以及用于对不同的 AUTOSAR 模板详细建模的 DSL 的相关需求。另外，文中讨论了在 UML 图和领域专用图中的领域专用对象的可视化的支持。本文还讨论了模型到模型的转换支持，向您提供了使用 UML 或使用 DSL 的选择。

参考资料

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
  
  
• 查看位于 www.autosar.org 的 AUTOSAR 技术概述 V2.1。
  
  
• 阅读文章 “探索模型驱动开发 (MDD) 和相关方法，第 4 部分：将领域特定建模应用于模型驱动的体系结构”，由 Peter Kovari 所作。
  
  
• 访问 UML 资源中心，获得关于统一建模语言（Unified Modeling Language，UML）的入门知识、技术资源和最佳实践。
  
  
• 访问 developerWorks 上的 Rational 软件专区，了解有关 Rational 软件交付平台产品的技术资源和最佳实践。
  
  
• 订阅 IBM developerWorks 时事通讯，获得有关最佳的 developerWorks 教程、文章、下载、社区活动、网络广播和事件的每周更新。
  
  
• 订阅 developerWorks Rational 专区时事通讯。 时刻关注 developerWorks Rational 内容。 每隔一周，你将会收到 Rational 软件交付平台的技术资源和最佳实践的最新更新。
  
  
• 浏览 技术书店，获得有关这些和其它技术主题的书籍。
  
  

• 访问 Rational Systems Developer 产品专题，获取最新的 RSD 产品文档和信息。
  
  
• 下载 IBM Rational Systems Developer 的试用版本。
  
  
• 下载 IBM Rational 软件的试用版。
  
  
• 下载这些 IBM 产品评估版，并着手使用来自于 DB2®，Lotus®，Tivoli®，以及 WebSphere® 的应用程序开发工具和中间件产品。
  
  

• 加入 developerWorks 社区 的讨论区，博客，播客，wiki，以及更多。
  
  
• Rational Software Architect，Systems Developer，Data Architect，Software Modeler，Application Developer 和 Web Developer 讨论区： 询问有关 Rational Systems Developer 的问题。

关于作者

		Manoj Paul 是 IBM Rational Software Bangalore Lab 的系统软件工程师。他为 Rational Systems Developer 团队工作。他目前参与 Rational Systems Developer 中的 AUTOSAR Modeling 工具的开发。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首