汽车电子-AUTOSAR基础简介

Posted 2021-09-10 Jason_Lee155

AUTOSAR的历史

AUTOSAR（AUTomotive Open System Architecture），即汽车开放系统架构，由全球汽车制造商、零部件供应商及其他电子、半导体和软件系统公司建立，目的是为了降低汽车控制软件的开发风险，提高软件复用度。AUTOSAR联盟自2003年成立以来，成员队伍不断壮大，基本上涵盖了世界各大著名整车厂、零部件供应商、半导体公司及软件工具开发商。近年来也有越来越多的中国企业例如华为、百度、长城汽车等加入联盟。

Autosar的出现因素

• 汽车电子系统复杂度和代码量的不断提升，当前整车控制系统的代码量都已达到千万行代码的级别，其复杂度远比高端的航空航天要高，只是安全性比他们要低些。
• 软件的复习用性差，由于软件依赖于固定的硬件开发，当硬件发生变更时功能往往需要推倒重来，无疑增加重复开发的工作量和周期，这都是血琳琳的投入和成本。

汽车行业里有众多的整车厂（OEM）和供应商。一般来说，每一家OEM会生产不止一种车型，每一家OEM对不同子系统和零部件会选择不止一个供应商，每个供应商也会向不止一家OEM供货。减少开发成本最有效的办法就是，尽可能让产品可重复利用，用数量来分摊开发成本。OEM希望可以让同一套系统和部件用在不同的车型上；同一辆车上来自不同供应商的的各个系统和部件可以相互兼容；而供应商希望开发出来的部件和算法可以通过简单的软件调整就供给不同的OEM。

另一方面，各个供应商的开发进度往往是不同步的。人们希望可以在供应商开发的过程中就可以测试该部件能否与整车上的其它系统正确配合。因此需要一种统一的、标准化的系统描述方法。

这便是AUTOSAR的初衷，即通过提升OEM以及供应商之间软件模块的可复用性和可互换性来改进对复杂汽车电子电气架构的管理。

对于此，圈内几位大佬相约一起讨论五百回合最后搞了个Autosar出来，并成为最初的九大核心成员（博世、BMW、大陆、福特、戴姆勒、PSA、通用、丰田和大众）。

AUTOSAR的基本思想

为此，AUTOSAR需要做到以下几件事情：

• 对应用软件与底层软件之间以及应用软件之间的接口进行标准化
• 给出一个控制器软件参考架构
• 规范分布式开发流程中的交换格式

AUTOSAR提出了一个口号，叫做“Cooperate on standards, compete on implementation”。意思就是汽车行业的整车厂和供应商共同合作开发一套汽车电子系统的软件开发标准，这样大家就可以专注于功能的开发，而无需顾虑目标硬件平台。

打个简单的比方。整车和零部件就好比是电脑和外设的关系，它们之间通过标准的USB接口来连接。无论是联想的电脑，还是戴尔的电脑，无论是100块的鼠标，还是1000块的鼠标，它们都互相可以即插即用。电脑厂家可以专注做自己的电脑，而无需考虑会外接什么样的鼠标键盘；相应的，外设厂可以专注做自己的鼠标键盘，而无需考虑会用在什么样的电脑上。它们之间的接口和交换格式，已经由USB标准规定了。这就是标准化带来的便利。

AUTOSAR架构分层

在AUTOSAR架构中，系统软件从上到下分层依次为：应用层（Application Software Layer），运行时环境（Runtime Environment，RTE），基础软件层（Basic Software Layer，BSW），微控制器（Microcontroller）。每层之间为保持独立性，每一层只能调用下一层的接口，并为其上一层提供接口。

应用层（Application）

应用层包含若干软件组件（Software Component，SWC），SWC封装了需要实现的具体功能，独立于微控制器的类型，与底层硬件的独立性是通过虚拟功能总线（VFB）来实现。而VFB则提供了一种通信机制，具体由RTE和BSW来实现。

SWC由端口（Port）和运行实体（Runnable Entity，RE）组成。

端口（Port）是SWC之间进行通信的接口，通信内容包含数据元素（Data Element，DE）和操作（Operation，OP）。

两种常用端口：发送-接收端口（Sender-Receiver Interface，S/R）和客户端-服务器端口（Client-Server，C/S）。

S/R用于数据传递，发送方将数据元素（Data Element，DE）发送给一个或者几个接收方。C/S用于操作（Operation，OP），即函数调用，服务器提供函数，而客户端用来调用函数，一个函数可以被多个客户端调用，但是一个客户端不能调用多个函数。

运行实体（Runnable Entity，RE）是一段可执行代码，封装了具体算法。

运行时环境（RTE）

RTE是AUTOSAR中虚拟总线功能（VFB）接口的实现。

基础软件层（BSW）

基础软件层又分为4个小层，分别是：服务层（Services Layer），ECU抽象层（ECU Abstraction Layer），微控制器抽象层（Microcontroller Abstraction Layer），复杂驱动（Complex Drivers）。

每个小层又可以进行更具体的划分，如下图：

基础软件层包含如下类型的服务：

（1）输入/输出（I/O）：对传感器、执行器和ECU外围设备的标准化访问

（2）内存（Memory）：对内部/外部（非易失性存储器）的标准化访问

（3）加密（Crypto）：对内部/外部加密原语的标准化访问

（4）通信（Communication）：车辆网络系统、车载ECU通信系统和ECU内部软件的标准化访问

（5）非车载通信（Off-board Communication）：V2X、车内无线网络系统和非车载ECU通信系统的标准化访问

（6）系统：提供标准化（包括操作系统，定时器，错误存储器）和ECU特定（ECU状态管理，看门狗管理）服务和库函数

服务层（Services Layer）

在BSW层最上层，提供以下服务：
（1）操作系统（OS）

（2）车辆网络通信和管理服务

（3）内存管理（NVRAM管理）

（4）诊断服务（包括UDS通信，错误存储器和故障处理）

（5）ECU状态管理，模式管理

（6）逻辑和程序流监控（Wdg管理）

复杂驱动（Complex Drivers）

提供集成特殊功能的可能性，例如设备的驱动，这些驱动有以下特点：
（1）在AUTOSAR中没有明确规定

（2）对时序要求比较高

（3）用于移植目的

ECU抽象层（ECU Abstraction Layer）

提供访问外围设备的API，使更上层的软件独立于ECU硬件。

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

包含可以直接访问微控制器和外围设备的底层驱动。