AUTOSAR_SWS_IOHardwareAbstraction

十月 21, 2024

AUTOSAR_SWS_IOHardwareAbstraction

简介和功能概述

本规范规定了 AUTOSAR 基础软件 I/O 硬件抽象的功能和配置。

I/O 硬件抽象是 ECU 抽象层的一部分。

I/O 硬件抽象不应被视为单个模块，因为它可以被实现为多个模块（可以存在多个 I/O 硬件抽象模块）。

本 I/O 硬件抽象规范并非旨在标准化此模块或模块组。

相反，它旨在作为它的（与其他模块关联的）功能接口的实现指南。

I/O 硬件抽象的目的是通过将 I/O 硬件抽象端口映射到 ECU 信号来提供对 MCAL 驱动程序的访问。

提供给软件组件的数据被完全从物理层的值中抽象出来。

因此，软件组件设计人员不再需要关于 MCAL 驱动程序 API 和物理层的值的单位的详细知识。

I/O 硬件抽象始终是特定于 ECU 的实现，因为软件组件对基础软件的要求必须适合某个 MCAL 实现的特性。

I/O 硬件抽象应提供初始化整个 I/O 硬件抽象的服务。

本文档的目的是：

当定义 I/O 硬件抽象时，确定软件组件模板的哪一部分应被使用。

解释定义通用端口的方式，在其中 ECU 信号被映射。

本文件的目的不是：

提供 C‑API。

为每个 ECU 信号提供特定的形式化，就像其在功能数据（车⾝域、动力系统、底盘域）的标准化中被完成那样。

首字母缩略词和缩写

本文件中使用的表述

ECU 信号属性

对其他模块的依赖

与 MCAL 驱动程序相关的接口

下图显示了 I/O 硬件抽象。它位于 MCAL 驱动程序之上。这意味着 I/O 硬件抽象将调用驱动程序的 API 来管理片上设备。

MCAL 驱动程序的配置取决于软件组件所需的 ECU 信号的质量。

例如，当引脚电平发生相关变化（上升沿、下降沿）时，可能需要发出通知。

系统设计人员必须配置 MCAL 驱动程序以允许针对给定信号发出通知。

通知由 MCAL 驱动程序生成，并在 I/O 硬件抽象中被处理。

请注意，I/O 硬件抽象并非旨在抽象 GPT 功能，而是使用它们来执行自己的功能。

之所以显示与 GPT 驱动程序相关的接口，是因为它是 MCAL 的一部分。

下图显示了所有与 MCAL 驱动程序相关的接口：

与 MCAL 驱动程序相关的接口的总结

[SWS_IoHwAb_00078]

[SRS_BSW_00384]

I/O 硬件抽象实现应提供可访问所有 MCAL 驱动程序的软件组件。

上表应按如下理解：

I/O 硬件抽象调用 ADC 驱动程序的 API。

I/O 硬件抽象接收来自 ADC 驱动程序的通知。

I/O 硬件抽象不会接收来自 DIO 驱动程序的通知。

所有 API 的完整列表请参见第 8.7.1 章。

与通信驱动程序相关的接口

[SWS_IoHwAb_00079]

[SRS_BSW_00384]

[SRS_IoHwAb_12242]

如果需要管理板载设备，I/O 硬件抽象的实现应为软件组件提供对通信驱动程序的访问权限（例如通过 SPI）。

下图显示了 I/O 硬件抽象，其中一些信号通过 SPI 处理程序/驱动程序来设置/接收。

根据分层软件架构（AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf）（ID03‑16）， I/O 硬件抽象包含专用驱动程序来管理外部设备，例如：

外部 ADC 驱动程序，通过 SPI 连接。

在 ASIC 设备上实现的外部 I/O 驱动程序，通过 SPI 连接。

与系统服务相关的接口

[SWS_IoHwAb_00044]

[SRS_BSW_00336]

[SRS_BSW_00384]

[SRS_BSW_00101]

I/O 硬件抽象的实现应提供与以下系统服务相关的接口：

ECU 状态管理器（初始化功能）

DET：默认错误追踪器

BSW 调度程序

与 DCM 相关的接口

I/O 硬件抽象应向 DCM 提供接口，用于软件组件的功能诊断。

DCM 将使用功能诊断来读取和控制已实现的 ECU 信号。提供给 DCM 的接口原型应位于头文件 IoHwAb_Dcm.h 内。

有关接口的详细信息，请参阅第 8.6 节。

文件结构

代码文件结构

[SWS_IoHwAb_00097]

[ ]

本规范内不得定义代码文件结构。

