【车载开发系列】AutoSar架构再认识

【车载开发系列】AutoSar架构再认识

0. 前言

AUTOSAR全称是Automotive Open System ARchitecture，是一个开放式的汽车电子系统架构标准，旨在为汽车电子软件开发提供一种标准化的方法和框架。AUTOSAR标准将汽车电子系统分为两个主要领域：软件和硬件，其中软件是基于面向对象的方法进行开发的，而硬件则包括处理器、传感器、执行器和通信总线等。AUTOSAR标准的目标是提高汽车电子系统的可靠性、安全性和可维护性，同时降低软件和系统的开发成本。
在AUTOSAR架构中，软件组件是系统的基本构件块，软件组件之间通过标准化的接口进行交互。AUTOSAR架构还定义了通用的数据结构和数据流程，以及一套标准的开发流程和工具链。
总之，AUTOSAR是一个开放式的、标准化的汽车电子系统架构标准，旨在提高汽车电子系统的可靠性、安全性和可维护性，降低软件和系统的开发成本。

一. 应用软件层

AUTOSAR运行时环境（RTE）以上的层，由映射在标准化汽车电控单元(ECU)上的AUTOSAR软件组件组成。AUTOSAR软件组件和其他软件组件之间的所有交互都是通过AUTOSAR运行时环境（Run Time Environment，RTE）进行的。

二. 实时运行环境（RTE）

在系统设计层面（无论硬件如何起草整个系统的逻辑视图），AUTOSAR运行时环境都是ECU间信息交换的通信中心。无论是ECU内部通信通道（如CAN、LIN、FlexRay、MOST等）还是ECU外部通信通道，RTE都可以通过提供相同的接口和服务向AUTOSAR软件组件提供通信抽象。由于运行在RTE之上的软件组件的通信主要取决于具体应用，所以，需要定制RTE—部分由ECU特定生成，部分通过配置生成。因此，所得到的RTE不同，ECU之间也不同。

三. 基础软件层（BSW）

是标准化软件层，为AUTOSAR软件组件提供服务，是运行软件功能部件所必需的。它不具有任何功能性的任务本身，并且位于AUTOSAR运行时环境之下。基本软件包含标准化和ECU特定模块。
基础软件层分为4大部分：

1）硬件抽象层（MCAL）

MCAL是硬件特定的层，可以确保基本软件组件的标准接口。MCAL管理微控制器的各种片上外设，并提供基本软件组件与微控制器无关的值。MCAL通过通知机制，支持将命令、响应和信息分发到不同的进程，MCAL就是将芯片的寄存器操作都封装成一个AutoSAR规定的统一的Api。就是说这套Api是定死的，但是不同厂商的具体实现可能不同（很重要的一点）。

2）ECU抽象层

ECU抽象提供了任何特定ECU的电气值的软件接口，以便将更高级别的软件与所有底层硬件依赖关系分离。也就是说如果MCAL只封装了芯片，那么ECU抽象层就是将板级所有的硬件都进行了封装。比如我们的控制器上有一个主芯片英飞凌的TC275，还有采样电路，电源电路，CAN电路等等。MCAL就是封装了芯片上有的功能。而ECU抽象层就是将所有的这些都做一个统一的封装。

3）服务层

这里是更加高级的一层了，服务层里是包含诊断协议等系统服务、NVRAM管理及操作系统（OS）等。OS将使用ECU抽象层的Api，再对上层暴露出服务接口，其实就是嵌入式实时操作系统（RTOS）所作的工作。

4）复杂驱动

又叫做CDD，主要工作是将AutoSAR未定义的一些功能封装起来，给应用层提供接口来调用这些功能。复杂设备驱动程序允许直接访问硬件，特别是对于资源关键型应用。

四. AUTOSAR COM

