AutoSAR入门篇学习总结

AutoSAR入门篇学习总结

第一章 AutoSAR简介
第二章 AutoSAR的应用层（AppL）
第三章 AutoSAR的RTE层概述
第四章 AutoSAR 的基础软件层（BSW）
第五章 AutoSAR 的方法论（Methodology）

---

---

前言

什么是 AutoSAR？
AUTOSAR是AUTomotive Open System ARchitecture 的简称，汽车开放系统架构。
AUTOSAR将汽车电子控制单元（ECU）的软件底层做了一个标准的封装。使得大家都能共用一套底层软件，只需要修改其中的一些参数，就可以匹配不同硬件，也可以匹配不同的应用层软件。
AutoSAR目标是建立一套优秀的软件底层代码，使得各大主机厂都能通用，同时使汽车软件开发更加标准化、 规范化、安全化、快速化和经济化。

---

一、AutoSAR简介

1. AutoSAR架构

1、 应用软件层APPL：
该层是由一个个SWC组成，每个SWC可以理解为一个.c文件，整个应用软件层就是一个文件夹。
2、 实时运行环境RTE：
把BSW比作windows系统，AppL就是开发的应用软件，而RTE更像是一个虚拟机，将上层应用和底层操作系统隔绝开的同时，又兼容了不同厂商开发的软件。
3、 基础软件层BSW：
 硬件抽象层（MCAL）：将芯片的寄存器操作都封装成一个AutoSAR规定的统一的库Api。这套Api是不同厂商都支持的，芯片厂商各自实现底层逻辑。
 ECU抽象层：将硬件上所有的硬件都进行了统一的封装，形成了统一的Api。比如控制器上有一个主芯片英飞凌的TC275，还有采样电路，电源电路，CAN电路等。
 服务层：服务层包含操作系统（OS），OS将使用ECU抽象层的Api，再对上层暴露出服务接口，其实就是嵌入式实时操作系统（RTOS）所作的工作。
 复杂驱动（CDD）：主要工作是将 AutoSAR 未定义的一些功能封装起来，给应用层提供接口来调用这些功能。

2. 工具链

1）MATLAB+DaVinci：国内主流，参考书籍有《基于AUTOSAR规范的车用电机控制器软件开发》
2）MATLAB+ETAS：博世和联电主要用这个，参考书籍有《AUTOSAR规范与车用控制器软件开发》
Matlab：主要是用Simulink做代码生成的，开发应用层软件。
DaVinci Developer：主要用来设计AppL的程序架构 。
DaVinci Configurator pro：主要用来配置BSW和自动生成RTE。

二、AutoSAR的应用层（AppL）

1. AppL的组成

AppL中最重要的就是SWC，而SWC之间通信需要接口，每个SWC中又由runnable组成：
 应用软件组件（SWC）
 AutoSAR 接口（Ports）和连接器（Connector）
 可运行实体（Runnable）

2. SWC的通信

SWC之间的通信是通过应用软件层外进行，称为虚拟功能总线（VFB）。
1）在片内通过RTE通信。一个SWC可以理解为一个.c文件，c文件间通信使用全局变量。
2）在片外通过片外总线通信（CAN Bus）。上图中的SWC都集成了AutoSAR 接口（Ports），而它们之间蓝色的连接线成为连接器（Connector）

3. SWC的分配

上图例子，两个ECU即为两个控制器，分别位于车身前部的车门控制器和车身顶部的顶灯控制器。
ECU内部的SWC是通过RTE的管理来通信的。
跨ECU的通信是通过外部总线（一般为CAN双绞线束）。

4. SWC的类型

原子级的SWC（Atomic SWC）

原子级的 SWC对应一个.c文件，runnable是其中的函数。每个SWC基本是用来实现特定的算法和基础特性。

集合级的SWC（Composition SWC）

