摘要:本文给出一些关于UML 2.0和SysML如何帮助定义不同的AUTOSAR工件，以及如何将指定的AUTOSAR部分应用于实际的一些想法。AUTOSAR定义目前正在UML 2.0之上定义。同时，OMG于2003年开始了一项提案，要求为系统工程定义一种基于UML的可视化建模语言。这个SysML也是UML 2.0的一个补充，所以比较AUTOSAR和SysML的目标和思想是一个显而易见的想法。

1.现状

目前用于汽车电子和电气开发的所有功能实现解决方案都是专有的。因此，很难在汽车原始设备制造商和供应商之间交换功能和应用。如果这种开发过程继续下去，未来功能复杂性的增长将导致需要投入越来越多的人力，同时失去对开发过程的完全控制。

现代汽车已经达到了非常高的水平。在新的法律安全和环境法规的推动下，除了客户的功能需求外，汽车功能还需要更加复杂的软件和电子部件，这些部件必须紧密耦合在网络结构中才能完全正确地执行。

2.AUTOSAR

2.1 AUTOSAR计划

2003年7月，AUTOSAR倡议-AUTOSAR(汽车开放系统架构)伙伴关系-由其核心伙伴正式发起：宝马集团、博世、大陆、戴姆勒-克莱斯勒、西门子VDO和大众。之后，福特汽车公司、通用汽车、雪铁龙标致和丰田汽车公司也成为核心合作伙伴。自成立以来，许多其他原始设备制造商和汽车供应商已加入AUTOSAR作为高级成员。核心成员和高级成员将资源分配给AUTOSAR内部的不同工作组。准成员可以提前向公众查看最后定稿的文件。

2.2 目标

AUTOSAR倡议将确定标准，作为实施未来汽车应用的基础。通过遵循这些标准，可以管理日益增长的汽车功能开发的E/E复杂性。这也将为产品维护、增强和更新带来更大的灵活性。基于AUTOSAR方法的解决方案将在产品线内和跨生产线上进行扩展。此外，原始设备制造商和供应商之间的职能交换也是可能的。汽车领域的所有领域都将涉及：动力系统、底盘、安全、多媒体/远程通信、车身/舒适性和人机界面。因此，汽车客户将获得更高质量的汽车和更可靠的电子元件。

确定了三个主要专题：

3.AUTOSAR的技术概念

图1：AUTOSAR方法

AUTOSAR将定义一个基于标准化接口的通用软件基础设施。这将包括不同API的标准化，从而导致AUTOSAR软件层的可分性。将定义功能软件组件的封装以及软件组件的数据类型。为了使这些软件组件能够工作，将确定和指定包括基本软件模块在内的软件基础设施。这些基本软件模块将具有标准化的接口。因此，分区和定义最佳资源使用是可能的，同时仍然允许本地优化来满足特定的非功能约束。

结构图在ECU-硬件之上，基本软件为AUTOSAR软件组件提供服务.在基本软件中，有四个不同的元素：

AUTOSAR的总体设计理念是应用程序和基础设施的分离。一个应用程序是由不同AUTOSAR软件组件之间的连接而形成的。图3给出了一个例子。

图3：示例应用程序，由连接的软件组件组成

如示例所示，AUTOSAR软件组件是最重要的结构元素。与UML 2.0组件类似，AUTOSAR软件组件包含与外部世界交互的独特端口。在AUTOSAR中还定义了所需提供的接口。它们连接到端口，这些端口在其接口提供数据或服务时支持端口，在需要接口时是RPort。AUTOSAR超越了UML 2.0，将接口定义为“发送方-接收方”或“客户端-服务器”。发送方-接收方接口提供或需要数据，而客户端-服务器接口定义服务。UML 2.0原型以及适当的约束是支持这一点的一种很有前途的方法。客户端-服务器连接的示例如图4所示

图4：客户端-服务器通信

AUTOSAR收发通信总是以非阻塞方式异步交换数据.新的符号可以而且应该被用来快速地传达给那些阅读图表的人。这如图5所示。注意：由于接口符号“ball”和“Socket”目前无法以图形方式替换，所以这里使用了在UML中定义的同义词接口依赖项。

图5：发件人与收件人通信