头文件结构

由于 I/O 硬件抽象可以有多个特定于项目的实例，因此无法指定文件结构。

[SWS_IoHwAb_00112]

[ ]

文件名应以“IoHwAb_<ComponentName>_<reference>”为前缀（其中字段 <reference> 可以是特定于实现的类别，字段 <ComponentName> 是原子软件组件的名称，即 I/O 硬件抽象的实例），以避免名称冲突。

需求可追溯性

功能规格

集成代码

I/O 硬件抽象作为 ECU 抽象的一部分，已被定义为集成代码。

背景与理由

根据 AUTOSAR 词汇表（AUTOSAR_TR_Glossary.pdf），集成代码是位于 AUTOSAR RTE 下方的 ECU 原理图相关软件。

集成代码实现的需求

I/O 硬件抽象的以下要求与硬件保护相关。

[SWS_IoHwAb_00038]

[SRS_IoHwAb_12248]

集成代码通常意味着该软件是为适应特定的 ECU 硬件布局而设计的。所有保护硬件的策略都应包含在该软件中。本文档不旨在对此类硬件保护标准化或提出建议。

硬件保护意味着当在某个输出上检测到故障（接地/电源短路、过热、过载⋯⋯）时，I/O 硬件抽象能够切断输出信号。

[SWS_IoHwAb_00039]

[SRS_IoHwAb_12451]

I/O 硬件抽象不应包含故障恢复策略。故障恢复操作只能由负责的软件组件决定。

I/O 硬件抽象的内部行为是特定于项目的，无法被标准化。I/O 硬件抽象不具备可扩展性。软件组件指定需要什么（信号质量），I/O 硬件抽象必须提供它。

ECU 信号概念

背景与理由

I/O 硬件抽象无法为 AUTOSAR 软件组件提供标准化 AUTOSAR 接口，因为其与上层的接口严重依赖于信号采集链。相反，I/O 硬件抽象提供了 AUTOSAR 接口。

这些 AUTOSAR 接口表示来自 ECU 输入/发送到 ECU 输出的电信号的抽象。或者，这些电信号也可能来自其他 ECU 或被发送到其他 ECU（例如通过 CAN 网络）。

端口是 AUTOSAR 组件的入口点。它们以 AUTOSAR 接口为代表。这些接口对应于“ECU 信号”。

ECU 信号的概念源于保证硬件平台互换性的需要。

对 ECU 信号的需求

I/O 硬件抽象处理直接连接到 ECU 的所有输入和输出（除了具有专用驱动程序的输入和输出，如 CAN，请参阅要求 [SWS_IoHwAb_00063]。

它包括所有输入和输出（直接映射到微控制器端口或板载外设）。

微控制器与外设（传感器和执行器以及由复杂驱动程序管理的外设除外）之间的所有通信均由 I/O 硬件抽象隐藏，同时考虑提供的接口。

ECU 通过输入/输出引脚以及网络与系统的其余部分相连。

网络不在本文档的讨论范围内。

[SWS_IoHwAb_00063]

[ ]

一个 ECU 信号代表一个电信号，这意味着至少一个输入或输出 ECU 引脚。

这一层的软件将抽象化 ECU 引脚。

从示波器上看，输入和输出只是电信号。

因此，本文档中定义的所有内容都与电信号这一概念有关。

这一概念的一个扩展是诊断（电气故障状态）。诊断在 ECU 连接器上不可见，而是由 I/O 硬件抽象提供的。

具有类似行为的电信号可能形成一个类。

因此，表示电信号的软件表示的 ECU 信号可能与一个特定于实现的类有关联。

属性

背景与理由

尽管每个 ECU 信号的大部分特性都是由软件组件定义的，但必须向每个信号添加一些属性才能提供软件组件所期望的信号质量。

对 ECU 信号属性要求

为了详细说明信号采集链，定义了一个属性列表来识别 ECU 信号的可配置特性。

过滤/防抖属性

[SWS_IoHwAb_00019]

[ ]

所有 ECU 信号都应具有过滤/去抖动属性，以便在传递给上层之前，可以对捕获的“原始”值进行过滤或去抖动。此属性仅适用于输入信号。它会影响对信号值的采集及访问的实现。

年龄属性

所有由 I/O 硬件抽象处理的 ECU 信号都依赖于 ECU 硬件设计。

这意味着设置 ECU 输出信号的时间和获取 ECU 输入信号的时间可能因 ECU 信号而异。

因此，为了保证所有类型的 ECU 信号（输入/输出）的模板行为，定义了一个通用的 Age 属性，并应为每个 ECU 信号配置该属性。

