【软件定义汽车】AUTOSAR架构介绍

CSDN话题挑战赛第1期
活动详情地址：https://marketing.csdn.net/p/bb5081d88a77db8d6ef45bb7b6ef3d7f
参赛话题：自动驾驶技术学习记录
话题描述：自动驾驶是当前最火热的技术之一，吸引了无数的开发者与学习者融入其中。然而，自动驾驶技术是系统硬件平台与人工智能、物联网、大数据、云计算等新一代信息技术深度融合的产物，具有知识新、内容杂、难度深、缺少系统教程等特点，让许多开发者眼花缭乱。
本话题通过记录分享自动驾驶相关技术，为大家提供相互学习与交流的平台。话题分享与讨论的技术点包括不限于：自动驾驶算法、自动驾驶系统基础架构、智能驾驶交互技术、虚拟仿真、自动化测试、无人系统与车辆平台、自动驾驶计算平台与传感器等。

什么是AUTOSAR

官网:传送门
AUTOSAR的全称是AUTomotive Open System Architecture，直译为汽车开放系统架构。

由全球汽车制造商、零部件供应商及其他电子、半导体和软件系统公司联合建立，致力于为汽车工业开发一个开放的、标准化的软件架构。

简单来说，AUTOSAR是一种开放的软件架构，需要汽车制造商、零部件供应商、芯片供应商及软件公司共同合作来实现该软件架构。

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

一般提到的AUTOSAR一般指Classic AUTOSAR，它是用在众多汽车ECU上的AUTOSAR架构。

Adaptive AUTOSAR是随着近些年汽车信息娱乐系统的发展，在带有高级操作系统(Linux或QNX)的车载Soc上使用的一种AUTOSAR架构。

为什么是autosar

autosar的提出解决了什么问题呢？

传统的汽车ECU开发，一般是由一个经验比较丰富的软件架构师来搭建一个项目的软件架构。

做的比较好的软件架构可能会考虑软件分层，比如驱动层、服务层、应用层等，做的不好的软件架构，软件层级可能就没有那么分明，在应用层甚至直接会嵌入硬件驱动相关的代码。

这就导致软硬件耦合性问题。

而且，在AUTOSAR之前，ECU软件开发一般按照功能模块进行分工。

不同模块之间的数据交互需要负责相应模块的工程师提前定义好接口，并在各自的模块开发完成后进行联合调试，调试过程中可能会发现定义接口时没有考虑到的一些问题，此时需要重新设计接口并进行再一次的联合调试。

接口不明确导致开发人员合作困难。

由于MCU选型不一样或者不同汽车主机厂的项目需求有差异，在把一套已经开发完成的软件移植到另一个项目时，会遇到比较大的困难。基本需要重新开发，导致代码复用率较低。

1. 软硬件解耦

使用AUTOSAR之后，软硬件是被分隔开来的。
如果更换MCU，只需要变更AUTOSAR架构中的一部分即可(BSW，即基础软件)，而处于上层的应用软件是可以直接复用的。
这就让软件代码和硬件部分进行了解耦。

2. 统一的接口，提交团队合作

AUTOSAR对不同模块之间的数据交互接口进行了统一定义(RTE)，每个模块只需要按照接口标准定义去开发，当开发完成后可以直接进行联合调试。

3. 代码的可移植增强

由于软硬件之间进行了良好的隔离，以及模块之间的通信接口也是按标准开发的。

一个开发好的软件可以直接根据新项目的需求取用相应的模块，移植到另一个项目上。由于上层的应用软件不会涉及具体的硬件，即使更换MCU应用层也无需做相应的更改。

AUTOSAR架构介绍

AUTOSAR架构从底层至应用层可以分为：

• 微控制器抽象层（Microcontrollrer Abstraction Layer）
• 基础软件层（Basic SoftWare Layer）
• 运行环境RTE（Runtime Environment）
• 应用软件层（Application Software Layer）
  

微控制器抽象层

Micaro-Controller Abstraction Layer（微控制器抽象层）位于AUTOSAR软件架构中基础软件的底层。

可以直接访问MCU寄存器和内部外设的底层驱动。这样划分可以使ECU抽象层、系统服务层可以独立于MCU，保证上层软件的标准化和通用性。

AUTOSAR规范根据MCU底层驱动功能的相似性，把MCAL可以分为4个驱动组，分别是微控制器驱动组（Memory Drivers Group）、通信驱动组(Communication Drivers Group)、输入/输出驱动组（I/O Drivers Group）。

基础软件层

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

运行环境RTE

运行时环境（Runtime Environment，RTE）作为应用软件层与基础软件层交互的桥梁。

RTE主要的作用就是实现软件组件间、基础软件间以及软件组件与基础软件之间的通信。

RTE层是AUTOSAR标准化的关键。

因为RTE封装了基础软件层的通信和服务，为应用层软件组件提供了标准化的基础软件和通信接口，使得应用层可以通过RTE接口函数调用基础软件的服务。此外，RTE抽象了ECU之间的通信，即RTE通过使用标准化的接口将其统一为软件组件之间的通信。

这样解决了应用软件层和基础软件层之间的耦合性。比如，当底层硬件改动（如MCU更改），应用软件层也不再需要改动。

应用软件层

应用软件层是由一个个SoftWare component组成，这些SWC内部可以实现算法，每个SWC可以由多个运行实体（Runnbale Entity）组成，并且SWC通过Port连接起来。

AUTOSAR在中国

国内的各大汽车厂商、科研院校也越来越关注AUTOSAR带来的标准化的设计、开发、验证，从而大幅提高汽车电子的研发效率和研发质量。

浙江大学ESE实验中心从2004年开始关注AUTOSAR，并率先加入了AUTOSAR组织。

目前浙江大学ESE实验中心已经成功开发出一套符合AUTOSAR标准的集成的ECU开发工具链（简称为SmartSAR Studio），它可以用于ECU软件架构、网络系统配置、基础软件核配置、诊断、标定和仿真测试，支持从上到下、软件为中心的快速迭代开发模式。另外，ESE实验室中心已经开发出符合AUTOSAR标准的操作系统、通信等基础软件模块。

一汽、长安等整车厂技术研究院也于2009年开始利用AUTOSAR标准的工具进行ECU的设计、开发、验证。

值得注意的是，普华基础软件股份有限公司（iSOFT），作为Autosar的成员，已经在中国联合上汽、一汽、长安、奇瑞等主要OEM和部分院校成立了CASA联盟，旨在中国推广和发展Autosar架构。普华已具备一些列基于Autosar的工具链，如OrientaisStudio，BSW配置工具。

CSDN话题挑战赛第1期
活动详情地址：https://marketing.csdn.net/p/bb5081d88a77db8d6ef45bb7b6ef3d7f