前面写了两篇关于AUTOSAR的文章，也是自己在学习相关AUTOSAR开发做的梳理。许多朋友在后台私信我，希望我就AUTOSAR 更为深度的分层体系做更详细细致的定义。
前两文都提到了 AUTOSAR architecture的分层式设计，用于支持完整的软件和硬件模块的独立性(Independence)，中间 RTE(Runtime Environment)作为 虚拟功能总线VFB（Virtual Functional Bus）的实现，隔离了上层的 应用软件层（Application Layer）与下层的 基础软件（Basic Software），摆脱了以往ECU软件开发与验证时对硬件系统的依赖。

打开网易新闻 查看精彩图片
软硬件分离的分层设计，对于OEM及供应商来说，提高了 系统的整合能力，尤其标准化交互接口以及软件组件模型的定义提高了各层的 软件复用能力，从而降低了 开发成本，使得系统集成与产品推出的速度极大提升。
1 AUTOSAR分层结构及应用软件层功能
打开网易新闻 查看精彩图片
图中所示，算上 复杂驱动层（Complex Device Drivers），AUTOSAR架构中共分六层：

  1. 应用软件层（Application Layer）

  2. 运行环境RTE(Runtime Environment)

  3. 服务层（Services Layer）

  4. ECU抽象层（ECU Abstraction Layer）

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

  6. 复杂驱动（Complex Device Drivers）

打开网易新闻 查看精彩图片
而 各层 更细致 的划分如上，自上而下逐层介绍：
应用软件层中，AUTOSAR的软件被组织在独立的单位 软件组件（software-component）中，其中封装了部分或全部汽车电子的功能与行为，包括对具体模块功能的实现以及对应描述，但是对外界仅仅开放了定义好的接口，称之为PortPrototypes，而所有ECU内部 组件之间的通信及 获取其他ECU资源的动作就都必须要通过接口来 访问RTE来完成了。
应用软件层内的 通信关系如下： 1.软件组件能和同一个ECU上其他软件组件通信 2.软件组件能和位于不同ECU上的其他软件组件通信 3.软件组件能和有端口并位于同一个ECU上的 基础软件（BSW）进行通信
2 虚拟功能总线VFB及运行环境RTE 虚拟功能总线 （VFB）是底层基础软件与网络拓扑结构的抽象，是AUTOSAR提供的所有通信机制的集合，在信息数据交互的过程中，应用程序被建模为组合组件。 当系统进行配置时，软件组件就会被映射到指定ECU上，而同时组件间的 虚拟连接也被 映射到了CAN, FlexRay，MOST等总线上。最后软件组件利用 预先定义好的端口，通过VFB来实现通信。
打开网易新闻 查看精彩图片
运行环境RTE即是具体单个ECU上对 VFB接口的实现，可以理解成是 面向对象的编程语言中 对象的创建。（小编没有对象，上海40°就只能在家写写文 T_T）
各软件组件之间不允许直接进行通信，由RTE封装好了下层如 OESK、COM等通信层BSW后，为上层提供数据通信所需的RTE API，再使用端口或者Sender-Receiver通信和Client-Server通信的方式进行交互。
案例来自虹科电子技术文档
打开网易新闻 查看精彩图片
软件组件「SWC1」的运行实体A通过端口「switch」向外发送名为a的数据元素，软件组件「SWC2」的运行实体B则通过端口「cmd」接收该数据。该过程中运行实体A调用的RTE API是Rte_Write_Switch_a, 运行实体B实现时调用的RTE_API是Rte_Read_cmd_a。可见软件组件在与其他软件进行通信时，并不依赖模块所处的网络环境及特定拓扑结构。有些ECU 内部的S/R通信API可以直接映射到赋值语句，而其他某些ECU内的C/S通信API则可以映射为调用服务运行实体的语句。
3 基础软件层(BSW)层内划分及其功能 服务层（Services Layer）被分为3个部分： 1、 通信服务（Communication Services） 将包括CAN、LIN、FlexRay在内的整车网络系统、ECU网络及软件组件内的访问进行了统一封装，模块则通过通信硬件抽象层进行通信：

  • 对上层的应用软件层隐藏了协议以及报文属性

  • 提供了统一的总线通信接口供应用软件层调用

  • 提供了统一的网络管理服务

  • 提供了统一的诊断通信接口

2、 内存服务(Memory Services)

将微控制器内外内存的访问进行统一封装，而NVRAM管理器提供了一个RAM镜像，来支持数据的快速读取。

  • 以统一的格式为上层的应用软件层传输非易失性数据

  • 抽象了内存地址以及属性

  • 为数据的保存、加载、校验保护、验证以及安全存储提供了统一的机制

3、 系统服务（System Services）

  • 提供RTOS服务，包括中断管理、资源管理、任务管理等

  • 提供功能禁止管理、通信管理、 ECU状态管理、看门狗管理、同步时钟管

理、基本软件模式管理等服务

ECU抽象层被分为4部分： 1、 I/O硬件抽象层(I/O Hardware Abstraction)

  • 通过I/O硬件抽象中的信号接口来访问不同的I/O设备

  • 对电流、电压、频率等I/O信号进行封装传输

  • 对上层的应用软件层隐藏下层的ECU硬件

2、 通信硬件抽象层(Communication Hardware Abstraction)

通信硬件抽象将微控制器及板上所有的通信信道都进行了封装，并对CAN、FlexRay、LIN、MOST等通信方式进行了抽象的定义

3、 内存硬件抽象层（Memory Hardware Abstraction）

将片内、板上的内存资源进行统一封装，如对片内EEPROM和片外的EEPROM都提供了统一的访问机制

4、 车载设备抽象层(On-board Hardware Abstraction)

对ECU上特殊的一些外设进行封装，如WatchDog以及时钟等
微控制器抽象层（Microcontroller Abstraction Layer）被划分为四部分： 1、 I/O驱动(I/O Drivers)

用于驱动模拟及数字I/O信号，如ADC, PWM，DIO

2、 通信驱动(Communication Drivers)

负责车辆各模块及整车通信，SPI、CAN等

3、 内存驱动(Memory Drivers)

控制设备芯片内存（如片内Flash、EEPROM）及外部映射设备（外置Flash）

4、 微处理器驱动(Microcontroller Drivers)

打开网易新闻 查看精彩图片

复杂驱动(Complex Device Drivers)通过对复杂传感器评估，利用中断、TPU、PCP等来实现实时性高的传感器采样、执行器控制等功能。

AUTOSAR架构对软件组织结构的统一，使得当底层硬件配置升级时不需要更改整个系统，有利于未来整车系统软件的更新，而目前各OEM都在着力研发的智能汽车、自动驾驶等技术都对现有的汽车架构提出了较高的要求，因而AUTOSAR的推广也成为了汽车电子行业的趋势。

末离借学习机会整理了这三篇关于AUTOSAR的文章，文中若有纰漏，恳请朋友们能指出，感谢，欢迎转载关注。

参考资料 《 AUTOSAR_TechnicalOverview.pdf》
《 AUTOSAR_LayeredSoftwareArchitecture.pdf》
《 AUTOSAR_SWS_VFB.pdf》
《 AUTOSAR_SoftwareComponentTemplate.pdf》
《 AUTOSAR_TechnicalOverview.pdf》
《 AUTOSAR_LayeredSoftwareArchitecture.pdf》
《AUTOSAR –An open standardized software architecture for the automotive industry》

打开网易新闻 查看精彩图片

若您读完有所得 这是一种鼓励

赞赏

人赞赏