一、AutoSar 的背景介紹
AUTOSAR是AUTOmotive Open System Architecture（汽车开放系统架构）的首字母缩写，是由全球各大汽车整车厂、汽车零部件供应商、汽车电子软件系统公司联合建立的一套标准协议，是对汽车技术开发一百多年来的经验总结
AUTOSAR目前分为两种：
Classic Platform AUTOSAR
Adaptive Platform AUTOSAR，也称为 CP 和 AP
獲取AUTOSAR的規範文件：https://www.autosar.org//standards
在 AutoSAR 之前，軟件耦合嚴重如下：
1. 開發效率低下
2. 開發週期長
3. 代碼合作開發難，維護難
4. 重用性差 (換平台，必需重寫)
5. 代碼量增加，代碼質量下降
進一步修正後，還是有缺點：
1. 對不同客戶，由於各家需求不同，重用性依然不好
2. 耦合也存在，同時該方法的優劣和架構師的能力直接掛鉤
AUTOSAR的计划目标主要有三个：
1）建立分层的体系架构
2）为应用程序的开发提供方法论
3）制定各种应用接口规范
有了以上了解，拿到規範文件後，你需要明確你的工作內容在整個產品生命週期的位置。簡單介紹下幾個流程概念。
按產品開發流程的順序大致梳理：
1. 整車廠以EE架構設計和應用層功能設計為主，所以如果你身在OEM中，你只需要著重瞭解AUTOSAR的方法論和基於方法論的SWC設計即可。這兩點說著簡單，其實並非我們想象中那麼簡單。方法論本身就是非常巨集觀的概念，想要把控產品流程，能為TIER1提供開啟需求文件，這本身就要對功能和下游工作十分了解，才能有高質量的輸出；
2. TIER1涉及AUTOSAR的工作分工就比較多了。
如果你是系統工程師，著重研究功能演算法的實現，那麼你需要對SWC的升級瞭如指掌，深入理解；如果你是軟體架構工程師，對於上游OEM提供的需求文件要有巨集觀概念，所以也要對方法論和SWC審計十分了解；
如果你是基礎軟體工程師，需要整個團隊協同實現：底層驅動工程師要深入學習晶片的抽象層MCAL應用；BSW協議棧工程師要熟悉OS，ComStack，DiagStack，Memory Stack，WgdStack等協議棧應用細節；複雜驅動工程師，要對AUTOSAR針對CDRV的介面定義方式等深入研究；如果整合工程師，要十分清楚RTE的執行整合和相關應用配置；
3. TIER2要深入研究的內容和TIER1的BSW工程師側重內容相似，主要圍繞晶片MCAL和基礎軟體協議棧展開。
4. 除了以上三類產品開發流程上的角色外，其實還有一個重要角色的存在：工具供應商。瞭解了AUTOSAR架構和實現過程後，大家可能會看到很多arxml格式的配置檔案的製作都離不開工具的支援，以及編譯環境、建模工具等，都離不開一直走在超前道路上的工具供應商。
AUTOSAR的開發流程：
二、AUTOSAR的分层模型
为了实现应用程序和硬件模块之间的分离，AUTOSAR架构被抽象成四层，由上至下依次为：
应用层（Application Layer）
运行时环境层（Run Time Environment，即 RTE）
基础软件层（Basic Software，即BSW）
微控制器层（Microcontroller）
目的：
OEM可以专注于开发特定的、有竞争力的应用层软件（位于RTE之上），另一方面，它使OEM所不关心的基础软件层（位于RTE之下）得到标准化。
三、AUTOSAR的方法论
AUTOSAR设计和开发流程分为三个阶段：
第一阶段：定义系统配置文件
这是系统设计者或架构师的任务。
包括选择硬件和软件组件，定义整个系统的约束条件。AUTOSAR通过使用信息交换格式和模板描述文件来减少初始系统设计时的工作量。系统配置的输入是XML类型的文件，输出是系统配置描述文件，系统配置的主要作用是把软件组件的需求映射到ECU上。
第二阶段：根据系统配置
描述文件提取单个ECU资源相关的信息，提取出来的信息生成ECU提取文件。根据这个提取文件对ECU进行配置，例如操作系统任务调度，必要的BSW模块及其配置，运行实体到任务的分配等，从而生成ECU配置描述文件。该描述文件包含了特定ECU的所有信息。
第三阶段：生成代码
基于ECU配置描述文件指定的配置来产生代码、编译代码，并把相关代码链接起来形成可执行文件。
具体的开发流程如下
1.编写系统配置输入描述文件
在AUTOSAR中，所有的描述文件都是XML类型的文件。系统配置输入文件包含三部分内容：
1）软件组件描述，定义了每个涉及的软件组件的接口内容，如数据类型，端口，接口等。
2）ECU资源描述，定义了每个ECU的资源需求，如处理器、存储器、外围设备、传感器和执行器等。
3）系统约束描述，定义了总线信号，软件组件间的拓扑结构和映射关系。
2.系统配置
系统配置的功能主要是在资源和时序关系的前提下，把软件组件映射到各个ECU上，然后借助系统配置生成器生成系统配置描述文件。这个描述文件包括总线映射之类的所有系统信息以及软件组件与某个ECU的映射关系。
3. 提取特定ECU的描述
从系统配置描述文件中提取出与各个ECU相关的系统配置描述信息，提取的信息包括ECU通信矩阵、拓扑结构、映射到该ECU上的所有软件组件，并将这些信息放在各个ECU的提取文件中。
4. ECU配置
ECU配置主要是为该ECU添加必要的信息和数据，如任务调度、必要的基础软件模块及其配置、运行实体及任务分配等，并将结果保存在ECU配置描述文件中，该文件包含了属于特定ECU的所有信息，换言之，ECU上运行的软件可根据这些信息构造出来。
5. 生成可执行文件
根据ECU配置描述文件中的配置信息，生成RTE和基础软件配置代码，完成基础软件和软件组件的集成，最终生成ECU的可执行代码。
四、AUTOSAR的接口类型
通过RTE实现AUTOSAR软件组件之间以及应用层与基础软件之间的通信前提是：
软件组件之间必须有标准的AUTOSAR接口。
AUTOSAR规范把汽车电子领域内的一些典型的应用划分为若干个由一个或多个软件组件组成的模块，并详细定义了这些软件组件相关的参数，例如名称、范围、类型等。
AUTOSAR定义了三种接口：
1. 标椎化接口（Standardized Interface）
标椎化接口是AUTOSAR规范中用C语言定义的API。这些接口用于ECU内部BSW模块之间，RTE和操作系统之间或者RTE和COM模块之间；
2. AUTOSAR接口（AUTOSAR Interface）
AUTOSAR接口是一种与应用相关的接口，与RTE一并生成。
基于AUTOSAR接口的端口可以用于软件组件（Software Component,SWC）之间或者软件组件与ECU固件之间（例如复杂驱动）的通信；
3. 标准化的AUTOSAR接口（Standardized AUTOSAR Interface）
标准化AUTOSAR接口是一种特殊的AUTOSAR接口。
这些在AUTOSAR规范中定义过的接口被SWC用于访问AUTOSAR BSW模块提供的服务，比如ECU管理模块或者诊断事件管理模块；
五、AUTOSAR的基础软件层
对基础软件层BSW进行进一步的细分，划分为4层：
1. 微控制器抽象层（MicroController Abstraction Layer，即MCAL），它位于BSW的最底层，包含了跟硬件相关的驱动程序、软件模块与直接访问微控制器内部和外围的设备，可以用来访问内存、通信和I/O等；
2. ECU抽象层（ECU Abstraction Layer），位于微控制器抽象层之上，对接微控制器抽象层所提供的驱动程序，并同时包含对外部设备的驱动程序，然后负责向上提供统一的访问接口实现对通信、内存或者I/O的访问，从而使得上层模块无须考虑这些资源由微处理器提供还是由外部设备提供
3. 服务层（Service Layer），提供各种类型的后台服务，例如网络服务、内存管理和总线通信服务等，操作系统就位于这一层。服务层是基础软件的最高层，同时与应用程序也有关联。虽然对I/O信号的访问由ECU抽象层覆盖，但服务层负责提供以下接口：操作系统的功能、车辆网络通信管理服务、存储器服务（NVRAM管理）、诊断服务（包括UDS通信、错误存储和故障处理）、ECU状态管理，模式管理、逻辑和时间程序流监控（Wdg管理器）、密码服务（密码服务管理）；
4. 复杂驱动层（Complex Drivers Layer，即CCD），跨越于微控制器硬件层和RTE之间，其主要任务是整合具有特殊目的且不能用MCAL进行配置的非标准功能模块，将该部分功能嵌入到AUTOSAR基础软件层中，从而实现处理复杂传感器以及执行器的特定功能和时间要求，提供集成特殊用途的功能，例如设备驱动程序，在AUTOSAR中未规定的、具有非常高的时间限制或用于迁移等目的
所以，总结一下，基础软件层BSW的组件及其功能对应如下：
1. 系统：提供标准化的规定（针对操作系统、定时器以及错误存储器）、ECU特定的服务（ECU状态管理、看门狗管理）和库函数
2. 内存：对内部和外部的内存（非易失性存储器）的访问入口进行标准化
3. 通信：对汽车网络系统、ECU通信系统以及ECU内部软件的访问入口进行标准化；
4. 输入/输出：对传感器、执行器以及ECU外设的访问入口进行标准化
同时，对BSW中的各个子层，还可以从功能上将其中的各个模块划分为4种类型：
1. 驱动模块Driver
1.1 内部驱动
内部器件位于微控制器（单片机）的内部，例如内部EEPROM、内部CAN控制器、内部ADC模块等。
内部驱动程序就是针对单片机内部器件资源的驱动程序，这部分驱动程序属于微控制器抽象层（MCAL）。
1.2 外部驱动
外部器件是指单片机外部的ECU硬件，比如外部EEPROM、外部看门狗、外部Flash等。
外部驱动程序就是针对单片机外部硬件资源的驱动程序，属于ECU抽象层。外部驱动程序需要通过微控制器抽象层（MCAL）驱动程序来实现对外部器件的驱动。
这种方法下AUTOSAR也支持嵌入在系统基础芯片（SBCs）中的组件，像收发器以及看门狗等。例如，使用SPI通信接口的外部EEPROM驱动程序是通过SPI总线处理程序来驱动外部EEPROM的。
但是有一种例外，对于和内存映射相关的外部器件（如外部Flash存储器），其驱动程序是可以直接对微控制器进行存取访问的，所以这部分驱动程序属于微控制器抽象层（MCAL）。
2. 接口模块Interface
接口模块包含了对其次级模块进行抽象的功能，比如对一个特定功能的硬件进行抽象。它提供一个通用的接口函数（API）来访问一种特定的器件类型，且与该类型器件的数目无关，同时也与器件的具体硬件实现无关。
接口模块不会改变数据的内容。一般来说，接口属于ECU抽象层。例如，CAN通信系统的接口模块提供一个通用的接口函数来访问CAN通信网络，并且与ECU上CAN控制器的数目以及硬件实现无关。
3. 处理模块Handler
处理模块是一个专用的接口，它控制一个或多个客户端对一个或多个驱动程序进行并行、多重以及异步地访问。也就是说，它起着缓冲、队列、仲裁以及多路复用的功能。同时，处理程序也不会改变数据本身的内容。处理模块通常会并入驱动程序或是接口模块中（如SPIHandlerDriver、ADC Driver等）
4. 管理器Manager
管理器为多重的客户端提供特定的服务。当单纯的处理程序不能满足对多重的客户端进行抽象时，就需要用到管理器来进行处理。除了处理功能外，管理器还可以对数据内容进行评估、改变或是适应数据内容。
一般而言，管理器属于服务层。例如，非易失性随机存储器（NVRAM）的管理器负责对内部或是外部存储设备进行并行的访问，如Flash、EEPROM存储器等。同时，它也可以完成分布式并且可靠的数据存储、数据校验以及默认值的规定等。
1. 微控制器抽象层
微控制器器抽象层位于AUTOSAR分层模型中的BSW的最底层，它包含内部驱动，可以直接访问微控制器和片内外设。进一步的，MCAL又可分为微控制器驱动模块组（Microcontroller Drivers）、存储器驱动模块组（Memory Drivers）、通信驱动模块组（Communication Drivers）、以及I/O 驱动模块组（I/O Drivers）。各个部分又由具体的与微控制器硬件相对应的驱动模块组成，如下图：
1.1、微控制器驱动
微控制器驱动由通用定时器驱动（General Purpose Driver，GPT Driver）、看门狗驱动（Watchdog Driver，WDG Driver）、微控制器单元驱动（Microcontroller Unit Driver，MCU Driver）和内核测试（Core Test）四个部分组成。
1.1.1、GPT Driver
在AUTOSAR中有两类定时器，操作系统定时器和硬件定时器。该模块使用通用定时器单元的硬件定时器通道，为操作系统或者其他基础软件模块提供计时功能。一个典型的时间周期是50us-5ms。
GPT驱动的作用是：
1. 启动和停止硬件定时器；
2. 得到定时器数值；
3. 控制时间触发的中断；
4. 控制时间触发的中断唤醒。
1.1.2、WDG Driver
WDG Driver的功能主要是初始化和触发看门狗。WDG Driver有内部WDG Driver和外部WDG Driver。内部WDG Driver控制MCU的内部看门狗定时器，提供触发功能和模式选择服务；外部WDG Driver控制外部硬件看门狗，与内部WDG Driver一样，提供触发功能和模式选择服务。
1.1.3、MCU Driver
MCU Driver位于MCAL层，可以直接访问微控制器硬件，它的主要功能是初始化、休眠、复位微控制器以及提供其他MCAL软件模块所需的与微控制器相关的特殊功能。MCU Driver还能够使能并设置MCU时钟，例如CPU时钟、外围器件时钟、预分频器等参数。
1.1.4、Core Test
Core Test（内核测试）模块包含周期性测试和启动测试。内核测试模块可以对CPU所有寄存器进行测试，提供中断控制和异常检测。该模块还对算术逻辑单元、存储保护单元和缓存控制器等进行检测。
1.2、存储器驱动
存储器驱动由内部EEPROM驱动、内部Flash驱动、RAM测试和Flash测试四部分组成。
1.2.1、内部EEPROM驱动
内部EEPROM驱动提供初始化服务，以及对内部EEPROM的读写、写、擦除等操作。该驱动模块一次只能接受一个任务。
1.2.2、内部Flash驱动
内部Flash驱动提供内部Flash初始化服务，以及对内部Flash的读、写、擦除等操作。该驱动还可以将Flash访问代码下载到RAM中，如果需要的话，也可以执行写、擦除操作。
1.2.3、RAM测试
RAM测试模块通过软件对RAM存储进行测试。该模块包含后台测试和前台测试。其中，后台测试是异步服务，前台测试是同步服务。
1.2.4、Flash测试
flash测试模块提供算法来测试诸如数据/程序闪存、程序SRAM等非易失性存储器，这些存储器可以是集成在微控制器内部的，也可以是外部映射到微控制器的存储器。
1.3、通信驱动
通信驱动由以太网（Ethernet）驱动、FlexRay驱动、CAN驱动、LIN驱动和SPI驱动五部分组成。
1.3.1、Ethernet驱动
Ethernet驱动模块使用以太网驱动层访问某些控制器，对所使用的以太网控制器的硬件特性进行抽象，为上层的以太网使用提供统一的接口。可由由若干个以太网驱动模块复合起来组成。
1.3.2、FlexRay驱动
FlexRay驱动用来抽象不同的FlexRay通信控制器及其硬件相关的特性。通信控制器的FlexRay协议强制特性经过封装后只能通过统一的API进行访问。API提供了映射到基于实际通信控制器的硬件访问序列的抽象功能操作。因此，使用FlexRay驱动可以保证FlexRay接口独立于硬件。
对内部或外部FlexRay通信控制器的驱动来说，需要进行下列处理：
FlexRay控制器的初始化；
1. 配置数据处理单元；
2. 控制指令向通信控制器的传递；
2. 从协议引擎到控制器主接口状态数据的规定；
4. 通信控制器和主处理机之间信息数据的传输。
1.3.3、CAN驱动
CAN驱动针对的是微控制器内部的CAN控制器，它可以实现以下功能：
1. 对CAN控制器进行初始化；
2. 发送和接收报文；
3. 对报文的数据和功能进行通知（对接收报文的指示、对发送报文的确认）；
4. 溢出和错误处理；
5. 唤醒检测；
此外，CAN驱动还具有以下特性：
1. 单个或多个CAN通道；
2. CAN驱动的多重实例化；
3. 对接收报文的中断/轮询模式；
CAN驱动是MCAL的一部分，可以执行硬件访问、向上层提供独立于硬件的API，而仅有的能够访问CAN驱动的上层是CAN接口（CAN Interface）。CAN驱动也可以为数据传输的初始化和通知接收事件的回调函数提供服务，该服务也是独立于硬件的。除此之外，CAN驱动也可以控制从属于同一个CAN硬件单元的CAN控制器的行为和状态。
1.3.4、LIN驱动
LIN驱动使用标准的通用异步收发器（Universal Asynchronous Receiver Transmitter，UART）或者串行通信接口（Serial Communication Interface，SCI）进行通信。
该模块可以完成下列任务：
1. LIN硬件的初始化；
2. 调度表的处理；
3. LIN报文的发送（通过标志位和函数接口确认）；
4. LIN报文的接收（通过标志位和函数接口指示）；
5. 睡眠和唤醒；
6. 协议差错的处理；
7. 报文的超时监测；
LIN驱动也是MCAL的一部分，可以执行硬件访问、向上层提供独立于硬件的API。仅有的能够访问LIN驱动的上层是LIN接口（LIN Interface）。一个LIN驱动可以支持多个通道，但是这些通道要属于同一个LIN硬件单元。
1.3.5 SPI驱动
SPI驱动模块是微控制器内部同步通信串行接口的驱动。SPI驱动为SPI总线上不同的设备（如EEPROM/Watchdog等）提供读写访问服务。一个SPI设备可以被所使用的SPI硬件和相关的片选信号识别。该模块可以在主、从或者主-从模式下运行。
配置 SPI 驱动应遵循以下步骤：
1. 选择SPI驱动的功能级别，配置可选择的功能特性；
2. 根据数据用途来定义SPI通道，它们可以是SPI驱动的内部缓冲器，或者是由用户提供的外部缓冲器；
3. 根据硬件属性来定义SPI任务，它们会包含一系列使用这些属性的通道；
4. 最后定义任务序列，以优先级排序的方式来传递数据
1.4 I/O驱动
參考文件：
Autosar从入门到精通-实战篇》总目录_培训教程持续更新中...
https://zh.wikipedia.org/wiki/AUTOSAR
https://zh.wikipedia.org/wiki/File:Autosar_architecture.png
原文链接：https://blog.csdn.net/LEON1741/article/details/105847992
https://blog.csdn.net/xyfx_fhw/article/details/94633994?spm=1001.2101.3001.6661.1&utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7ECTRLIST%7EPayColumn-1.pc_relevant_aa&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7ECTRLIST%7EPayColumn-1.pc_relevant_aa&utm_relevant_index=1
No comments:
Post a Comment