[SWS_IoHwAb_00021]

[ ]

所有 ECU 信号都应具有 Age 属性。根据 ECU 信号的方向（输入/输出），Age 属性有两个特定名称。无论如何，它始终包含最大时间值。以下描述解释了此属性对于每种 ECU 信号的含义。

ECU 输入信号：此属性的具体功能是限制信号的有效时间。该值定义此信号数据的最长有效时间。如果有效时间为 0，则必须立即从物理寄存器中检索信号。如果有效时间大于 0，则信号在指定的时间内有效。

ECU 输出信号：此属性的具体功能是限制信号输出的最大延迟。该值定义了实际设置该信号之前允许的最大时间。如果延迟为 0，则必须立即将信号设置到物理寄存器。如果延迟大于 0，则在配置的时间过去之前，可以设置信号。

I/O 硬件抽象和软件组件模板

关于本章的注释：本章引用了文献（AUTOSAR_TPS_SoftwareComponentTemplate.pdf）。本文档内部的变更可能会影响本章的内容。

背景与理由

这种方法允许定义标准化深度。如前所述，实现为集成代码。因此，本章仅总结如何将 I/O 硬件抽象定义为软件组件，并简要概述内部行为。内部行为描述主要涵盖 BSW 调度机制。

对软件组件模板使用的需求

[SWS_IoHwAb_00001]

[SRS_BSW_00423]

I/O 硬件抽象应基于文档（AUTOSAR_TPS_SoftwareComponentTemplate.pdf）中指定的软件组件模板。

与任何其他软件组件一样，I/O 硬件抽象可能会根据 ECU 的复杂性进行子结构化。

事实上，I/O 硬件抽象是一种经典的组件原型，它可以是原子的或组合的，并且提供和需要接口。

此外，I/O 硬件抽象只能通过其 PortPrototype 与 RTE 上方的其他软件组件进行交互。

不允许存在未通过 PortPrototype 表达的隐藏依赖关系。

然而，对于 I/O 硬件抽象接口来说，一边是带有准化接口的 MCAL 驱动程序，另一边是 RTE。因此，I/O 硬件抽象应尊重虚拟端口的概念。

[SWS_IoHwAb_00025]

[ ]

I/O 硬件抽象应作为 EcuAbstractionSwComponentType 的一个或多个实例来实现。

有关 EcuAbstractionSwComponentType 的更多信息，请参阅 AUTOSAR_TPS_SoftwareComponentTemplate.pdf。

EcuAbstractionSwComponentType 的实例提供了一组端口。

在 RTE 生成期间，只考虑与软件组件相连的端口。

本章概述了虚拟端口概念和应用于 I/O 硬件抽象需求的可运行实体。

本文档的后续章节将更详细地描述此处列出的要点。

端口概念和 I/O 硬件抽象

这是关于使用软件组件模板来定义 I/O 硬件抽象端口的建议概述。

本文档的后续章节将深入介绍 I/O 硬件抽象端口的使用。

不过，建议阅读软件组件模板文档（AUTOSAR_TPS_SoftwareComponentTemplate.pdf），以了解所有使用的术语和概念。

应通过使用 IoHwAbstractionServerAnnotation 来注释 I/O 硬件抽象组件的端口，以定义第 7.3 章中描述的属性（参见 AUTOSAR_TPS_SoftwareComponentTemplate.pdf）。

软件组件和可运行概念

软件组件具有实现其策略和内部行为的功能。这些部分使用可运行实体进行描述。前者被包含在可运行实体中，后者依赖于可运行实体的设计。可运行实体由原子软件组件提供，并且（至少间接地）是底层操作系统的调度对象。

原子软件组件的实现必须在其“内部行为”中为每个可运行实体提供代码入口点。有关更多信息，请参阅规范（AUTOSAR_TPS_SoftwareComponentTemplate.pdf）。

可运行实体是最小的代码片段，可以被独立激活。它们由原子软件组件提供，并由 RTE 激活。例如，可运行实体被设置为响应服务器上的数据交换或操作调用。

可运行实体有三种可能的状态：

暂停（Suspended）

启用（Enabled）

运行（Running）

在系统运行时，原子软件组件的每个可运行部分（作为操作系统任务的成员）处于这些状态之一。

要了解定义原子软件组件的每个可运行项的可用选项和属性，请参阅规范（AUTOSAR_TPS_SoftwareComponentTemplate.pdf）。

I/O 硬件抽象的调度概念

背景与理由