未定义AUTOSAR软件组件的大小。然而，一个软件组件是原子的，因此它不能被划分，因此不能在几个ECU上运行。在UML模型中，这可以通过在软件组件和适当的ECU之间定义1：1的关系来实现。

虽然AUTOSAR软件组件是独立于现有基础设施设计的，但必须描述其接口、功能和非功能约束。在AUTOSAR中，软件组件描述的格式和结构必须遵循所谓的软件组件模板的定义。这保证了描述包含所有必要的信息，例如软件组件需要或提供给其他组件的操作和属性。此外，在软件组件描述中还指定了基础设施需求、所需的硬件资源以及要遵循的具体实现细节。

如果实现了AUTOSAR软件组件，则此实现与该组件映射到的特定ECU(或ECU内的微控制器体系结构)无关。即使是获得必要数据或功能所需的软件组件也不必驻留在同一个ECU上。此外，有可能运行相同软件组件的多个实例。

有专门的AUTOSAR软件组件，用于传感器或执行机构。这些通常在传感器或致动器物理连接的ECU上运行，并封装传感器输出或执行器输入的物理性质。ECU及其微控制器的技术细节和往常一样是隐藏的-传感器/执行器软件组件取决于为其设计的传感器或执行器。

图6：硬件交互

4.虚拟功能总线

为了使AUTOSAR软件组件可重定位，提出了虚拟功能总线(VFB)的概念。VFB使用软件组件描述作为输入，在软件实现之前验证所有组件和接口之间的交互。因此，可以集成进行测试。

图7：连接到虚拟功能总线的原子软件组件和AUTOSAR服务

在VFB中，AUTOSAR软件组件之间的所有必要连接性都是抽象的，与它们在车辆中的未来位置无关。因此，如果两个组件必须通信，即使不知道运行这些软件组件的特定硬件，也可以指定这些组件。此外，AUTOSAR软件组件的通信需求在VFB中以抽象的方式满足(使用其底层，如OS或硬件驱动程序)。VFB内部定义良好的通信模式提供抽象的通信服务.不同ECU内部的实现是由AUTOSAR运行时环境(RTE)在现有硬件上映射后完成的。在RTE中，通信功能在BASIC软件及其通信设备中实现。图6是一个图形化的UML组合结构图，显示了可以通过VFB连接的元素。只有复杂的设备驱动程序和ECU抽象是特定于所使用的硬件的。

5.技术工件

为了使用AUTOSAR来构建系统，必须创建几个工件。首先，每个AUTOSAR软件组件将由其软件组件描述.这是基于XML的，包括软件组件之间的端口、接口和连接的详细定义。ECU描述，也是XML格式，将描述可用的资源。此外，系统约束描述将提供关于已经存在的网络体系结构所提供的约束的附加信息。这种软件到硬件的映射应该在工具支持下进行。

6.UML 2.0及其扩展机制

当交叉引用UML和AUTOSAR时，很明显UML 2.0和AUTOSAR使用了类似的概念，例如组件、端口和接口，这些概念都是在UML类模型中为组合结构图定义的。因此，UML 2.0语法可以直接用于AUTOSAR中的系统描述。然而，AUTOSAR中的一些概念需要对UML进行调整，以适应AUTOSAR语法。一个用于AUTOSAR的UML概要文件是必要的，它将所有AUTOSAR的特定信息和容器添加到UML 2.0中。

由于AUTOSAR的Meta模型是基于UML 2.0的，因此要使UML工具像Artisan Studio AUTOSAR兼容，第一步就是在AUTOSAR概要文件中为AUTOSAR定义专门用于AUTOSAR的添加。然后，开发人员可以通过使用特定于领域的术语和图形元素，使用像ArtianStudio这样的工具来描述AUTOSAR兼容的软件。为了进一步支持特定领域的建模，必须能够为建模指定规则。这使用户能够从一开始就避免建模错误，或者通过将AUTOSAR特定的元素或结构自动添加到手动编辑的模型元素来帮助用户。Artisan Studio 6.0通过向这些UML原型扩展添加脚本的可能性来包含此功能，这些扩展还可以用于将建模活动限制在AUTOSAR中允许的连接和属性上。

7.SysML