集合级的SWC对应一个文件夹，包含一个或多个.c文件，对应一个一个更小的 Atomic SWC。就好像是一个分子由很多原子组成的概念，实现了特定的功能集合。

特殊的SWC

在BSW中，IO硬件抽象层（IoHwAb）和复杂驱动（Cdd)都是需要手动添加代码的，也可以算作是SWC，在DaVinci Developer中可以作为SWC进行配置和添加runnable等操作。

5. Ports的类型

1）接口的类型

2）S/R接口
作用：传输数据。
通过RTE传输数据，并且通过RTE管理数据的传输，避免数据出问题。
一个接口可以包含多个数据，传输基础数据类型（int，float等）和复杂数据类型（record，array等）。
3）C/S接口
作用：提供操作。
Server提供函数供Client调用，支持ECU内和跨ECU，一个接口支持多个操作，可以同步和异步。
同步：直接调用，相当于函数直接插入上下文运行；
异步：需要等待，相当于让函数在另一个线程中运行，运行完了再返回，原上下文依然运行；

6. Runnables可运行实体

Runnable就是SWC中的函数，而在AutoSAR架构在被DaVinci软件生成的时候，Runnable是空函数，需要手动添加代码来实现其功能。 Runnable可以被触发，比如被定时器触发、被操作调用触发或者被接受数据触发等。

这里还要补充一点的是：**Runnable 是需要 OS 中的 Task 做载体的。**这句话是什么意思呢？
runnable是函数，但是在c文件中光有一个函数那没用，必须要调用该函数才能起作用，就文件中光有一个函数那没用，必须要调用该函数才能起作用，就必须要有操作系统中的任务来执行这个函数。类比于必须要有操作系统中的任务来执行这个函数。类比于Windows中的线程就是中的线程就是Task，runnable就就运行在线程上这种感觉。值得注意的是：而操作系统和AutoSAR架构是两回事，Task不是架构里的概念，而是操作系统中的概念，在AppL中没有中没有Task这个概念，不可混为一谈。

---

三、AutoSAR的RTE层概述

1. 什么是RTE

RTE提供了SWC的运行环境。
1） 将一个SWC的信息通过RTE连接到其他SWC或者BSW上；
2） RTE具有管理这些SWC信息的功能，比如接收的SWC正忙，那么RTE负责让发送信息的SWC等待，或者做其他处理；
3） RTE还能触发SWC，比如接收的SWC休眠中，这时发送的SWC发信息过来，RTE就要把接收的 SWC唤醒处理。

2. RTE的作用

RTE是VFB（虚拟功能总线）的具体实现，提供ECU内部或跨ECU的通信管理，提供对runnable的管理功能（触发、唤醒等，通过RTE实现映射到OS的Task上运行）。Vector工具链中，RTE是自动生成的。

3. RTE对Runnables的运行支撑

1）通过RTE给runnable提供触发事件。
2）通过RTE给runnable提供所需资源。
3）将BSW和SWC做隔绝。runnable的运行条件由RTE提供，不能由OS直接提供。

4. RTE对Ports的支撑

1）S/R接口的不同方式
 直接调用（Direct）：相当于有一个全局变量，runnable可以直接读写这个变量。示例：
Std_ReturnType Rte_Read_ ( *data)
Std_ReturnType Rte_Write ( data)
 缓存调用（Buffered）：相当于将全局变量先复制到一个runnable的局部变量中，再操作这个局部变量，最后把这个局部变量再赋值到全局变量中。在runnable操作这个局部变量期间，全局变量是不会改变的。示例：
Rte_IRead (void)
void Rte_IWrite_ ( data)
 队列调用（Queued）：因为数据不止一个，是一组队列的数据，就像我们常用的串口FIFO。因此，可以设置循环接收或者等待接收，等待的话是有超时管理的。示例：
Std_ReturnType Rte_Receive_ ( *data)
Std_ReturnType Rte_Send_ ( data)

