AUTOSAR基础简介

1.AUTOSAR是什么

AUTOSAR全称为AUTOSAR Open System Architecture（汽车开放系统架构）。用大白话来说大家一起给汽车控制器软件定义一个通用架构，使用这套软件架构来实现什么功能就看各厂商各显神通了。

AUTOSAR是由汽车主机厂、零部件供应商、半导体厂商、软件服务商、工具提供商、以及其他相关的厂商联合成立的一个组织。截止到现在有超过280家厂商参与到autosar组织中来。其中，OEM有宝马、奔驰、本田、现代等；零部件供应商有博世、大陆、李尔等；芯片厂商有瑞萨、NXP、Intel等。

                                      AUTOSAR联盟成员

2. 为什么要使用AUTOSAR

（1）如果使用WORD或者EXCEL等文档去传递需求，使用文档传递需求具有规范与格式难以统一的缺点，所以很难准确传递信息。AUTOSAR使用ARXML作为数据的载体，具有格式规范，存储数据容量大并且准确的特点。

（2）在没有AUTOSAR之前，每一个新的ECU项目都需要重新编写通信协议栈，存储协议栈等，需要大量的时间与人力，应用AUTOSAR之后，使用AUTOSAR基础软件配置工具可以快速配置并且生成基础软件的代码。

（3）使用AUTOSAR后，如果某个ECU需要更换MCU芯片，那么只需要使用芯片厂商提供的MCAL生成工具生成MCAL代码，将这部分替换之前的MCAL代码即可。为什么这么方便呢？因为AUTOSAR将MCAL与其他模块的接口规定好了，各芯片厂商都会根据这些接口编写MCAL代码，所以切换MCAL变得非常简单了，具体的规则，笔者将在后面为大家详细说明。

（4）按照之前没有AUTOSAR时的软件开发方式，架构师可能通过Ecxel文档管理各模块的之间的接口，但是直到编译代码的时候才能发现各模块的接口是否是连接上的，这种方式一方面不直观，另一方面对整个开发进度是不利的。如果使用了AUTOSAR工具，架构师就能够对软件接口进行自动化集成，为后面的软件开发顺利进行奠定基础。

3.AUTSAR的缺点

AUTSAOR虽然具有很多优点，但是到目前为止，仍具有一些缺点。

（1）AUTOSAR软件的价格十分高昂：如果需要开发完整的AUTOSAR环境的话，需要购买第三方软件，目前主流的AUTOSAR软件有DAVINCI,ISOLAR等，这些软件动辄百万级RMB，导致AUTOSAR的门槛非常高。

AUTOSAR文档数量变化

（2）AUTOSAR文档规范非常多而且复杂：获得AUTOSAR标准文档的方式非常方便，在AUTOSAR官网上下载即可。但是这些AUTOSAR的正式文档是作为规范而不是作为指南编写的。更糟糕的是，如果你时间有限，并且希望通过阅读AUTOSAR文档学习AUTOSAR，那么你将陷入痛苦的深渊，AUTOSAR文档不仅数量多而且难以理解，AUTOSAR文档的具体格式笔者将在后面的文章中做具体介绍。

4.Autosar分层架构

AUTOSAR规范主要由分层架构、方法论、以及应用接口三部分组成。

分层架构是AUTOSAR中最厉害的思想，也是实现软硬件分离的关键。

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

微控制器抽象层（Microcontrollrer Abstraction Layer）

基础软件层（Basic SoftWare Layer）

运行环境RTE（Runtime Environment）

应用软件层（Application Software Layer）

根据AUTOSAR分层理论，每一层只能使用下一层的软件接口，并向上一层提供相应的接口，这样可以保证AUTOSAR的严格分层。

基础软件层属于为硬件服务的层级，应用软件层属于纯逻辑应用层，软硬件的隔离，对于应用工程师来说，摆脱了以往ECU软件开发与验证时对硬件系统的依赖；对于OEM及供应商来说，提升了系统的整合能力，比如，OEM自己开发应用软件层，供应商开发基础软件层，有了AUTOSAR，这种开发模式变得非常简单了。

