全部学习汇总： https://github.com/GreyZhang/hack_autosar
继续梳理《AUTOSAR_EXP_VFB》。
与硬件的交互
简介
这一部分的目标是关注应用软件组件和硬件之间通过虚拟功能总线的标准化交互。硬件交互意味着访问以下三种硬件（另请参见图 6.1）：
- 微控制器外围设
- ECU 电子设备
- 传感器和执行器
执行器和传感器硬件通常需要专门的软件来提供与应用软件的接口。该接口通常包括读取传感器值的软件接口、设置执行器的功能、诊断接口等。集成商需要灵活地将其系统的传感器和执行器连接到他选择的合适的 ECU。
在某些情况下，甚至需要 ECU 上的专用硬件，并且无法通过标准化的基本软件与该硬件进行交互。 在这些情况下，可以使用复杂的驱动程序与此特定硬件进行交互。 复杂的驱动程序是特定于供应商的。
图中显示了从物理信号到软件信号（例如车速）和返回（例如车灯）的典型转换过程。 采用这种接口架构有两个原因：
最佳重用潜力（当满足所有其他集成要求，如性能要求时）：
- 如果 µC 发生变化，则可以重用 ECU 抽象、传感器执行器软件组件和应用程序软件组件。
- 如果 ECU 发生变化，可以重用传感器执行器软件组件和应用软件组件。
- 如果传感器或执行器发生变化，仍然可以重用应用软件组件。
可以由不同的专家和/或公司开发各种模块（μC、ECU、传感器/执行器、应用）。
这个图算是我看了这么多文档看到的第一个框架设计的例子，在这个图中，包括了输入以及输出两个路径。
微控制器抽象层 (MCAL)
对硬件的访问通过微控制器抽象层 (MCAL) 进行路由，以避免从更高级别的软件直接访问微控制器寄存器。
MCAL是硬件特定层，可确保基本软件组件的标准接口。它管理微控制器外设，并为基本软件的组件提供独立于微控制器的值。 MCAL实施通知机制以支持向不同进程分发命令、响应和信息。
其中包括：
数字输入/输出
模拟/数字转换器
PWM
EEPROM
FLASH
ICU
看门狗定时器
串行外设接口
I²C总线（这个也是MCAL中定义的？）
每个标准微控制器都提供 MCAL。
ECU抽象
ECU 抽象为任何特定 ECU 的电气值（或许可以理解为物理值？）提供了一个软件接口，以便将高级软件与所有底层硬件依赖性分离。
上图显示了 ECU 抽象的典型示例。 在这种情况下，服务“ECU_Set_I”在 ECU 上以 3 种不同的方式提供，但 SW 接口始终相同。
传感器执行器软件组件
传感器执行器软件组件是一种原子软件组件，它使传感器或执行器的功能可用于其他软件组件。这意味着传感器执行器软件组件为应用软件组件提供了传感器和执行器物理值的接口。传感器执行器软件组件是为具体的传感器或执行器编写的，并使用 ECU 抽象接口。
复杂驱动程序组件
复杂驱动程序 (CDD) 允许直接访问硬件，特别是对于资源关键型应用程序。
复杂驱动程序是一个松散耦合的容器，可以在其中放置特定的软件实现。对软件部分的唯一要求是必须根据 AUTOSAR 端口和接口规范实现与 AUTOSAR层面的接口。
复杂驱动程序的主要任务是通过使用特定中断和/或复杂 μC 外设（如 PCP、TPU）直接访问 μC 来实现复杂的传感器评估和执行器控制，例如：
喷射控制
电动阀控制
增量位置检测
此外，复杂驱动程序将用于为 AUTOSAR 不支持的硬件实现驱动程序。
例如，如果将引入新的通信系统，则通常没有 AUTOSAR 驱动程序可用于控制通信控制器。为了通过该介质实现通信，驱动程序将在复杂驱动程序中专有实现。在通过该介质的通信请求的情况下，通信服务将调用复杂驱动程序而不是通信硬件抽象来进行通信。
需要非标准驱动程序的另一个示例是支持实现非标准化功能的 ASIC。
最后，复杂驱动程序在某种程度上旨在作为迁移机制。由于在复杂驱动程序中可以直接访问硬件，因此现有应用程序可以定义为复杂驱动程序。如果根据 AUTOSAR 标准定义扩展接口，则可以根据 AUTOSAR 标准实现新的扩展，这不会强制 OEM 或供应商重新设计所有现有应用程序。
看过的这部分资料里面，这一段算是最熟悉的了。几个不同的软件层，分别用来实现什么功能，软件之间的依赖关系等。理解上没有什么大的问题，在实施上，需要增补的只是还有太多。