>>>点我返回《AUTOSAR专栏》目录
前面讲了BSW的概述，这次就下面这张图进行更加详细的描述：
该层由以下模块/块组成：
1）微控制器驱动程序： 此模块具有内部驱动程序，用于访问MCU的内部外围设备（如看门狗，通用定时器），或具有直接访问MCU的功能（如CoreTest）。
2）内存驱动程序： 此模块具有用于访问内部闪存，内部EEPROM之类的片上存储器或外部Flash之类的存储器映射设备的驱动程序。
3）加密驱动程序： 此模块具有用于片上加密设备（例如SHE，HSM）的驱动程序。
4）无线通信驱动程序： 此模块具有用于无线网络系统（车内或车外通信）的驱动程序。
5）通讯驱动程序： 此模块具有用于板载通讯的驱动程序，如 SPI， I2C等，还具有用于车辆通讯的驱动程序，如 CAN， FlexRay。
6）I / O驱动程序： 此模块具有用于访问和使用MCU的I / O引脚的驱动程序，包括数字和模拟，如IO口、ADC、DAC、PWM。
该模块可用于在BSW堆栈中实现非标准功能。在很多情况下，当我们需要实现一些AUTOSAR不支持的功能时，就将CDD用于此类情况。或者，如果功能需要严格的时序约束（可能小于AUTOSAR OS分辨率的最小时序），则“复杂设备驱动程序”模块很有用，因为它可以直接帮助将MCU硬件驱动与应用程序APP连接。
但是复杂的驱动程序功能高度依赖于MCU和应用程序，因此代码可能不容易移植。
ECU抽象层有助于实现ECU硬件独立性（不仅MCU芯片具有硬件独立性，而且ECU板的不同外围设备也具有硬件独立性）。让我们看一下这一层中所包含的东西：
1）I / O硬件抽象：在现实的ECU中，I / O外设可以在芯片上或板上，并且ECU硬件布局（例如MCU引脚连接或引脚反转）可能很复杂。在传统的软件编写中，我们也必须考虑这些底层的细节，但是在AUTOSAR中则没有考虑。此模块从Application中抽象出此类底层的详细信息，并且仅提供用于使用I /O的API。这是独立于MCU的（因为它仅指向较低级别的驱动程序），但是与ECU硬件相关，因为它使用板载外围设备的外部驱动程序，如果更改，则其I/O硬件抽象也将发生变化。
2）通信硬件抽象：此模块抽象通信控制器的位置和ECU硬件布局。应用程序不知道使用哪个通信控制器（在CAN的情况下）或使用哪个引脚，甚至不知道使用哪种类型的通信总线（无论是CAN，FlexRay还是其他类型），它只是“了解”数据无论选择的通信控制器是片上还是板载，都可以发送和接收。此模块用于实现这种级别的硬件独立性。它提供了将由各个模块调用并执行数据发送或接收的API。
3）加密硬件抽象：此模块通过隐藏使用的加密信息（基于内部，外部设备或软件）来抽象加密功能。同样，上层也不知道所使用的加密类型，甚至不知道所使用的加密类型，例如是片上，板载还是软件编码。该模块提供了用于访问加密设备的机制。
4）内存硬件抽象：此模块还抽象出所用存储设备的位置。内存可以是片上或板载的，板载的内存可能具有不同的ECU硬件布局（如内存芯片的差异），但是所有这些信息都是从应用程序中抽象出来的，因为它仅了解数据并且无法控制要选择的存储设备类型。
5）板载设备抽象： 此模块提供特定于板载设备的ECU的抽象。该模块包含板载设备的驱动程序，这些驱动程序不能称为传感器或执行器，也不能称为内部或外部看门狗定时器之类的定时器。
>>>点我返回《AUTOSAR专栏》目录 扫描下方的二维码关注“汽车软件攻城狮”可第一时间获取更新！