I/O 硬件抽象可能由多个 BSW 模块组成（例如板载设备驱动程序）。

每个 BSW 模块都可以提供 BSW 可运行实体（在 RTE 规范中也称为 BswModuleEntity（参见 AUTOSAR_SWS_RTE.pdf））。

相比之下，BswModuleEntity 相当于软件组件可运行实体，AUTOSAR 词汇表（AUTOSAR_TR_Glossary.pdf）对其给出了如下定义：“可运行实体是原子软件组件 (定义) 的一部分，它可以独立于对于它来说的其他可运行实体被执行和调度”。

这意味着 I/O 硬件抽象可以同时使用：

可运行实体调度

BSW 调度

可运行实体调度将处理可运行实体，并且是强制性的。与可运行实体调度不同，BSW 调度是可选的，并且必须手动完成与 BSW 调度程序相关的接口。

对于软件组件可运行实体，这些实体在 AUTOSAR OS 任务体中被调用。可运行实体在软件组件描述中被给出。软件组件可运行实体的激活很大程度上取决于 RTE 事件。

与软件组件通常由 RTE 事件激活一样，可调度的 BswModuleEntity 也可以由 BSW 事件激活。还有一种 BswModuleEntity 可以在中断上下文中被激活。这导致了两个子类：

BswSchedulableEntity

BswInterruptEntity

关于 I/O 硬件抽象调度概念的需求

由端口提供的接口的操作

从接口的角度描述的 I/O 硬件抽象实现了软件组件定义的端口接口的对应部分，也就是说，它提供了可运行实体，该实体实现了软件组件所需的提供端口（服务器端口、发送方/接收方端口）。

[SWS_IoHwAb_00068]

[ ]

I/O 硬件抽象的提供端口服务背后的实现是 ECU 特定的，并且应在软件组件描述中记录相应端口接口的映射。

获取操作

[SWS_IoHwAb_00069]

[ ]

对于与被配置为输入信号的端口接口关联的 ECU 信号，I/O 硬件抽象应提供 GET 操作，并且应可以自由地选择操作的短名称。

设置操作

[SWS_IoHwAb_00070]

[ ]

对于与被配置为输出信号的端口接口关联的 ECU 信号，I/O 硬件抽象应提供 SET 操作，并且应可以自由地选择操作的短名称。

通知和/或回调

[SWS_IoHwAb_00032]

[SRS_SPAL_12056]

I/O 硬件抽象应定义 BswInterruptEntity（与 BswSchedulableEntity 相反，是 BswModuleEntity 的子类）来实现通知和/或回调机制，以便在中断上下文中与 RTE 下方的其他模块交换数据。

I/O 硬件抽象可能包含一个或多个回调函数。可用的回调函数需要被连接到 MCAL 驱动程序的通知接口。因此，它们必须遵守 MCAL 驱动程序的原型定义（无传递参数，无返回参数）。

[SWS_IoHwAb_00033]

[SRS_BSW_00333]

[SRS_SPAL_12056]

实现时必须考虑到回调函数将在中断上下文中执行。

回调函数还可以提供触发 I/O 硬件抽象之外的软件组件的功能。

这些通知需要通过 RTE（发送方端口）处理。

[SWS_IoHwAb_00034]

[SRS_SPAL_12056]

可用回调函数的数量和执行顺序将取决于实现，并且必须在 I/O 硬件抽象 BSWMD 中记录。

[SWS_IoHwAb_00143]

[SRS_BSW_00440]

通过 RTE 路由的 I/O 硬件抽象的回调函数的函数原型应按照以下规则实现：StdReturnType Rte_Call_<p>_<o>(<parameters>)。

回调函数必须与 RTE 的 Rte_Call_<p>_<o> API 兼容，以实现类型安全的配置以及 AUTOSAR 服务和 IO 硬件抽象的实现。

主函数/作业处理函数

[SWS_IoHwAb_00035]

[SRS_BSW_00450]

I/O 硬件抽象可能包含一个或多个作业处理函数，这些函数是 BswSchedulableEntity（与 BswInterruptEntity 相反，是 BswModuleEntity 的子类，例如，每个设备驱动程序一个）。它们应根据用途被相应激活。

它们将由 BSW 调度程序按时间触发。它们可以与其他可运行实体的执行同步。

BswSchedulableEntity 的数量及其执行顺序将取决于实现，并且必须在 I/O 硬件抽象描述中被记录。

初始化、取消初始化和/或 Callout

[SWS_IoHwAb_00036]

[SRS_BSW_00336]

[SRS_BSW_00101]

