AUTOSAR架构、分层模型以及方法论学习笔记

一、 AutoSAR为汽车电子系统而生

汽车电子系统越来越复杂，越来越多的功能需要集成在ECU上，导致电子系统复杂性不断提高，软件代码量也在急速上升。整车生命周期往往高于ECU生命周期，需要在整车生命周期之内需要对ECU的软件进行开发和升级。

不同的平台有很多复杂的嵌入式平台，功能随着电子系统的发展不断增强，电子系统也越来越复杂，五花八门的硬件平台使得开发过程变得复杂，切换硬件平台就需要大量的人力来切换平台，学习不同的平台。而且嵌入式系统不支持硬件抽象，使得每次在进行新的处理器更换之后需要重新底层软件的开发，软件模块化的过程非常有限。导致汽车电子化发展出现很多问题。

在此背景下，全球主机厂、Tire1和汽车电子软件系统公司联合建立了一套标准协议——AUTOSAR架构（汽车开放系统），为汽车软件提供了一个标准化的、模块化的架构，使得软件可以在不同车型和平台上复用，极大地提高了软件开发的效率和灵活性。

它不仅简化了软件开发的流程，降低了开发成本，还为汽车制造商提供了更加灵活的软降定制能力。由于模块化的架构，可以让软件在不同车型和平台上复用，极大提高软件开发的效率和灵活性。

AUTOSAR计划目标主要有三个：

1.建立分层的体系架构
2.为应用程序的开发提供方法论

3.制定各种应用接口规范

下文主要从这三个方面来介绍

二、AutoSAR分层模型

AUTOSAR主要分为3个层级：应用软件层（Application Layer，即AppL），实时运行环境（Run Time Environment，即RTE）和基础软件层（Basic Software，即BSW）

1.应用软件层（APPL）

该层是由一个个SWC组成的，每个SWC咱们可以理解为一个.c文件，而整个应用软件层就是一个文件夹。如下图说明了对应关系，可以看出，这里的整个工程就是我们的AutoSAR架构，而其中的AppL、RTE和BSW都分别对应一个文件夹，而我们的SWC组件就是一个一个的.c文件（和.h）

实时运行环境层(RTE)

RTE是VFB总线在ECU上的一个实线，RTE以上是VFB view，所有的SWC通过RTE总线进行相互链接，进行数据交互等。

RTE以下是BSW基础软件层，在RTE这一层，将ECU的底层软件和硬件进行了隐藏，不用关心具体的I/O是什么样子的、服务是由哪个模块提供的，传输的信号是通过何种总线协议进行传输的。RTE的功能是对底层软件的抽象化。

主要功能：一方面实现数据的通讯；另一方面实现任务调度。

3.基础软件层(BSW)

基础软件层又分为四大类，分别是如下描述：

硬件抽象层（MCAL）：硬件抽象层又叫MCAL，位于BSW最底层，就是将芯片的寄存器操作都封装成一个AutoSAR规定的统一的库Api。就是说这套Api是不同厂商都支持的，但是底层怎么实现，就是芯片厂商的事了。同时也有软件工具EB，可以通过界面配置MCAL功能

ECU抽象层：位于MCAL层之上，如果说MCAL只封装了芯片，那么ECU抽象层就是将硬件上所有的硬件都进行了封装。比如我们的控制器上有一个主芯片英飞凌的TC397，还有采样电路，电源电路，CAN电路等等。而MCAL就是封装了芯片上有的功能。而ECU抽象层就是将所有的这些都做一个统一的封装。所以不管硬件是如何实现的，这里封装后，也形成了统一的Api

服务层：是基础软件的最高层，提供各种类型的后台服务，例如网络服务、内存管理和总线通信服务等，服务层里是包含操作系统（OS）。OS将使用ECU抽象层的Api，再对上层暴露出服务接口，其实就是嵌入式实时操作系统（RTOS）所作的工作。

服务层提供以下接口：操作系统的功能、车辆网络通信管理服务、存储器服务，诊断服务（包括UDS通信、错误存储和故障处理）、ECU状态管理，模式管理，逻辑和时间程序流监控、密码服务。

服务层的主要任务是位应用程序、RTE以及基础软件模块提供最基本的服务，按照服务对象不同，分为：通信服务、内存服务和系统服务三个部分。

复杂驱动层：又叫做CDD，跨越于微控制器硬件层和RTE之间，主要任务是整合具有特殊目的且不能用MCAL进行配置的非标准功能模块。将该部分功能嵌入到AUTOSAR基础软件层中，从而实现处理复杂传感器以及执行器的特定功能和时间要求，提供集成特殊用途的功能，例如设备驱动程序，在AUTOSAR中未规定的、具有非常高的时间限制或用于迁移等目的。

