一、 AUTOSAR背景介绍

　　AUTOSAR是英文AUTomotive Open Systems ARchitecture的缩写，中文意思是汽车开放系统架构，它定义了一套支持分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案，以便应用于不同的汽车平台，提高软件复用，降低开发成本。AUTOSAR是由汽车OEM和其一线供应商建立的汽车软件开发全球合作联盟，于2003年夏天正式成立，并于2004年启动了主要的工作，其目的就在于控制汽车软件的复杂性和多样性。AUTOSAR包括9个核心成员：BMW Groups（宝马）、BOSCH（博世）、Continental（大陆）、DAIMLER（戴姆勒）、Ford（福特）、GM（通用）、PSA Peugeot Citron（标志-雪铁龙）、TOYOTA（丰田）、VOLKSWAGEN AG（大众）。目前其成员已超过150个，国内OEM中已有一汽及上汽加入，恒润科技成为继一汽、上汽之后，国内第三家加入该组织的公司。

　　AUTOSAR自面世以来，从半导体工业、工具和软件厂商、零部件供应商到汽车制造商本身，整个汽车领域内的价值体系都给予该标准积极的推动。 AUTOSAR开发成员在2007年发布了2.1版本，使AUTOSAR的发展到达了一个稳定的阶段，随后通过几个不同的开发项目对AUTOSAR的实用性进行了测试，现在AUTOSAR已经做好进入到产品ECU的准备，而宝马集团已将符合AUTOSAR标准的ECU（电子控制单元）应用在全新BMW 7系量产车型中，预计在2010年AUTOSAR的所有核心成员都将推出相关的产品。在商业领域里，支持AUTOSAR标准的工具和软件供应商已推出了相应的工具和软件，提供需求管理，系统描述，软件构件算法模型验证，软件构件算法建模，软件构件代码生成，RTE生成，ECU配置以及基础软件和操作系统等服务，帮助OEM实现无缝的AUTOSAR系统软件架构开发流程。目前AUTOSAR版本为3.1版，预计将于2009年秋季发布4.0版本。

　　 由于AUTOSAR提倡“在标准上合作，在实现上竞争”的原则，其核心思想在于“统一标准、分散实现、集中配置”，所以采用AUTOSAR将为OEM带来很大的好处，这将使得他们对于软件采购和控制拥有更灵活和更大的权利，因为软件系统的标准化和开放化将使更多的软件供应商进入汽车电子行业，从而使得他们有更多的选择，同时软件的质量监督也会相应提高，有利于提高他们的产品质量。但是，也必须看到在全行业内推行此标准还是存在潜在障碍的，就是来自一些OEM厂商和大的第一级汽车供应商的抵制，因为他们已经有自己的标准和架构了，而采用AUTOSAR标准及其架构可能产生更换成本、丧失控制等风险。尽管如此，汽车电子软件开发方法和软件架构的标准化是汽车行业不可阻挡的发展趋势，而且目前还没有哪种标准比AUTOSAR标准走的更远。鉴于此，国内汽车OEM必须做好应对AUTOSAR的准备，这对他们来说，是挑战更是机遇。

　　在AUTOSAR标准的实施过程中，OEM将起主导作用。OEM应如何提出需求并在他们的产品上使用这些来自不同供应商的具有标准功能和接口的软件呢？AUTOSAR为此同时制定了方法上、流程上的标准，即AUTOSAR方法论。 本文将着重解读AUTOSAR方法论内容，讲解OEM应如何将该标准应用在他们的产品研发及生产过程中。

二、 AUTOSAR 技术概述

　　AUTOSAR的计划目标主要有3项，第一是建立独立于硬件的分层的软件架构；第二是为实施应用提供方法论，包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU中；第三是制定各种车辆应用接口规范，作为应用软件整合标准，以便软件构件在不同的汽车平台上的复用。

　　1、AUTOSAR软件架构

　　为了实现AUTOSAR的目标，即实现应用程序和基础模块之间的分离，汽车电子软件架构被抽象成几个层，如图1所示。

图1：AUTOSAR软件架构层次图。

　　为了区别软件依赖和硬件依赖，基础软件分为四个层次：服务层（Services Layer）、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer）和RTE（Runtime Environment）。除此四层外，在AUTOSAR软件架构中还有复杂驱动（Complex Driver），由于对复杂传感器和执行器进行操作的模块涉及到严格的时序问题，在AUTOSAR中这部分没有被标准化。

* 服务层提供包括诊断协议、存储管理、ECU模式管理和操作系统等在内的系统服务。除了操作系统外，服务层的软件模块都是与平台无关的。

* ECU抽象层将ECU结构（如外设与ECU的联接方式等）进行了抽象处理。该层与ECU平台相关，但与微控制器无关。

* 微控制器抽象层包括微控制器相关的驱动（如I/O驱动、ADC驱动等）。