I/O 硬件抽象应定义 BswModuleEntry 以便与在中断上下文之外以及在 RTE 之下的其他软件交换数据，例如在 BSW 初始化/取消初始化的情况下

这些 BswModuleEntry 将被链接到专用的 BswModuleEntity，它将被调用来执行服务/交换数据。

I/O 硬件抽象可能包含一个或多个初始化和取消初始化函数（例如，每个设备驱动程序一个）。与 MCAL 驱动程序类似，初始化函数应包含一个参数，以便能够将不同的配置传递给设备驱动程序。此函数应将 I/O 硬件抽象驱动程序使用的所有本地和全局变量初始化为初始状态。

[SWS_IoHwAb_00037]

[ ]

初始化/取消初始化函数应由 ECU 状态管理器专门使用/处理。有关更多信息，请参阅 AUTOSAR_SWS_ECUStateManager.pdf。可用函数的数量和执行顺序取决于实现，并且必须在 I/O 硬件抽象描述中记录。

I/O 硬件抽象调度示例

由 ADC 和 I/O 硬件抽象提供的接口

以下示例显示了 ADC 转换的调度示例。I/O 硬件抽象应提供两个 P 端口。本例中的软件组件接口是 af_pressure。

ECU 状态管理器能够触发 BswModuleEntry 来初始化 ADC 驱动程序（使用 Adc_ConfigType 结构调用 Adc_Init()）。

用例：软件组件需要 af_pressure 值。

RTE 触发专用 P‑Port 的 OP_GET 操作。

R1 是一个可运行实体，它允许调用适当的 ADC 驱动程序服务

ADC_EnableNotification

ADC_StartGroupConversion

转换结束时，ADC 在中断上下文中触发 BswModuleEntry R2。这是可能的，因为对此接口而言通知是允许的。ADC_NotificationGroup() 函数在 ADC 驱动程序中指定。

然后通过 RTEEvent 将通知“发送”到软件组件。

本示例的序列图在第 9 章中。

使用可运行实体和 BswSchedulableEntity 进行同步调度

以下示例显示了设置与 SMART 电源链接的灯的调度示例。

SMART 电源通过 SPI 总线连接到微控制器。因此，专用代码段使用 SPI 处理程序/驱动程序。

RTE 要设置的 FrontLeftLamp 值位于 I/O 硬件抽象缓冲区中。

到另一条 SMART 电源的输出线被同步设置，以通过 ADC 驱动程序触发相同电信号的 ADC 转换。

在转换结束时，转换结果可用，并且设置给模拟输入管理器的通知以将值存储在缓冲区内，可用于诊断目的。

在这个例子中，定期处理的实现是由 BswSchedulableEntity 完成的。

错误分类

开发错误

[SWS_IoHwAb_91001]

[ ]

扩展生产错误

I/O 硬件抽象层描述

背景与理由

I/O 硬件抽象层与软件组件有一些相似之处，尤其是在通过 RTE 进行通信的端口定义方面。主要区别在于 I/O 硬件抽象位于 RTE 之下（在 ECU 抽象层中）。I/O 硬件抽象是处于基础软件模块和应用软件之间的一种接口。

对于 I/O 硬件抽象以及服务，当前方法需要填写两个不同的模板。例如，为了在 AUTOSAR ECU 上集成 NVRAM 管理器，可以使用 BSWMD 来记录其对 BSW 调度程序、OS 资源等的需求。此外，还可以使用软件组件来描述 RTE 的端口。

I/O 硬件抽象是 BSW 的一部分。它可以被视为一组模块。尽管 I/O 硬件抽象是集成代码，但 I/O 硬件抽象的每个模块都可以适合 BSWDT。今天，众所周知，这一点在当前规范中没有得到充分记录。

然而，一致同意 ECU 信号将被映射到 VFB 端口（参见第 7.2 章和第 7.4 章）。此外，为了描述 I/O 硬件抽象实现和应用软件组件实现（RTE 之上）之间的接口，应该使用软件组件模板。

本章旨在总结在配置过程中定义端口、接口和所有其他软件组件类元素的所有建议。

需求

I/O 硬件抽象端口定义

[SWS_IoHwAb_00075]

[ ]

I/O 硬件抽象规范仅定义了端口使用的建议。端口的实例化应在配置过程中完成，并且特定于 ECU 电子设计。

I/O 硬件抽象建议为每个识别的 ECU 信号创建一个端口，但连接到 ECU 输出信号的 ECU 诊断信号除外。应创建此 ECU 信号与端口之间的关系。

例子：

