Autosar介绍

---

前言

随着汽车电子进入了高速发展的时代，据统计一辆汽车其内部的代码量已经超过了1千万行，超过上百个ECU。而随着顾客对功能需求的增加，以及整车厂对顾客需求的满足，这个数字依然成上升趋势。功能需求越多，软件复杂度就会越高。就会面临软件可重用性差、硬件平台各式各样很难统一、软件模块化极其有限等问题。各大厂商为了解决这些问题，Autosar就诞生了。

一、Autosar简介

Autosar（AUTomotive Open System ARchitecture）就是汽车开放系统架构。这是一个由整车厂，零配件供应商，以及软件、电子、半导体公司联合成立的一个组织。自从2003年以来，就致力于为汽车电子行业提供一个开放的、标准的软件架构。

1.Autosar官网

https://www.autosar.org/

2.Autosar成员

Autosar成员主要分为：9个核心合作伙伴（宝马、博世、大陆、戴姆勒、福特、通用、标致雪铁龙、丰田和大众汽车公司），63个高级合作伙伴，1个战略合作伙伴，74个发展伙伴，158个联系合作伙伴，33个与会者

3.Autosar分类

AUTOSAR目前分为两种：Classic Platform AUTOSAR 和 Adaptive Platform AUTOSAR，也称为CP和AP。
通常我们提到的AUTOSAR一般指Classic AUTOSAR，它是用在众多汽车ECU上的AUTOSAR架构，一般在带有RTOS的系统上使用，2016年及以前发布的都是Classic AUTOSAR经典平台的。
Adaptive AUTOSAR是随着近些年汽车信息娱乐系统的发展，在带有高级操作系统(Linux或QNX)的车载Soc上使用的一种AUTOSAR架构，自适应平台的AUTOSAR版本是2017年3月发布的。本文谈论的是Classic AUTOSAR，因此下面提到的AUTOSAR均指Classic AUTOSAR。

4.Autosar发展历程

根据官网介绍，大致梳理的。详情可参考官网的history页面

AUTOSAR官网将AUTOSAR的发展分成了5大阶段：
AUTOSAR成立：Initialization（2002-2003）
第一阶段：Phase 1（2003-2006）
第二阶段：Phase 2（2007-2009）
第三阶段：Phase 3(2010-2012)
2013年开始不断更新完善：AUTOSAR continuous further development (since 2013)
2017年新的AUTOSAR自适应平台成立：AUTOSAR Adaptive Platform（since 2017）

·Initialization（2002-2003）~ AUTOSAR成立

2002年8月召开AUTOSAR项目启动会，主要确定了AUTOSAR的成员，AUTOSAR的初版目标计划。当时参加的公司成员有宝马，博世，大陆集团，奔驰和大众汽车公司。不久之后，西门子VDO也加入了。西门子VDO后面被大陆集团收购。

2003年7月，目前AUTOSAR Classic Platform（经典平台）的草稿版发布，也确立了AUTOSAR的核心会员Core Partner。

从AUTOSAR成立的过程中可以看出，AUTOSAR早期主要是德国汽车主机厂、德国汽车零部件供应商之间的联盟。

· Phase 1（2003-2006）~ AUTOSAR第一阶段
2003年11月、12月Ford福特汽车、PSA标致雪铁龙，Toyota丰田先后以核心会员身份加入AUTOSAR。2005年6月GM通用汽车以核心会员身份加入AUTOSAR。2005年6月发布了AUTOSAR Classic Platform 1.0。2005年8月标准化AUTOSAR工具链。2006年先后发布了AUTOSAR Classic Platform 2.0，2.1。截止2006年，AUTOSAR第一阶段开发结束，总共有113个成员（3个Premium Partner， 48个Development Partner， 52个Associate Partner， 10个Attendees）。

从AUTOSAR第一阶段发展过程中可以看出，AUTOSAR几乎涵盖了当时世界上所有主流主机厂商和汽车零部件供应商，也不再只是德国汽车行业之间的联盟了。