* RTE层负责AUTOSAR软件构件（即应用层）相互间的通信以及软件构件与基础软件之间的通信。RTE层之下的基础软件对于应用层来说是不可见的，必须通过RTE进入，它将软件构件从对底层软件和硬件平台的依赖中独立出来，实现了应用程序和基础软件之间的分隔。2、 AUTOSAR方法论

　　AUTOSAR为符合该标准的汽车电子软件系统开发过程定义了一套通用的技术方法，这种方法即被称为AUTOSAR方法论（AUTOSAR Methodology）。汽车OEM作为整车系统功能的规划和设计者，需要了解并掌握AUTOSAR提供的这套开发流程，才能主导和推进符合AUTOSAR标准的系统的开发过程。

　　兼容AUTOSAR标准的汽车电子软件系统设计与开发流程如图 2所示。

图2：AUTOSAR系统设计与开发流程。

　　主要步骤可划分两个阶段：

　　第一个阶段是系统配置阶段，这属于系统级设计决策工作。首先是编写系统配置输入文件，为XML类型的文件。应用软件的描述术语在AOTUSAR中为软件构件（Software Components），该文件将确定需要使用的软件构件（即系统具有哪些功能）和硬件资源（ECU），以及整个系统的约束条件。AUTOSAR提供了一系列的模板（软件构件模板，ECU资源模板和系统模板）和标准的信息交换格式，工具供应商可据此提供相应的工具支持，从而简化系统设计的工作，最终系统设计者只需要使用工具填充或编辑相应的模板即可导出系统配置输入文件。

　　系统配置输入包含三部分内容，第一个输入是软件构件描述，定义每个需要的软件构件的接口内容，包括数据类型，端口，接口等；第二个输入是ECU资源描述，定义了每个ECU的资源需求，如处理器、外部设备、存储器、传感器和执行器等；第三个输入是系统约束描述，定义总线信号，拓扑结构和软件构件的映射关系。

　　系统配置阶段接下来的工作是将初步获得的系统配置输入文件借助系统配置生成器生成系统配置描述文件，同样为XML文件，这是系统配置阶段的最终工作成果。该文件将包含所有的系统信息，包括将软件构件映射到相关的ECU上（这种映射需要考虑到构件的需要、构件的连接、资源需求以及约束条件，有时也需要考虑成本等方面的因素），以及通信矩阵（整车的网络结构、时序以及网络数据帧的内容）。

　　第二个阶段是ECU的配置，这阶段的工作需要对系统中每个ECU分别进行。首先是使用第一个阶段的工作成果——系统配置描述文件，从中提取出与各个ECU相关的系统配置描述信息，提取的信息包括ECU通信矩阵、拓扑结构、顶级功能组合（据此产生需映射到该ECU上的所有软件构件），将放在另一个XML文件中。提取信息的工作可借助工具完成。然后进入ECU配置的实际工作中，这一步负责往输入对象中添加具体应用所必需的信息，如任务调度、必要的BSW模块、BSW配置信息、给任务分配的可运行实体等。这一步的结果被放在ECU 配置描述文件中，它包含了具体ECU所需的所有信息。最后一步是生成具体ECU的可执行程序，此步将根据ECU 配置描述文件中的配置信息构建完成ECU的基础软件的设置和与基于AUTOSAR构件的应用软件的集成，最终生成ECU的可执行代码。

　　此外，要说明的是，AUTOSAR系统的设计过程使用了虚拟功能总线（Virtual Functional Bus）的概念。虚拟功能总线（Virtual Functional Bus）将AUTOSAR软件构件相互间的通信以及软件构件与基础软件之间的通信进行了抽象，同时使用预先定义的标准接口。而对于虚拟功能总线来说，ECU内部通信和外部总线通信并没有什么区别，这种区别要等到系统布局以及ECU的具体功能最终确定才会体现出来。软件构件本身对于这种区别并不关注，因此我们可以在独立的情况下开发软件构件。在系统实现过程中，虚拟功能总线所代表的功能最终以RTE的生成来体现。

　　3、标准化的应用接口

　　通过RTE实现AUTOSAR软件构件（即应用程序）相互间的通信以及软件构件与基础软件之间的通信的前提是，软件构件必须具有标准的AUTOSAR接口。目前，AUTOSAR 3.1版已定义了一些典型的汽车电子应用领域（动力，车身/舒适和底盘）的标准接口。AUTOSAR按照功能逻辑分别将这些领域的系统划分成若干个模块，这些模块可被视为一个软件构件或多个软件构件的组合，这些功能性的软件构件的接口被明确定义，所定义的接口的内容包括名称，含义，范围，数据类型，通信类型，单位等。应用软件开发者在软件构件的设计与开发时需要应用这些接口定义。

　　这里以车身/舒适系统的雨刷管理的软件构件的接口定义为示例，如图3：

图3：软件构件的接口定义。