2)跨ECU的方式
runnable中调用Rte_Write__()函数后，会需要走runnable (ECU1) ->RTE (ECU1) ->BSW (ECU1) ->外部总线->BSW (ECU2) ->RTE (ECU2) ->runnable (ECU2)。示例：
Com_SendSignal()
Com_ReceiveSignal()

3)C/S接口的不同方式
 同步调用：等同于将被调函数代码嵌入当前调用的函数代码中运行。
//假如我们的被调函数是：
Std_ReturnType RunnableServer(int *param)
//那我们的客户中应该写的调用函数就是：
Std_ReturnType Rte_Call_RunnableServer(int *param)
 异步调用：相当于有两个线程，一个线程运行我们的原函数中的内容，另一个执行被调函数的内容。然后可以过一段时间去读取一下被调函数的返回结果。
 循环检测，就是在那一直等，等到返回值为止，和同步差不多了；
 超时检测，约定一个时间，时间到了就去读取，没到则继续运行我的程序；
 事件触发，当服务函数运行结束，RTE可以触发原函数，告诉它被调函数运行完了；
//执行下面的函数后就能将参数返回了
Std_ReturnType Rte_Result_RunnableServer(int *param)

5. RTE对数据一致性的管理

数据一致性，就是当多个用户试图同时访问一个数据库，同时使用相同的数据对象时，可能会发生以下四种情况：丢失更新、未确定的相关性、不一致的分析和幻想读。说的通俗一点：就是当多个操作同时读写同一个数据的时候，很有可能出bug （实际是由于优先级的问题，可能出现我们的数据被篡改的情况，造成作者不想看到的数据结果）。

数据一致性的实现机制：

1）利用RTE管理
比如IRead操作的是数据的备份，不直接操作原数据。
2）SWC内部变量
runnable可以直接调用，类似于一个c文件中定义的全局变量。但同一个c文件中的函数是可能被放在不同Task上运行的，出现多个函数在同一时刻运行的状况，出现读写异常，解决方式：
 EAs(Exclusive Areas,专用区域)：
相当于一个关中断，调用变量的语句放在里面，运行时不能有更高级的Task打断被保护的语句。
Rte_Enter_();
//这里放置被保护的语句
Rte_Exit_()
 IRVs(Inter-runnable variables,跨函数变量)：
相当于在改变变量的时候被保护，也就是下面语句执行的时候被保护。
Rte_IrvWrite_()
Rte_IrvRead_()

6. RTE与Interface接口

AutoSAR 接口：

一句话概括：之前说的 S/R 和 C/S 接口就是 AutoSAR 接口。

标准接口：

一句话概括：就是 AutoSAR 规定的 C 语言 API。

标准AutoSAR 接口

一句话概括：就是 AutoSAR 接口，不过名称是由 AutoSAR 官方规定不能修改。
特征：就是标准接口和 AutoSAR 接口的特征它都有一部分。首先是和AutoSAR接口一样，提供的是 C/S、S/R 接口；然后又和标准接口一样，函数名是不可变的。
位置：RTE<>Services ，就这么一个地方

AutoSAR 的基础软件层（BSW）

1. 什么是BSW（Basic Software）

这个基础软件层实质上就是将整个ECU分层封装起来，一直封装到OS。
ECU就像是电脑硬件，ECU上的主芯片就是cpu，AutoSAR OS在这里就可以看成是windows。
BSW中的OS是可以由软件直接生成，针对千奇百怪的ECU产品，BSW需要设置不同的配置来满足OS 和上层的需求。

2. BSW的结构

微控制器硬件抽象层（MCAL）

将芯片上的功能都封装为API函数，供上层调用，而这些API函数是AutoSAR规定的。针对不同的芯片，在这一层就可以做到对上层的接口完全一致，同一个操作可以兼容所有芯片。

ECU抽象层

