面向OEM的AUTOSAR汽车开放系统架构解决方案

　　一、 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：软件构件的接口定义。 

　　说明： 

　　雨刷管理构件（WiperWasherManager）有两个接口，CmdWashing 和StaWasher,图中WWManager表示为雨刷管理软件构件的实例。针对CmdWashing接口定义了以下信息： 

　　1) CmdWashing接口由WiperWasherManager构件提供，其数据内容为FrontWasher构件的Activation接口所使用。 

　　2）CmdWashing包含一个“Command”的数据元素。 

　　3）“Command”的数据类型为“t_onoff”。 

　　4）“t_onoff”属于“RecordType”，该类型描述一般的开/关信息。 

　　应用软件开发者应该意识到，面向AUTOSAR运行时环境（RTE）接口的应用软件设计的重要性，及早地将AUTOSAR应用层接口引入到实际的项目中来，为实现应用软件的可复用性做好准备，从而优化整个软件开发流程。 

　　三、 设计应用与实施 

　　仍以车身/舒适领域的外部车灯控制系统的设计为例，在本例中只涉及转向灯的闪烁控制功能的实现。 

　　在系统配置阶段，第一步是收集系统配置输入内容。首先收集实现该功能所需的软件构件，如图4右部边框所示，在本系统中共使用了5个软件构件，按照AUTOSAR提供的软件构件模板编写每个软件构件的描述文件；然后明确系统中所用到的ECU资源，形成ECU资源描述文件，如图4左上部边框所示，这里有3类ECU；最后是系统约束条件的描述文件，描述系统的网络拓扑关系。一般OEM需要提供软件构件描述和系统约束描述文件，以供零部件供应商在ECU系统开发时使用。 

                                               图4：系统配置输入内容。 

　　以上描述文件的生成均有专门的工具（这类工具统称为AUTOSAR描述文件编辑器）支持，用户只需向工具中填充规定的内容即可。 

　　软件构件描述文件的生成，需要获取每个软件构件的关于接口，行为，直接的硬件接口（I/O），运行性能需求（内存，功耗，定时等）等方面的信息；而软件构件描述文件本身将包含4部分内容： 

　　* 一般特性：名称，生产商等 

　　* 通信属性：端口，接口 

　　* 内部结构：子构件，连接关系 

　　* 需要的硬件资源：处理时间，调度，内存大小和类型等。 

　　ECU资源描述文件生成之前，需要获取每个ECU的关于传感器和执行器，硬件接口，硬件属性（内存，处理器，功耗），连接和带宽等方面的信息；而ECU描述文件本身将包含7部分内容： 

　　* 一般特性：名称，生产商等 

　　* 温度（自身，环境，冷却/加热） 

　　* 可用的信号处理方法 

　　* 可用的编程能力 

　　* 可用的硬件：微控制器，架构（如多处理器）；内存，接口（CAN，LIN，MOST，FlexRay），外设（传感器/执行器），连接（如引脚数目）。 

　　* RTE之下针对微控制器的基础软件模块 

　　* 从引脚到ECU抽象层的信号 

　　系统约束描述文件生成之前，需要关于整个系统的信息，如总线系统，协议，通信矩阵和属性，功能集群，功能部署（向ECU的分布）；而系统约束描述文件本身将包含3部分内容： 

　　* 网络拓扑：总线（CAN，LIN，FlexRay），连接的ECU，网关，电源供应 

　　* 通信（针对每个通道）：通信矩阵，网关表 

　　* 软件构件的映射 

　　以上所描述的系统配置输入内容收集完整后，使用系统配置工具导出系统配置文件，这一步决定哪个软件构件运行在哪块ECU上，它生成ECU配置描述；此外还生成该系统内的通信矩阵。如图5所示。 

                                                      图5：系统配置结果。 

　　以上工作完成后，接下来进入ECU配置阶段。将每个ECU的配置信息从系统配置文件中提取出来，其内容包括ECU通信矩阵、拓扑结构、顶级功能组合（即需映射到该ECU上的所有软件构件的组合）。此外，还需要更具体的关于AUTOSAR的基础软件各主要部分的配置，如RTE的配置，OS 的配置，MCAL（微控制器抽象层）的配置和通信协议栈配置等。这些软件部件的配置目前均有相应的工具支持，直接生成可编译的头文件以供ECU系统软件的集成使用。在生成ECU可执行程序之前，需获得相关软件构件和基础软件的代码，然后与上述基础软件的配置头文件进行连编，最后生成ECU的可执行程序。如图6所示。 

                                              图6：ECU的配置与可执行程序的生成。 

　　综上所述，整个系统设计和开发流程可用图7表示，这里要注意的是，该过程可能需要多次迭代修改，以达到最优。 

                                                       图7：系统设计和开发流程。 

　　四、总结 

　　AUTOSAR正在成为现实，建立这样一个标准化平台并贯彻标准化，将会缩短新产品的研发时间和测试时间，从而帮助企业实现快速的市场反应。许多OEM都计划在接下来的车型中采用AUTOSAR。在市场上不少工具和软件供应商都已推出了符合AUTOSAR标准的工具或软件支撑，可为 AUTOSAR系统的设计和开发提供完整的无缝的解决方案。 

　　AUTOSAR是汽车电子软件平台标准化的历程中的一个巨大飞跃，我们需要学习和理解它。但是也必须看到，在整个汽车行内打破传统的软件开发平台需要相当长的一个过程。我们可以根据用户的需求和目标，在初期搭建AUTOSAR与传统软件的混合平台，这是是一个能够实现向AUTOSAR平滑升级的可行的方法。在这个过程里，重点不是单纯地使用，理解AUTOSAR的理念和思想才最重要，因为它对汽车电子软件开发的工作流程和商业模式都将带来意义深远的变革。 

　　参考文献 

　　1、 AUTOSAR SPECIFICATIONS Release3.1：AUTOSAR官网发布的规范文件 

　　2、 《03_AUTOSAR_Tutorial.pdf》：AUTOSAR官网文件