ECU 有 10 个模拟输入引脚、15 个 PWM 输出引脚、15 个数字输出引脚。I/O 硬件抽象为每个 ECU 信号定义至少一个端口。在这个简单的示例中，端口被实例化了 40 次。

示例

示例 1：板载硬件用例

此示例源自电源供应 ECU。

ECU 具有大量数字输入 (DI)。

第一个主要类别是机械开关的“慢速 DI”。

第二个主要类别是用于诊断电源 IC 的“快速 DI” （此 DI 表示输出电流过高“过流”，这些 DI 不会从 ECU 物理引出）。

MCU 没有足够的 PIN 导致：

慢速 DI 连接到 8 位多路复用器（每个多路复用器有 3 条地址线和 1 条数据线）。

从发生“过流”到电源 IC 开关发生动作之间的最大时间为 1 毫秒。

OEM 的一项要求是开关的反应时间不得晚于 100 毫秒。

另一个 OEM 要求是每个 DI 必须通过 3/5 投票形式的去抖动。

但实践表明，去抖动类型并不重要，因为机械开关和电源 IC 不会产生干扰信号。

目前的解决方案是每 0.8 毫秒读取一次所有 DI（慢速和快速）（循环任务）

（慢速 DI 的扫描率可以降低，但额外任务的开销高于运行时间节省）

慢速 DI 的去抖动在每个循环中 1 次（因此去抖动值的最坏情况延迟为 3.2 毫秒）

如果检测到过流，该引脚将在同一循环中再次读取几次，并且电源 IC 将立即关闭。

该应用程序每 10 毫秒运行一次，并读取开关的去抖动 DI 和诊断信息。

AUTOSAR 架构上的分解：

示例 2：故障监控用例

在此示例中，应在 I/O 硬件抽象级别上使用诊断属性定义诊断输出信号。

因此，使用输入来执行输出的诊断。

当 I/O 硬件抽象要求定位一个输出（Dio_WriteChannel）时，将通过配置为输入的 ECU 引脚读取该通道。

ICU 驱动程序向 I/O 硬件抽象发送通知。保护策略位于集成代码中。软件组件可以通过端口使用诊断操作来获取诊断值。

示例 3：输出功率级别

ECU 硬件有一个功率级别 ASIC。

因此，在 RTE 之下所有 ECU 引脚都应作为 I/O 级别的“信号”被提供给硬件抽象。

一些输出通过 SPI 驱动程序/句柄进行控制。

一些输入直接通过 DIO 驱动程序控制。

一些电压、频率是通过 PWM 驱动程序设置的。

功率级别驱动程序提供所有输出的视图。它调用 PWM、DIO 驱动程序和 SPI 处理程序的服务。信号抽象使所有这些输出从软件组件的角度上来看是“可见”的（信号映射到端口上）。“功率级别驱动程序”是可以配置的。

诊断：

可以在功率级别层面检测到每个故障。诊断数据流通过 SPI 通信到达功率级别驱动程序。然后，通过 S/R 接口向所有软件组件提供诊断信息。

示例 4：低功耗状态下设置传感器和控制外设

ECU 通过其 ADC 和 DIO 外设来控制传感器。

在特定情况下，ECU 进入一种操作模式，在该模式下，传感器关闭，ADC 被设置为低功耗状态。

操作顺序如下：

应用程序电源模式管理器向 BswM 发出模式请求，以切换到“LowPowerMode”。

BswM 评估请求，如果所有先决条件都满足，则向电源模式管理器和传感器软件组件发出模式切换请求。

传感器软件组件停止读取传感器数据（即不再向硬件抽象请求任何获取操作）。

硬件抽象从 ADC 取消注册其通知并最终停止硬件周期性采集。

硬件抽象命令外部传感硬件进入低功耗模式或将其关闭。

硬件抽象调用其低功耗模式准备回调函数，然后调用其低功耗模式设置回调函数，如配置中所定义的，以实现与请求的应用程序低功耗模式“LowPowerMode”相关的 ADC（在本例中）电源状态。

通过引入更细粒度的模式请求，并对确认和/或切换做出反应，可以逐步控制该过程。

API 规范

导入的类型

本章列出了以下模块包含的所有类型：

[SWS_IoHwAb_91005]

[ ]

类型定义

IoHwAb<Init_Id>_ConfigType

[SWS_IoHwAb_00157]

[SRS_BSW_00414]

函数定义

这是为上层模块提供的函数列表。

I/O 硬件抽象注意事项：

如前几章所述，不会为 I/O 硬件抽象指定任何功能 API。