ECU上不光有主芯片，还有其他的一些设备（比如外置存储，外置看门狗等），这一层就是对ECU上包括主芯片在内的所有设备的封装。这些设备其实也是要通过主芯片控制的，其底层还是需要MCAL的支持，比如外置看门狗，就需要和主芯片相连接，由主芯片的接口去配置它。

服务层

服务层里面包含了操作系统OS，同时是将下层的功能统一汇总到这里，将所有与硬件想关的功能都抽象成一个具体应用服务。比如通信，这里就将CAN、I2C和串口等一系列的通信统一抽象称COM通信，应用层可以无需知道该通信具体是走哪种通信方式。具体功能包括：
 诊断（Diagnostics）
 存储管理（NVRAM Management）
 看门狗管理（Watchdog Manager）
 通信（Communication）
 操作系统（OS）
 调度管理（Schedule Manager）
 ECU状态管理（ECU state management）
 通信通道管理（Com Channel Management）

复杂驱动

复杂驱动不属于BSW三层结构中，它的作用相当于补充的作用，在BSW三层结构中没有定义的，但是实际中会用到的功能可以在此实现。

3. BSW结构细分

BSW的I/O功能

I/O 包括了DIO（数字输入输出，就等同于单片机上的GPIO）、ADC和PWM。
 I/O Signal Interface： 对输入数据的初步处理，比如输入消抖；
 Driver for ext. ADC ASIC： 外置ADC的驱动，比如当有外部ADC采样芯片的时候，通过SPI通信，将数据传入主芯片。这里就需要有对外部ADC处理的驱动模块；
 Driver for ext. I/O ASIC： 同上，只不过这里是I/O；
 SPI Handler：SPI（Serial Peripheral Interface，串行外围设备接口）处理驱动，将硬件中的SPI封装成API供上层调用（有的使用的是I2C：Inter Integrated Circuit，内部集成电路）；
 ADC, PWM, DIO：MCAL中的驱动，将硬件中的ADC、PWM、DIO分别封装成API供上层调用；
 SPI, ADC, PWM, DIO（Hardware）：就是指芯片中的这些功能模块；
值得一提的是，I/O HwAb是需要手写代码的（也可以Matlab生成），在DaVinci中可以申请一个SWC声明为IOHwAb来作为一个c文件，在其中添加代码，当成SWC使用。

BSW的Communication功能

 COM：从应用层传下来数据首先就进入这里，应用层无需关心收发的数据是通过什么总线传输的。这些收发的数据是由用户的DBC文件或者arxml文件已经定义好了的。COM主要就起了一个信号接口和网关的作用。
 PDU Router：PDU（Protocol Data Unit）协议数据单元，这个模块的功能就是将COM下发的信号数据分配到相应的协议总线上去；或者将不同的协议变成同一信号上传给COM。
 IPDU Mux：用于解析一些特殊的协议，比如CAN FD或者用户自定义的一些协议。就是起了一个统一CAN ID，不同信号Layout的作用。
 Bus Tp：分包数据传输与错误检测，一般来说只有在诊断的时候才会使用。
 Bus Interface：与硬件无关，主要可以配置收发队列；组帧(FlexRay)；管理时间触发总线的调度表(LIN, FlexRay)。
 Bus Driver：就是MCAL中对主芯片上CAN模块的驱动封装。
 Trcv Driver： Trcv（Transceiver）是收发器驱动。如果是外置CAN收发器，就要用到Trcv Driver驱动，而非Bus Driver。
1）发送流程：
数据流：应用层 -> COM -> PDU Router(PDU Buffer) -> Interface -> Driver -> 发送；
PDU Router辨认总线种类，并把PDU数据（每个PDU有独立的ID）发向不同的下级模块；
Interface根据不同的通道，把报文写入不同的队列；
Driver根据报文的优先级立刻发送报文。
2）接收流程：中断或者循环接收
数据流：接收 -> Driver -> Interface -> PDU Router(PDU Buffer) -> COM -> 应用层；
硬件接收报文后，由Driver发出Rx中断（函数），先通过RxIndication数据被传递到Interface；
数据到达COM后，如果SWCs使用Data ReceptionTrigger就通知RTE；否则暂存到Buffer中；
最后，数据由RTE触发应用层读取。

