011 Autosar ECU中的基础软件（二）
最近心血来潮去了Autosar网站找了点资料看，可是关于Autosar的规范内容实在是带多了（几千页是至少的）！大圣也是新手，那我们就从技术概述开始慢慢看起吧。大圣将其技术概述浓缩了一下，时不时写几期连载给大家分享下。Autosar的核心思想是软件的重用性（整车所有ECU上）、软硬件分离（单个ECU上的高度抽象）。软硬件分离是标准化的必然，过去的软件与硬件在设计的时候具有高度的依赖性，往往导致当ECU硬件平台更换后，所有的软件模块不易，甚至不能porting，需要重新设计，造成大量的浪费。在未来，硬件的更新换代速度是越来越快，我们当然不可能也没有时间去一一更改那些我们已经设计好的模块（应用层软件）。所以Autosar的分层架构，使得我们只需更改少部分底层软件，就能实现模块无缝移植，这是ECU产商所希望得到的。
Autosar中的层次架构
说到Autosar就不得不说道下面这张图，展示的是一个完整的Autosar软件架构一般所具有的层次。包括以下六个：★应用软件层（Application Layer）★运行环境RTE(Runtime Environment)★服务层（Services Layer）★ECU抽象层（ECU Abstraction Layer）★微控制器抽象层（Microcontroller Abstraction Layer）★复杂驱动（Complex Device Drivers）
可以说除了橙色RTE以下的部分都可以归于Baisic SW，我们可以把Basic SW进行更高度的抽象，又具体分为服务层、ECU抽象层、微控制器抽象层、复杂驱动。也可以更具体的分化为以下模块：
（1）Service服务层
★系统服务：涵盖了所有层所需的的一些组件与功能比如实时操作系统，错误管理器等。★通信管理：总线通信CAN，LIN，FlexRay…，网络管理等。★内存管理：比如对NVRAM区的数据管理等。
（2）Microcontroller Abstraction控制器抽象
微控制器抽象层位于基础软件的最底层，里面包含着内部驱动，软件可以直接访问uC和内部设备。通过控制器抽象层MCAL（Microcontroller Abstraction Layer）来访问硬件，避免高层软件直接访问控制器的寄存器。MCAL是一种特殊的硬件层，为Basic SWC（Software component）提供标准接口。★通讯驱动：ECU内部通讯如SPI、车载通讯如CAN等。★I/O驱动：如数字/模拟驱动如ADC、PWM、DIO等。★内存管理：芯片内外的内存管理，如内外部flash。★控制器驱动：内部设备驱动如看门狗、定时器等。
微控制器抽象层
（3）ECU Abstraction ECU抽象
ECU抽象层与控制器抽象层直接相连并提供接口，同时也包含着外部设备的驱动。ECU抽象层提供了大量的API来访问内/外部设备与uC相连（pin 端口，接口种类）。例如ECU抽象层外部驱动通过调用控制器抽象层中的SPI驱动来进行通讯。
★I/O硬件抽象
I/O抽象是对I/O设备口的抽象集合，可以通过I/O抽象中的信号接口来访问不同的I/O设备（Ps：I/O抽象层不同于别的其他ECU抽象层的是它并没有连通service服务层，而是直接连接到RTE层。）
★通讯硬件抽象
通讯抽象对车上所用到的所有总线通讯方式都进行了封装与抽象定义（如CAN、LIN、MOST、FlexRay）。
★内存硬件抽象
对ECU内的存储设备进行了封装，比如对芯片内、外部的EEPROM设备都采用了相同的访问机制。
★车载设备抽象
该层包括那些不能被认为是传感器、执行器的其他设备。比如内、外部的看门狗，这些驱动可以经由控制器抽象层来访问ECU Onboard device。
（4）CDD复杂驱动
Autosar为了提高驱动的灵活性，提供了一种方法，可以直接由RTE操控底层硬件。一般来说这种驱动无法具体划分到哪个区，又与底层硬件息息相关。在不同平台的ECU上，这部分内容都得从新编写，无法直接移植。比如喷油控制、电磁阀控制、增量位置检测等。
参 考 资 料
-
Autosar technical overview
-
从软件构架看符合AUTOSAR标准的软件 Part 1 – 软件分层（小翼）
-
autosar layer.pdf
-
AUTOSAR架构不得不看的深度解析（末离）
未经许可禁止转载，氮素你可以分享到朋友圈