IoHwAb_Init<Init_Id>

[SWS_IoHwAb_00119]

[ ]

[SWS_IoHwAb_00158]

[SRS_BSW_00414]

配置指针 ConfigPtr 应始终具有 NULL_PTR 值。

配置指针 ConfigPtr 目前未被使用，因此应被设置为 NULL_PTR 值。

[SWS_IoHwAb_00059]

[SRS_BSW_00101]

此类函数要么初始化所有 I/O 硬件抽象软件，要么初始化部分 I/O 硬件抽象。

[SWS_IoHwAb_00060]

[SRS_BSW_00101]

由 I/O 硬件抽象软件管理的 I/O 设备的多样性应通过多个 init 函数进行处理。应为每个 init 函数标注 <Init_ID>。因此，其驱动程序被封装在 I/O 硬件抽象内部的外部设备，可以被单独初始化。

[SWS_IoHwAb_00061]

[SRS_BSW_00101]

此类初始化函数应由 ECU 状态管理器调用。ECU 集成器能够配置由 ECU 状态管理器调用的初始化序列的顺序。

[SWS_IoHwAb_00102]

[SRS_BSW_00441]

完成模块初始化后，I/O 硬件抽象状态应被设置为 IOHWAB_IDLE，作业结果应被设置为 IOHWAB_JOB_OK。

IoHwAb_GetVersionInfo

[SWS_IoHwAb_00120]

[ ]

回调通知

这是为下层模块提供的功能列表。

IoHwAb_AdcNotification<#groupID>

[SWS_IoHwAb_00121]

[ ]

[SWS_IoHwAb_00104]

[ ]

当组 <#groupID> 的组转换完成时，ADC 驱动程序将调用函数 IoHwAb_AdcNotification<#groupID>。

IoHwAb_PwmNotification<#channel>

[SWS_IoHwAb_00122]

[ ]

[SWS_IoHwAb_00105]

[ ]

当信号边沿出现在通道 <#channel> 上时，PWM 驱动程序将调用函数 IoHwAb_PwmNotification<#channel>。

IoHwAb_IcuNotification<#channel>

[SWS_IoHwAb_00123]

[ ]

[SWS_IoHwAb_00106]

[ ]

当信号边沿出现在通道 <#channel> 上时，ICU 驱动程序将调用函数
IoHwAb_IcuNotification<#channel>。

IoHwAb_GptNotification<#channel>

[SWS_IoHwAb_00124]

[ ]

[SWS_IoHwAb_00107]

[ ]

当通道 <#channel> 上的计时器值到期时，GPT 驱动程序将调用函数
IoHwAb_GptNotification<#channel>。

IoHwAb_OcuNotification<#channel>

[SWS_IoHwAb_00155]

[ ]

[SWS_IoHwAb_00156]

[ ]

当计数器的当前值与通道 <#channel> 上的阈值匹配时，OCU 驱动程
序将调用函数 IoHwAb_OcuNotification<#channel>。

IoHwAb_Pwm_NotifyReadyForPowerState<#MODE>

[SWS_IoHwAb_91002]

[ ]

如果 PWM 驱动程序被配置为支持异步模式下的电源状态控制，则需要 CDD 或 IoHwAbs 提供此接口。

IoHwAb_Adc_NotifyReadyForPowerState<#MODE>

[SWS_IoHwAb_00154]

[ ]

如果 ADC 驱动程序被配置为支持异步模式下的电源状态控制，则需要 CDD 或 IoHwAbs 提供的此接口。

调度函数

这些函数由基础软件调度程序直接调用。以下函数应无返回值且无参数。所有函数均为不可重入。

<调度函数的名称>

功能诊断接口

本章描述了 I/O 硬件抽象向 DCM 模块提供的接口，以实现“软件组件的功能诊断”。

“软件组件的功能诊断”意味着通过提供的接口，DCM 模块能够控制和读取每个被实现的 ECU 信号。

IoHwAb_Dcm_<EcuSignalName>

[SWS_IoHwAb_00135]

[SRS_IoHwAb_00002]

[SWS_IoHwAb_00136]

[SRS_IoHwAb_00002]

此功能允许控制相关的 ECU 信号，即 ECU 信号可以被锁定、解锁和调整为某个值。

[SWS_IoHwAb_00138]

[SRS_IoHwAb_00002]

此功能应在编译前可被配置为开/关。

锁定信号意味着对于软件组件来说特定信号被软件锁定，即软件组件的请求在锁定状态下对硬件没有影响。如果使用“客户端/服务器”通信来输入信号，则可能需要一个硬件抽象内部缓冲区，缓冲区的值可以由 DCM 调整。