· Phase 2（2007-2009）~ AUTOSAR第二阶段
AUTOSAR第二阶段先后发布了AUTOSAR Classic Platform 3.0, 3.1, 4.0。期间，因为西门子VDO被Continental 收购，因此西门子VDO不再是AUTOSAR的核心会员。2008年10月，第一届 AUTOSAR Open Conference Detroit（AUTOSAR开放论坛）召开。截止2009年止，AUTOSAR成员超过了166个。

· Phase 3（2010-2012）~ AUTOSAR第三阶段
2010年到2012年，先后举办了第二届东京AUTOSAR Open Conference，第三届法兰克福AUTOSAR Open Conference，第四节巴黎AUTOSAR Open Confluence，第五届北京AUTOSAR Open Confluence。期间，AUTOSAR发布了Classic Platform 3.2，结束了第三阶段。截止2012年，AUTOSAR成员超过了170个。

· 2013年开始不断更新完善
2013年到2016年期间，先后发布了AUTOSAR Classic Platform 4.1.0，4.2.1,4.2.2,4.3.0。2014年6月AUTOSAR发布了Acceptance Test 1.0.0，用于AUTOSAR架构的认证。从此AUTOSAR更加完善。截止到2016年，AUTOSAR成员超过了191个。

· 2017年新的AUTOSAR自适应平台成立
2017年开始，AUTOSAR开始开发AUTOSAR Adaptive Platform。此平台将主要用于域控制器，不再是单一的嵌入式软件平台。目前Adaptive platform主要用在智能驾驶，ADAS等系统中。此平台将会和目前手机、计算机十分相似。

二、Autosar软件架构

1.架构图总览

在AUTOSAR软件架构中，汽车嵌入式系统软件自上而下分别为应用软件层（Application Software Layer，ASW）、运行时环境（Runtime Environment，RTE）、基础软件层（Basic Software Layer，BSW）和微控制器（Microcontroller）。为保证上层与下层的无关性，在通常情况下，每一层只能使用下一层所提供的接口，并向上一层提供相应的接口。

2.应用软件层（APP）

应用软件层（Application Software Layer，ASW）由若干个软件组件（Software Component，SWC）组成，软件组件间通过端口（Port）进行交互（软件组件之间的交互必须经过RTE层）。每个软件组件可以包含一个或者多个运行实体（Runnable Entity，RE），运行实体可以简单的理解为软件中具体的逻辑控制、算法等函数。应用软件层也必须通过RTE调用基础软件层的服务。

3.运行时环境（RTE）

运行时环境（Runtime Environment，RTE）作为应用软件层与基础软件层交互的桥梁，为软硬件分离提供了可能。
RTE可以实现软件组件间、基础软件间以及软件组件与基础软件之间的通信。
RTE封装了基础软件层的通信和服务，为应用层软件组件提供了标准化的基础软件和通信接口，使得应用层可以通过RTE接口函数调用基础软件的服务。
此外，RTE抽象了ECU之间的通信，即RTE通过使用标准化的接口将其统一为软件组件之间的通信。由于RTE的实现与具体ECU相关，所以必须为每个ECU分别实现。

4.基础软件层（BSW）

基础软件层（Basic Software Layer，BSW）又可分为四层，即服务层（Services Layer）、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer，MCAL）和复杂驱动（Complex Drivers）

4.1服务层（Service layer）

服务层（Services Layer）提供了汽车嵌入式系统软件常用的一些服务，其可分为系统服务（System Services）、存储器服务（Memory Services）、加密服务（Crypto Services）以及通信服务（Communication Services）等。
提供包括网络通信管理、存储管理、ECU模式管理和实时操作系统（Real Time Operating System，RTOS）等服务。除了操作系统外，服务层的软件模块都是与ECU平台无关的。

服务层软件通常由第三方软件服务商提供（如Vector, EB、普华等）

4.2电子控制单元抽象层（ECU Abstraction Layer）

