轻松了解AUTOSAR

AUTOSAR背景介绍

随着汽车电子进入高速发展的时代，据统计一辆汽车内部的代码量已经超过了1千万行，超过上百个各类型的电子控制单元 ECU。随着顾客对功能需求的增加，以及整车厂对顾客需求的满足，这个数字依然成上升趋势。功能需求越多，软件复杂度就会越高，面临软件可重用性差、硬件平台难以统一、软件模块化极其有限等问题就会接踵而至。在此背景下，从2003年开始，丰田、宝马、大众、福特、戴姆勒、通用、博世和 PSA 等汽车巨头成立AUTOSAR联盟，旨在为汽车 ECU 提供标准化的开放软件架构。

AUTOSAR（Automotive Open Systems Architecture），即汽车开放系统架构，是由全球各大汽车整车厂、汽车零部件供应商、汽车电子软件系统公司联合建立的一套标准协议，旨在改善汽车电子系统软件的更新与交换，同时更方便有效地管理日趋复杂的汽车电子软件系统。AUTOSAR规范的运用使得不同结构的电子控制单元的接口特征标准化，在应用于不同的汽车平台时，能大大提高软件复用、降低开发成本。

AUTOSAR的计划目标主要有三个：

（1）建立分层的体系架构

（2）为应用程序的开发提供方法论

（3）制定各种应用接口规范

AUTOSAR分类

AUTOSAR 目前分为两种: Classic Platform AUTOSAR 和 Adaptive PlatformAUTOSAR，也称为 CP 和AP。

通常我们提到的AUTOSAR一般指Classic AUTOSAR，它是用在众多汽车ECU上的AUTOSAR架构，一般在带有RTOS的系统上使用。Adaptive AUTOSAR是随着近些年汽车信息娱乐系统的发展，在带有高级操作系统(Linux或QNX)的车载Soc上使用的一种AUTOSAR架构。

AUTOSAR CP 和 AP 并不是相互竞争、相互取代的关系，而是在面对不同应用场景时的相互补充。随着汽车 E/E 架构的升级和智能网联汽车的快速发展独立的 AUTOSAR CP 或者 AP 均难以再满足控制器集中化的中央处理单元的需求，AUTOSAR CP 和 AP 一体化的解决方案则是大势所趋。

AUTOSAR开发方法论

AUTOSAR 为汽车电子软件系统开发过程定义了一套通用的技术方法，即AUTOSAR方法论。该方法描述了从系统底层配置到 ECU 可执行代码产生过程的设计步骤。

AUTOSAR设计和开发流程分为三个阶段：系统配置、ECU设计与配置阶段、代码生成阶段。

第一阶段：定义系统配置文件，这是系统设计者或架构师的任务。包括选择硬件和软件组件，定义整个系统的约束条件。AUTOSAR通过使用信息交换格式和模板描述文件来减少初始系统设计时的工作量。系统配置的输入是XML类型的文件，输出是系统配置描述文件，系统配置的主要作用是把软件组件的需求映射到ECU上。

第二阶段：根据系统配置描述文件提取单个ECU资源相关的信息，提取出来的信息生成ECU提取文件。根据这个提取文件对ECU进行配置，例如操作系统任务调度，必要的BSW模块及其配置，运行实体到任务的分配等，从而生成ECU配置描述文件。该描述文件包含了特定ECU的所有信息。

第三阶段：生成代码，是基于ECU配置描述文件指定的配置来产生代码、编译代码，并把相关代码链接起来形成可执行文件。

AUTOSAR分层模型

为实现应用程序和硬件模块之间的分离，AUTOSAR架构被抽象成四层，由上至下依次为：应用层（Application Layer）、运行时环境层（Run Time Environment，即RTE）、基础软件层（Basic Software，即BSW），以及微控制器层（Microcontroller）。

AUTOSAR软件体系结构包含了完全独立于硬件的应用层（APP）和与硬件相关的基础软件层（BSW），并在两者中间设立了一个运行时环境（RTE），从而使两者分离，形成了一个分层体系架构。RTE是专门为应用软件（AUTOSAR软件组件和/或AUTOSAR传感器/执行器组件）提供通信服务的层。在RTE之上，软件架构风格从“分层”转变为“组件风格”。AUTOSAR软件组件通过RTE与其他组件（内部和/或内部ECU）或服务进行通信。所以，这样的分层结构带来两个最大的好处，一方面，OEM可以专注于开发特定的、有竞争力的应用层软件（位于RTE之上），另一方面，它使OEM所不关心的基础软件层（位于RTE之下）得到标准化。