BSW的Memory功能

ROM存储方式一般有两种：EEPROM和FLASH仿EEPROM；物理位置分为片内、片外。
注：相同大小容量下Flash相对便宜一些，但是只能按块擦写，不能按位擦写。想要让Flash做到按位擦写，就需要先将Flash原来的数据备份一份，再修改其中想要修改的位，再按块擦除，最后将改写好的数据再烧录回原块中。这个过程需要软件的处理，所以称为FLASH仿EEPROM。

 NVRAM Manager: 简称NVM，是应用层访问非易失性数据的唯一接口，提供非易失数据的管理服务。写完后有回调函数通知Memory Abstraction，然后再通知NVM。
 Memory Abstraction Interface:将需要读写的信息解耦，分别分派给EEPROM或FLASH。
 EEPROM Abstraction: EEPROM的抽象层，进一步封装片外或片内EEPROM驱动，给上层提供统一的API接口。
 Flash EEPROM Emulation: 同上，此为Flash的抽象层。
 External E² Drv: ECU抽象层中片外EEPROM的驱动，下面是SPI的驱动，由于片外的EEPROM要通过SPI通信才能访问。因此，片外EEPROM的驱动要放到ECU抽象层中。
 Ext Fls Drv: 同上，此为片外Flash驱动。
 SPI Handler Drv: MCAL中对片上SPI的驱动。
 EEPROM Drv: MCAL中对片上EEPROM的驱动。
 Flash Drv: MCAL中对片上FLASH的驱动。
 SPI，EEPROM，FLASH: 片内的SPI、EEPROM和FLASH功能模块。
 External E² Memory: 片外EEPROM，就是板载的EEPROM，需要通过SPI访问。
 External flash Memory: 片外Flash，就是板载的Flash，需要通过SPI访问。

BSW的Mode Management功能

Mode Management：模式管理，可以理解为对状态的管理（比如ECU的上下电和休眠；CAN通讯的开启和关闭都是状态）。主要管理的对象有ECU、BSW和COM。

 ECU State Manager(EcuM): ECU状态机，主要作用是管理的是ECU的上下电功能（还包括休眠、重启等）。官方手册给出了具体有以下四个功能：
1） 单片机初始化时，初始化OS所需的BSW模块；
2） 为单片机的休眠（Sleep）模式和唤醒（wake up）模式做准备；
3） 执行关机命令和重启命令；
4） 通过唤醒验证协议验证已发生的唤醒；
 Basic Software Mode Manager(BswM): 主要作用是定义一系列规则。一旦满足规则，就执行相应的动作。主要有Communication Control、Ecu State Handing和Module Initialization，而这些都是软件自动生成的。如果要自己添加规则，可以在Miscellaneous中添加。
 Communication Manager(ComM): 主要功能是管理通信的启用和关闭。
 Network Management(Nm If, Bus NM): 主要功能是保持总线唤醒和协调总线关闭。
 Bus State Manager(Bus SM): 切换Bus的状态，比如CAN SM是切换该CAN的启动和关闭。

BSW的Watchdog功能

WdgM: 为应用层提供安全相关的服务
WdgIf: 看门狗接口，主要功能是触发硬件看门狗
Wdg Drv: Mcal中看门狗的驱动

BSW的Diagnostics功能

