功能安全---AUTOSAR架构深度解析
AUTOSAR架构深度解析
本⽂转载于：
AUTOSAR的分层式设计，⽤于⽀持完整的软件和硬件模块的独⽴性(Independence)，中间RTE(Runtime Environment)作为虚拟功能总线VFB（Virtual Functional Bus）的实现，隔离了上层的应⽤软件层（Application Layer）与下层的基础软件（Basic Software），摆脱了以往ECU软件开发与验证时对硬件系统的依赖。
软硬件分离的分层设计，对于OEM及供应商来说，提⾼了系统的整合能⼒，尤其标准化交互接⼝以及软件组件模型的定义提⾼了各层的软件复⽤能⼒，从⽽降低了开发成本，使得系统集成与产品推出的速度极⼤提升。
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）进⾏通信
虚拟功能总线VFB及运⾏环境RTE
虚拟功能总线（VFB）是底层基础软件与⽹络拓扑结构的抽象，是AUTOSAR提供的所有通信机制的集合，在信息数据交互的过程中，应⽤程序被建模为组合组件。当系统进⾏配置时，软件组件就会被映射到指定ECU上，⽽同时组件间的虚拟连接也被映射到了CAN,
FlexRay，MOST等总线上。最后软件组件利⽤预先定义好的端⼝，通过VFB来实现通信。
运⾏环境RTE即是具体单个ECU上对VFB接⼝的实现，可以理解成是⾯向对象的编程语⾔中对象的创建。
各软件组件之间不允许直接进⾏通信，由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则可以映射为调⽤服务运⾏实体的语句。
基础软件层(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设备
flex软件对电流、电压、频率等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的推⼴也成为了汽车电⼦⾏业的趋势。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。