IoHwAb_Dcm_Read<EcuSignalName>

[SWS_IoHwAb_00139]

[SRS_IoHwAb_00002]

[SWS_IoHwAb_00140]

[SRS_IoHwAb_00002]

此功能为 DCM 模块提供对某个 ECU 信号的读取访问权。读取访问与 ECU 信号的当前状态（锁定/解锁）无关，并且应始终从硬件读取当前物理值。

[SWS_IoHwAb_00142]

[SRS_IoHwAb_00002]

此功能应在编译前可被配置为开/关。

电源状态函数

IoHwAb_PreparePowerState<#MODE>

[SWS_IoHwAb_00146]

[ ]

[SWS_IoHwAb_00149]

[ ]

此 API 是可配置的回调，应为要管理的每种电源模式的每种配置定义一次。

[SWS_IoHwAb_00150]

[ ]

此调用应在硬件抽象软件组件上下文中执行，这意味着它具有对 MCAL 的完全访问权限。

许多外设的电源状态转换请求可与由此回调实现的给定电源模式转换相关联，以及与使外设进入目标电源状态所需的任何其他操作（在此情况下可解决外设之间的交叉依赖）相关联。

IoHwAb_ EnterPowerState<#MODE>

[SWS_IoHwAb_00147]

[ ]

[SWS_IoHwAb_00151]

[ ]

此 API 是可配置的回调，应为要管理的每种电源模式的每种配置定义一次。

[SWS_IoHwAb_00152]

[ ]

此调用应在硬件抽象软件组件上下文中执行，这意味着它具有对 MCAL 的完全访问权限。

[SWS_IoHwAb_00153]

此 API 执行由前面调用准备的所有与 IoHwAb_PreparePowerState<#MODE> 对应的电源状态转换。

预期接口

本章列出了所有需要其他模块提供的接口。

强制接口

I/O 硬件抽象没有强制接口。I/O 硬件抽象使用哪些接口取决于软件组件定义的通道的预期功能。

使用所有 MCAL 驱动程序 API 的 I/O 硬件抽象示例：

请注意，<module_name>_Init 和 <module_name>_DeInit 函数未在下面列出。

初始化序列由 ECU 状态管理器调用，而不是由 I/O 硬件抽象调用。

<module_name>_GetVersionInfo 函数也未在此列出。

本表根据以下文件建立

Driver ADC

AUTOSAR_SWS_ADCDriver.pdf

Driver DIO

AUTOSAR_SWS_DIODriver.pdf

Driver ICU

AUTOSAR_SWS_ICUDriver.pdf

Driver PWM

AUTOSAR_SWS_PWMDriver.pdf

Driver PORT

AUTOSAR_SWS_PORTDriver.pdf

Driver GPT

AUTOSAR_SWS_GPTDriver.pdf

Driver SPI

AUTOSAR_SWS_SPIHandlerDriver.pdf

Driver OCU

AUTOSAR_SWS_OCUDriver.pdf

[SWS_IoHwAb_91003]

[ ]

可选接口

本章定义了实现 I/O 硬件抽象的可选功能所需的所有接口。

[SWS_IoHwAb_91004]

[ ]

序列图

I/O 硬件抽象提供的 ECU 信号（示例）

该序列图解释了第 7.5.2.5 章的示例。

在这个例子中，传感器/执行器组件是客户端，I/O 硬件抽象是服务器。

传感器/执行器组件请求 AUTOSAR 信号 af_pressure 的新值，该信号是 I/O 硬件抽象级别的 ECU 信号。

ADC 转换完成后，来自 MCAL 驱动程序的通知将被转换为提供给传感器/执行器组件的 RTE 事件。然后，它可以同步读取 af_pressure 信号缓冲区中的值。

注意：

API IoHwAb_GetVoltage(af_pressure) 和 IoHwAb_ReadVoltage(af_pressure, &buffer) 不是指定的接口，且仅供此示例使用。

此示例中的图表旨在显示可运行对象，并不旨在显示服务器端口到可运行对象的映射。

根据应用程序低功耗模式请求在低功耗状态中设置 ADC 和 PWM（示例）

图 9‑2 中的序列图指的是电源状态转换，其中外设被配置为异步电源状态转换。

收到准备电源状态的请求后，外设驱动程序向调用者（在本例中为硬件抽象）发出通知，告知对方自己已准备好转换到新的电源状态。

下面的序列图显示了一个同步转换（只要准备 API 返回，外设就立即准备转换）：