ECU故障发生了，需要将发生的故障记录到EEP或者Flash中（NVRAM Manager及其更底层模块），还需要用到CAN传输数据到诊断设备上（communication相关模块）。这些信息并非是应用层直接下发，所以这里用的是DCM而非COM。故障发生的时候，还需要对故障做处理的功能。

 FIM: Function Inhibition Manager，功能禁止管理。当error出现时，禁止/使能相关SWC功能。
 DEM: Diagnostic Event Manager，诊断事件管理。下面连接 NVRAM Manager，将这些诊断事件记录到EEP或者Flash中。
 DCM: Diagnostic Communication Manager，诊断通信管理。实现诊断通信协议，我们通常说的 UDS协议（即ISO14229，是Unified Diagnostic Services，统一诊断服务）。
工作流程：
绿色箭头：就是对故障做出快速响应的功能。这里首先由应用层传输数据到DEM，DEM判断出是哪个故障，之后发送给FIM；FIM立即做出判断，通过回调函数通知SWC或者轮询的方式禁止SWC。
黄色箭头：就是将故障记录的功能。接上面故障由应用层传输数据到DEM，DEM一边是发送给FIM，另一边是发送给NVRAM Manager，然后将故障记录到EEP或者Flash中。

BSW的OS功能

AutoSAR OS可以划分为四个等级：SC1、SC2、SC3、SC4（SC：Scalability Classes，可伸缩的类型），下面列出一张表格来看具体区别：

4.BSW小结

1）DaVinci配置工具配置出的AutoSAR架构主要分为两部分：源代码，配置代码。
源代码：主要是每个模块的具体功能实现（比如是用CAN还是CAN FD），定义了所有功能，源代码是固定不变的。
配置代码：配置代码中主要就是#define，我们在DaVinci中某个功能的使能框中打一个勾或者配置了某一项，配置代码中就#define一个定义。

五、AutoSAR 的方法论（Methodology）

1.什么是方法论

搭建符合AutoSAR架构的ECU软件的详细工作流程。
交换文件：OEM和TIER1之间、TIER1内AutoSAR底层和应用层之间和MCAL与BSW之间都需要文件交互。AutoSAR规定了一种新的文件格式：.arxml，可由DaVinci等软件自动生成。
工具链：符合AutoSAR的工具链，如DaVinci、ETAS。

2.工作流程

普通流程（目前大部分车企还停留在这个阶段）

OEM通过软件设计出整车的通信矩阵，并导出DBC、FIBEX或LDF文件；
OEM将这些文件发送给TIER1；
TIER1使用DaVinci软件，导入后直接自动配置Communication的大部分功能；

AutoSAR标准流程

OEM列出需求：OEM设计整车需要哪些ECU、需要哪些功能、要哪些SWC。
OEM分配需求：OEM将所有列出来的SWC分配到各ECU中。
OEM将需求交给TIER1：OEM将各个ECU的需求（通信矩阵、SWC）生成对应的arxml文件，交给TIER1，每个arxml中只包含该ECU需要的内容。
TIER1实现需求：将arxml文件导入到DaVinci中，自动配置AppL层，Communication等内容。然后将SWC补充功能代码，再配置其他必要内容。

3.ECU的项目流程

 ECUEX文件：OEM根据不同的 ECU提取出对应的ECUEX文件交接给TIER1。
 EB tresos：是用来配置MCAL的，它可以直接生成代码；也可以生成arxml导入到DaVinci Configurator中生成代码（建议后者，方便，可靠）。
 DaVinci Developer：是用来配置AppL的，能搭建SWC、Ports之类的框架，然后导入到DaVinci Configurator中生成代码（由于Developer和Configurator共享一个工程，支持双向同步）。
 MATLAB/Simulink：DaVinci Developer生成的arxml还会交接给应用层的工程师，导入到MATLAB/Simulink，在Simulink中会自动生成一个软件框架，工程师再添加模型代码。
开发可以之上而下也可以至下而上：就是说可以在Developer中设计好AppL层的框架导入到Simulink 中做代码填充；也可以在Simulink中直接搭建符合AutoSAR规范的代码，然后导出arxml，再导入到 Developer中，也能自动生成框架；

参考：AutoSAR系列讲解 - 总目录