卡车与轿车软件架构对比：整车软件架构分析

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架构。本文谈论的是Classic AUTOSAR，因此下面提到的AUTOSAR均指Classic AUTOSAR。

为什么使用AUTOSAR

那么问题来了，为什么要使用AUTOSAR这种软件架构，或者说使用AUTOSAR能带来哪些好处？

在说明AUTOSAR的优势之前，我们先来看一下使用AUTOSAR之前的软件开发现状。

软硬件耦合

传统的汽车ECU开发，一般是由一个经验比较丰富的软件架构师来搭建一个项目的软件架构。做的比较好的软件架构可能会考虑软件分层，比如驱动层、服务层、应用层等，做的不好的软件架构，软件层级可能就没有那么分明，在应用层甚至直接会嵌入硬件驱动相关的代码。

多人同时开发效率低下

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

软件复用性低

由于传统的ECU 软件在开发时没有清晰的层级划分，软硬件之间以及不同的功能模块之间耦合性较大，由于MCU选型不一样或者不同汽车主机厂的项目需求有差异，在把一套已经开发完成的软件移植到另一个项目时，会遇到比较大的困难。

在使用AUTOSAR之后会有哪些改变呢？

软硬件隔离

下图的左侧是在使用AUTOSAR之前的状态，可以看到软硬件之间的耦合性是很大的。右侧是使用AUTOSAR之后的状态，软硬件是被分隔开来的。如果更换MCU，只需要变更AUTOSAR架构中的一部分即可(BSW，即基础软件)，而处于上层的应用软件是可以直接复用的。

提高团队开发效率

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

软件复用性程度提高

由于软硬件之间进行了良好的隔离，以及模块之间的通信接口也是按标准开发的。一个开发好的软件可以直接根据新项目的需求取用相应的模块，移植到另一个项目上。由于上层的应用软件不会涉及具体的硬件，即使更换MCU应用层也无需做相应的更改。

介绍完了AUTOSAR的好处，一起来看一下AUTOSAR的具体架构。

AUTOSAR的具体架构

下图展示了AUTOSAR比较High Level的三个大的层级：应用软件层、RTE和基础软件层。应用软件层包含了汽车主机厂要求的和功能相关的软件，RTE是应用层不同模块之间以及应用层和基础软件层之间进行交互的桥梁，基础软件层则包含MCU及其外围设备驱动、硬件抽象层以及为上层应用提供接口服务的服务层。

而基础软件层(BSW)可以再进一步划分，如下图的微处理器抽象层(MCAL)、ECU抽象层、服务层以及复杂驱动。

MCAL其实就是MCU的驱动软件，对每个外设模块的操作进行了寄存器操作的封装，比如SPI的初始化只需要调用一个初始化函数即可，不用关心函数内部是怎么实现的。

ECU抽象层相比MCAL多了一些板上硬件资源的驱动，比如外部看门狗、片外EEPROM或FLASH等，如果要使用这些硬件资源直接调用ECU抽象层的接口即可。

服务层是进一步的封装和抽象，一般包括OS、电源状态管理、整车网络通信、诊断服务、存储服务等。

复杂驱动主要包含一些不在AUTOSAR标准规范里的一些硬件设备的驱动，比如电机驱动、一些比较复杂的传感器驱动等。

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删