前面写了两篇关于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架构中共分六层：
应用软件层（Application Layer）
运行环境RTE(Runtime Environment)
服务层（Services Layer）
ECU抽象层（ECU Abstraction Layer）
微控制器抽象层（Microcontroller Abstraction Layer）
复杂驱动（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)
驱动如看门狗（Watchdog）、时钟模块（Clock Unit）并负责RAM测试及对微控制器抽象层内部设备和映射的微控制器抽象层外部设备的内存访问等功能。 
复杂驱动(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》 
若您读完有所得 这是一种鼓励
赞赏
人赞赏
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