三、AutoSAR接口类型的定义

AUTOSAR定义了3种类型的接口：

1.标准接口：使用特定语言进行定义的标准化的函数，通常用在ECU内部的函数通讯。但是使用标准化的接口不能实现在网络上的通讯，是不符合AUTOSAR接口标准的。

2.AUTOSAR接口：定义软件SWC模块、SWC和BSW通讯的端口。在SWC这一端的接口都是AUTOSAR的interface（接口），负责服务、通讯的模块也是符合AUTOSAR的接口的，在总线上进行通讯。

3.标准化的AUTOSAR接口：在AUTOSAR接口的基础上，对这些语法、语义的定义进行了标准化的AUTOSAR接口，通常是用来提供标准的AUTOSAR 服务的。

四、AutoSAR方法论 3.0

AUTOSAR为汽车电子软件系统开发过程定义了一套通用的技术方法，即AUTOSAR方法论。

如果将软件开发比作做菜的话，软件模块可以理解成是原料，那方法论就好比一本菜谱，告诉我们如何去做这样一道菜，菜谱里面可能包含了需要的原料、分量、火候、制作过程等等。

AUTOSAR方法论定义了很多信息，例如开发过程中的角色以及他们的分工，在每个阶段用什么样的工具干什么样的工作，工作的输入和输出等内容。

Auotosar方法论使用了结构化的开发方法，可以让开发在开始的时候就可以对需求（功能/要求）上的缺陷进行识别，一开始就可以对缺陷进行修正。避免在开发最后阶段才发现最初定义的系统是有问题的。

AUTOSAR 3.0开发方法流程分为：系统阶段、ECU定义阶段、软件开发阶段和ECU执行代码阶段。

软件组件描述文件，包含了软件组件相关的信息，比如用到了什么样的Data和Operation，SWC对基础架构和对硬件的要求，SWC使用的资源，与应用协议相关的限制，SWC的接口等，

ECU资源描述文件。描述了可用的硬件资源，包含了ECU上的传感器、执行器、存储器、处理器、收发器、引脚分配等内容，主要是一个描述ECU硬件的文件，通过这个描述文件可以知道有多少ECU资源可供软件使用，也决定了哪个功能分配给哪个ECU上。

系统约束描述文件。就是整车电子电气架构，包含了网络拓扑，通讯限制、协议、通信矩阵，波特率等。

系统配置过程

根据软件组件描述文件、ECU资源描述文件和系统约束描述文件，将对应的信息进行配置，生成系统配置文件，该文件包含了SWC对ECU的映射；数据端口到通信矩阵的映射。

ECU配置过程：

根据系统配置描述文件提取出与各个ECU相关的系统配置描述信息，提取出来的信息生成ECU提取文件，ECU配置生成器根据这个提取文件对ECU将进行配置，如RTE的配置、BSW的配置，运行实体到任务的分配等，从而生成ECU配置描述文件。

ECU配置过程主要是对 RTE和BSW的配置。在 RTE 配置阶段，需要将软件组件的运行实体映射到相应的操作系统任务；在 BSW 配置阶段，需要详细配置 BSW 层中所需要用到的模块，一般有操作系统、通信服务、ECU抽象层和MCAL等，并将结果保存在 ECU 配置描述文件中。

ECU实现

根据ECU的配置文件以及对应的代码生成工具，生成工具会将配置文件转化成对应的C代码，这些C代码再配合上autosar的library文件以及SWC实现的文件，整合这些文件，就可以生成ECU的执行的二进制代码，这就实现了ECU开发。

Autosar 4.0方法论，是在3.0基础上的扩充，对开发过程进一步的完善。

在系统设计之前，增加了两个部分，Abstract System开发过程和VFB System开发过程，是对系统开发的进一步抽象。在更高层次上进行的系统开发。

开发流程划分成了三块：BSW的开发、系统的开发、VFB的开发。

总结：

AUTOSAR 方法论描述了从系统底层配置到整个ECU可执行代码的产生过程的设计步骤，作为汽车电子软件平台标准化的历程中的一个巨大飞跃，建立这样一个标准化平台并贯彻标准化，将会缩短新产品的研发时间和测试时间，从而帮助企业实现快速的市场反应。但也有一些弊端，业内车企特斯拉就选了自研软件和硬件一体化的解决方案，以满足其独特的需求和快速迭代的目标。

文章来源