ECU抽象层（ECU Abstraction Layer）包括板载设备抽象（Onboard Devices Abstraction）、存储器硬件抽象（Memory Hardware Abstraction）、加密硬件抽象（Crypto Hardware Abstraction）、通信硬件抽象（Communication Hardware Abstraction）和I/O硬件抽象（Input/Output Hardware Abstraction）等。
该层将ECU结构进行了抽象，负责提供统一的访问接口，实现对通信、存储器或者I/O的访问，从而不需要考虑这些资源是由微控制器片内提供的，还是由微控制器片外设备提供的。该层与ECU平台相关，但与微控制器无关，这种无关性正是由微控制器抽象层来实现的。

ECU抽象层（ECU Abstraction Layer）和复杂驱动（Complex Drivers）通常由Tier1（零部件供应商）或者OEM（汽车主机厂）提供。

4.3微控制器抽象层（Microcontroller Abstraction Layer）

微控制器抽象层（Microcontroller Abstraction Layer，MCAL）是实现不同硬件接口统一化的特殊层。通过微控制器抽象层可将硬件封装起来，避免上层软件直接对微控制器的寄存器进行操作。就类似于硬件抽象层，屏蔽底层硬件差异做的适配层。
微控制器抽象层包括微控制器驱动（Microcontroller Drivers）、存储器驱动（Memory Drivers）、通信驱动（Communication Drivers）以及I/O驱动（I/O Drivers）。

MCAL一般由芯片厂商提供

4.4复杂设备驱动（Complex Device Drivers）

可简单理解为除主MCU外其他芯片的开发或AUTOSAR架构当中未包含的模块统称为复杂设备驱动模块。
比如电源芯片，看门狗芯片，继电器驱动芯片，蓝牙芯片等。

三、Autosar工具链

应用软件层（AppL）：
主要使用有Vector 的 DaVinci Developer 和 MATLAB Simulink

实时环境层（RTE）和基础软件层（BSW）：
DaVinci 的 Configurator Pro 和 ETAS 的 ISOLAR-AB，当然还会有一些其他厂商，比如东软睿驰的 NeuSAR、普华的软件 ORIENTAIS Studio，恒润的软件 INTEWORK-EAS（ECU AUTOSAR Software，简称EAS）等等
在基础软件层当中有微控制器抽象层（MCAL）这层在国内一般会使用 EB 的 Tresos。

使用较多的两种方式是：

Vector的 DaVinci Developer + DaVinci 的 Configurator Pro + EB 的 Tresos（主流用法）

MATLAB Simulink + ETAS 的 ISOLAR-AB + EB 的 Tresos（博世，联电和一些新能源厂商用法）

四、Autosar优缺点

1.Autosar优点

1 软件可复用性高

2 AUTOSAR分层架构使系统软硬件耦合度大大降低

3 便于软件的升级维护

4 标准化软件接口和模块，减少设计错误

5 减少了手动代码量，提高了软件质量

6 缩短开发周期，提高开发效率

1.Autosar缺点

1. AUTOSAR规范更新升级慢

因为制定AUTOSAR规范时候并不会开发测试，制定出来的规范往往会有一些bug，而修复需要等到下一个AUTOSAR版本。

2. AUTOSAR规范理解不太一致

目前各个厂商对AUTOSAR规范的理解并不是那么一致，集成各个厂商所开发的软件模块需要大量的精力和时间。各个厂商提供的工具也并不真正相互兼容。

3. AUTOSAR的软件价格高昂

完整的AUTOSAR开发环境至少是一般的开发环境价格的几倍甚至十几倍。购买第三方软件供应商的软件的价格也是十分高昂。

4. AUTOSAR软件的重用性面临挑战

在真实的项目中，基于某个AUTOSAR项目重新配置所需要的时间和精力也是巨大的，并不是理想中那么完美。

参考资料：

1，autosar官网：https://www.autosar.org/
2，《AUTOSAR规范与车用控制器软件开发》宋珂、王民