AUTOSAR结构定义基于UML 2.0. 与此同时，OMG在2003年3月开始了一项提案请求，为系统工程定义了一种基于UML的建模语言。目前有两个团队，SysML合作伙伴和SysML提交小组正在并行工作，以满足到2006年第一季度完成SysML规范的时间表。

SysML是针对OMG、INCOSE和AP 233开发的需求为系统工程定义的图形化建模语言。它重新使用UML 2.0的一个子集并向其添加扩展，从而支持广泛复杂系统的规范、分析、设计、验证和验证。系统可以包括硬件、软件、数据、人员、程序和设施。

SysML补充了UML 2.0，因此使用SysML的系统工程师和使用UML 2.0的软件工程师都可以使用具有不同特性的相同图形语言进行无缝协作。

图8：将SysML和SysML模型嵌入到UML 2.0中

由于SysML的工作尚未完成，这里提出的概念和想法包含了2005年11月正在进行的工作的状态。它们可能会更改，直到最终的SysML规范发布。

8.SysML配置文件结构

为了扩展UML 2.0，SysML定义了SysML概要文件。这分为几个子包。

图9：SysML配置文件结构

SysML概要文件中定义的子概要文件、原型和标记定义扩展了UML 2.0的现有元模型元素。

9.SysML图形符号

SysML没有使用UML 2.0中定义的所有十三种图表类型。相反，它使用自己的图表分类法，其中引入了两种新的图表类型：

某些结构图类型在 比UML 2.0更简单的方法来反映 更好的系统工程概念。也有一些 图表类型名称已更改。

图10：SysML图分类法

为了更好地理解SysML的重点，让我们看看新的图表类型。它们解释了UML 2.0中系统工程方面的差距。现有的建模语言已经包含了非常重要的结构建模功能，如结构序列和复合结构。但是，对于系统工程师来说，尤其是使用和建模需求的能力是必不可少的。

图11：需求图

完全描述需求的元素。这包括诸如名称、ID、需求描述等需求属性。另外，需求依赖关系，比如一个需求是从其他需求派生出来的，或者一个需求包含其他需求，都可以以图形的方式显示出来。重要的建模功能是，需求可以与系统设计或测试用例中的系统元素等其他建模构件相关联。这是使用类型化的依赖关系来完成的，比如测试用例的<<验证>>，或者设计元素的<满足>。在一个模型中拥有所有三个透视图、需求、设计元素和测试的事实将使用户能够跟踪这三个世界之间任何缺失的链接。如果有至少一个设计项目不能满足的要求，或者没有链接到可以验证它的定义测试，则可以自动分析。

SysML中的下一个新概念是块的表示法。类似于UML 2.0组件，块不限于软件组件。它们表示一个模块，该模块可以位于系统层次结构中的任何级别，包括外部系统、逻辑子系统或物理子系统，如果由软件和/或硬件组成，则它们是独立的。块可用于黑匣子或白盒造型.

模块定义图是UML 2.0中的简化类图，它们使用组合关联，现在是在块之间。

图12：模块定义图

内部模块图是构造型复合结构图。已在模块定义图中建模的组合被重用。但是，内部连接是在此图表形式中添加的。

当前SysML定义中的下一个新图是约束图。在SysML概要文件的0.9版本中，它被称为参数图。UML 2.0增加的原因是必须在系统建模中包括时间连续建模和物理方程。UML 2.0只使用基于事件的建模，这对于软件透视图来说已经足够了.为了建立一个系统也使用系统工程的角度，它还需要能够使用例如物理方程。

图13：约束块示例

帧本身表示一个约束块，框架上的引脚显示参数。在约束块中，有可能包含其他约束块。约束可以链接到块。因此也支持流，即流属性、流项和流端口。流的SysML定义扩展了UML 2.0信息流。

SysML中的活动图被增强以包括连续的项流，因此元素的行为得到了更好和完整的描述。

图14：活动图示例

10.结论

AUTOSAR计划展示了如何为汽车建模定义特定领域的建模，以标准化概念、接口和服务。这将基于UML 2.0指定，使用用于AUTOSAR的UML概要文件。软件组件、系统约束和系统定义的所有必要构造都将包括在内。然而，考虑到复杂系统建模的一般系统工程需求，这些需求也可以用于汽车建模。SysML通过简化和扩展UML 2.0的概念来更好地适应系统的建模，从而缩小了系统和软件工程之间的差距。