AUTOSAR COM是AUTOSAR标准的一部分，它是从OSEK COM标准的基础上发展而来的。AUTOSAR COM提供了一种标准化的访问汽车通讯系统和ECU（Electronic Control Unit）通讯的方式，提出了一个在不同速率的总线网络之间进行数据交换的方法。它为汽车控制单元应用软件提供了一个统一的通信环境，为内部和外部通信定义了公共的软件通信接口和行为，增强了应用软件模块的可移植性。
AUTOSAR COM提供了基本的通信服务，它有明确的上层模块RTE(Runtime Environment)和下层模块PDU Router。
COM 模块通过调用 PduR _ ComTransmit ( ) 将I-PDU传递到 PDUR 模块,PDUR 模块根据静态定义的路由表,查找 I-PDU 的目的模块,然后调用相关下层CanIf_Transmit( ) 函数实现传输

五. PDU-Router

PDU-Router模块是AutoSar架构通信协议栈的通用模块，也就是CAN，Lin，Eth，FlexRay等总线通信，诊断报文传输的时候就会使用该模块。它也是AUTOSAR Basic Software中的一个模块，对上提供统一的接口，屏蔽下层网络细节，对下层兼容多种车载总线，如 CAN、LIN 和FlexRay 等。PDUR 模块主要包括两个部分，PDU 路由表和PDU 路由引擎。
PDU 路由表静态定义了每个 I-PDU 的路由路径，根据路由表来确定 I-PDU 的上下层模块信息; PDU 路由引擎是根据 PDU 路由表进行操作的实际代码，实现 I-PDU 信息的路由传递。
可以简单的理解为PDU-Router模块就是一个软件中间件，统一管理所有报文的传输方向。

六. AUTOSAR架构目标

AUTOSAR架构的目标主要有三个：

1. 建立独立于硬件的分层软件架构
2. 为实施应用提供方法论，包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU
   制定各种车辆应用接口规范，作为应用软件整合标准，以便软件构件在不同汽车平台复用
3. AUTOSAR整体框架为分层式设计，以中间件RTE(Runtime Environment)为界，隔离上层的应用层（Application Layer）与下层的基础软件BSW（Basic Software）

• AUTOSAR提倡“在标准上合作，在实现上竞争”原则；
  AUTOSAR核心思想是“统一标准，分散实现、集中配置”，即统一的开放平台、软件系统层次化模块化，降低应用与平台耦合性、统一格式的配置信息，集中配置生成系统；
  一个汽车电子应用系统可包含多个相互关联的AUTOSAR组件。组件通过虚拟功能总线（VFB）提供标准通信机制与服务，实现平台无关性；

七. AutoSAR工具链介绍

目前主流的主要是以下两种开发模式：
MATLAB + DaVinci
MATLAB + ETAS

MATLAB ：主要是应用层做算法用的，比较方便实用
DaVinci Developer：主要用来搭建设计APPL的框架架构
DaVinci Configurator pro： 主要用来配置BSW和自动生成RTE的
SWC应用层主要使用Matlab开发，使用Simulink模型开发应用，优点在于生成代码，逻辑清晰，不易出现误编码，缺点是开发周期大于手写代码。
MathWorks Simulink：一个用于AUTOSAR模型建模和仿真的工具，支持多种AUTOSAR版本和硬件平台。
Lauterbach TRACE32：一个用于AUTOSAR软件调试的工具，支持多种MCU和调试接口。
EB tresos Studio：一个用于AUTOSAR配置和代码生成的工具，支持多种AUTOSAR版本和硬件平台。
Vector CANoe：一个用于AUTOSAR通信协议测试和仿真的工具，支持多种通信协议和ECU。
Vector CANape：一个用于AUTOSAR应用程序调试和校准的工具，支持多种通信接口和ECU。
Tasking by Altium：一个用于AUTOSAR应用程序编译和调试的工具，支持多种MCU和编译器。
ETAS：一款用于AUTOSAR系统调试和测试的工具，支持多种MCU和总线协议。ETAS是Bosch旗下的一家汽车电子开发工具和测试系统提供商。
Davinci：一款用于AUTOSAR系统调试和测试的工具，支持多种MCU和总线协议。ETAS是Bosch旗下的一家汽车电子开发工具和测试系统提供商。