4.1 应用层（Application Layer）

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

如何理解SWC与Runnbale Entity的关系呢？如果大家写过C语言，那么SWC可以理解为一个.C模块，而Runnbale Entity就可以认为是.C模块中的函数。Port能够理解成模块之间函数调用或者模块之间为了进行数据传递通过封装函数对全局变量进行读写。

如下图中车灯控制系统组件示意图，整个控制系统由多个SWC组成，每个SWC负责处理相应的功能，SWC通过Port传递需要的数据。

                                车灯控制系统的功能软件组件示意图

4.2 运行环境RTE

RTE是基础软件层与应用层之间交互的基础通道。应用层的软件组件SWC间、应用层软件与BSW基础软件间、以及基础软件间的通信需要通过RTE实现。

所以RTE具有如下几个主要功能：

（1）抽象应用层SWC之间的通信：无论是模块之间的数据传递以及函数调用，都将封装成标准化的接口。

（2）封装基础软件层提供的通信与服务：ECU之间的通信（CAN,LIN,以太网）在通过基础软件层BSW的处理后，RTE通过使用标准化的接口将其统一为软件组件的通信。同时，基础软件提供的服务（诊断、存储等），也被RTE定义成标准的服务接口，提供给应用层使用。

（3）抽象基础软件层之间的通信：基础软件中复杂驱动模块与IOHWAB模块通常被认为是软件组件，他们之间的通信也需要通过RTE定义的标准接口进行通信。

所以可以认为RTE是AUTOSAR中的虚拟总线(Virtual Functional Bus )，VFB是AUTOSAR提供的所有通信机制的总和。

4.3 AUTOSAR基础软件层

基础软件层（BSW）从软硬件分层可以抽象划分为四个层级：微控制器抽象层（MCAL），ECU抽象层（ECU Abstraction Layer）、服务层（Service Layer）和复杂驱动。

按照软硬件分层：

（1）微控制器抽象层

MCAL是Micaro-Controller Abstraction Layer（微控制器抽象层）的缩写。MCAL位于AUTOSAR软件架构中基础软件的底层。可以直接访问MCU寄存器和内部外设的底层驱动。这样划分可以使ECU抽象层、系统服务层可以独立于MCU，保证上层软件的标准化和通用性。

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

                         MCAL 4个驱动组与微控制器内核与外设的关系

（2）ECU抽象层

ECU抽象层的目的在于使上层软件与ECU硬件电路设计剥离开。其中包括：板载设设备硬件抽象（外挂看门狗）、存储器硬件抽象（如EEPROM）、通信硬件抽象(如CAN收发器)、I/O硬件抽象（I/O电路处理）。而且ECU层将会给应用层和系统服务层提供统一标准化的接口，应用层与系统服务层通过这些接口可以直接访问存储或者L/O等的访问，并不需要关心这些接口的资源是来自于芯片本身还是外设。

BSW通过MCAL抽象MCU芯片，ECU抽象层抽象ECU硬件电路将整个硬件剥离开来，因此，ECU抽象层之上的软件层级只需要关注于软件而不需要关注硬件了。

（3）服务层

服务层的目的在于提供给应用层可用的服务内容，主要包括：诊断、操作系统、通信、内存管理等。其中，除了操作系统之外，服务层的软件模块都是与ECU平台无关的。

(4)复杂驱动层

复杂设备驱动组件的目的在于提供复杂传感器和执行器的驱动，使应用层可直接访问硬件资源。通常对于实时性有着非常高需求的应用可以利用该组件实现控制管理，或是将过去已经应用非常成熟的功能代码移植到该架构下时可放在该组件中，比如电机的驱动控制，MCU的PWM控制等

按照功能层级可以划分为：

（1）存储协议栈

（2）通信协议栈

（3） I/O接口

（4）系统服务

（5）复杂驱动

 文章转载自公众号：汽车电子嵌入式