72 KiB
AUTOSAR 标准错误说明
AUTOSAR CP Release 4.4.0
原文：Description of the AUTOSAR standard errors（文档 ID 377）
翻译状态：已完成 v1（封面+变更历史+TOC+Ch 1-6 主体）
对应原文 PDF：
BSWGeneral/AUTOSAR_EXP_ErrorDescription.pdf
文档标识
| 字段 | 值 |
|---|---|
| 文档标题 | AUTOSAR 标准错误说明（Description of the AUTOSAR standard errors） |
| 文档标识号 | 377 |
| 文档所有者 | AUTOSAR |
| 文档责任方 | AUTOSAR |
| 文档状态 | 正式版（Final） |
| 所属 AUTOSAR 标准 | Classic Platform |
| 所属标准版本 | 4.4.0 |
原文头部包含版权声明（Disclaimer）段落，已按规范要求略去，仅在此处说明。原文标题为 "Description of the AUTOSAR standard errors"。
文档变更历史
| 日期 | 版本 | 变更人 | 变更说明 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性修订 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 移除了对过时需求的引用；更新了通信错误报告流程 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 编辑性修订 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 编辑性修订 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 编辑性修订 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 移除了对过时通信栈类型的引用 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 根据 AUTOSAR 术语表变更进行了适配 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 初始发布 |
目录
1 目的
本文档的目的在于：
- 给出不限于某个特定模块的 BSW 异常行为概述
- 澄清错误处理机制，以保证任何 BSW 实现具有相同行为，并允许更安全地交换模块
- 列出为应用软件提供的 BSW 机制，并指出需要补充的不足
- 从安全分析的角度，给出不同机制在检测和恢复方面的失效模式覆盖
本文档面向 BSW 模块的开发者和应用/SW-C 开发者。
本文档描述了 AUTOSAR 基础软件所处理的所有现有错误，以及根据 FDIR 流程（Fault，Detection，Isolation and Recovery，故障、检测、隔离与恢复），架构对这些错误的反应方式。
本文档还描述了每个错误处理机制的已识别失效模式覆盖范围。失效模式被假定为与硬件相关的随机失效。用于检测这些硬件故障的 SW 机制也可能检测到 SW（设计）缺陷。这些机制被映射到失效模式列表上，并根据机制在检测和恢复方面的效果进行评估。
限制
目前，本文档的范围限于 CAN 通信栈和内存栈。
本文档仅是描述性的，不包含需求。基础软件模块的功能和需求在规范文档中规定。
本文档仅描述 AUTOSAR 架构中包含的标准错误。根据特定的实现和/或特定的硬件属性，可以添加特定的错误。
2 与其他文档的关系
本文档与 AUTOSAR 内发布的众多其他文档存在关联。本文的目的不是替代任何这些其他文档，而是给出 BSW 中错误处理的完整视图。因此，本文与其他文档存在显著的内容重叠。请注意，本文档仅是描述性的，不包含需求。
3 文档导读
以下是后续章节内容的概述：
- 第 4 章：通用机制（Generic mechanisms） 本章描述通用的错误处理机制。
- 第 5 章：通信相关错误（Communication related errors）
- 5.1 节：概述。本节概述了通信栈中现有的错误处理机制。它还描述了每种机制到已识别失效模式的映射。
- 5.X 节：这些章节精确描述了 AUTOSAR 架构对通信栈中每种错误的行为。
- 第 6 章：内存相关错误（Memory related errors）
- 6.1 节：概述。本节概述了内存栈中现有的错误处理机制。它还描述了每种机制到已识别失效模式的映射。
- 6.X 节：这些章节精确描述了 AUTOSAR 架构对内存栈中每种错误的行为。
对于每种错误，一张图呈现了该错误的信息流摘要，并指示了错误检测、缓解或恢复的位置。同时，对于每个模块，一张表详细说明了关于错误处理的具体项目：
| 项目 | 描述 |
|---|---|
| 检测（Detection） | 描述模块如何检测此错误情况或被通知此错误情况 |
| 反应（Reaction） | 指示模块的内部反应（如内部状态变化） |
| 报告（Report） | 指示错误如何通知给栈中的其他模块或 AUTOSAR 基础设施 |
| 恢复（Recovery） | 指示错误如何/是否被模块恢复或缓解 |
4 通用机制
本节描述通用机制，它们涉及本文档中提到的不同错误的错误处理策略。这些机制不会在第 5 章和第 6 章的错误描述中再次描述。
4.1 上报到诊断事件管理器（DEM）
4.1.1 概述
图 1：上报到 DEM 的错误的信息路径
（信息流示意图：BSW 或 SWC 检测错误 → 报告给 DET 或直接报告给 DEM → DEM 上报给 FIM/SWC → 触发恢复动作）
4.1.2 模块的角色
4.1.2.1 报告错误的模块（其他 BSW 或 SWC）
| 项目 | 内容 |
|---|---|
| 检测 | 取决于 SWC 或 BSW 模块 |
| 反应 | 取决于 SWC 或 BSW 模块 |
| 报告 | - BSW 通过 Dem_SetEventStatus API 或 Det_ReportRuntimeError API 或 Det_ReportTransientFault API 报告事件的新状态- SWC 通过 Dem_SetEventStatus API（通过 RTE）报告事件的新状态 |
| 恢复 | 实现特定 |
4.1.2.2 诊断事件管理器（DEM）
| 项目 | 内容 |
|---|---|
| 检测 | - 当错误发生（DEM_EVENT_STATUS_FAILED 或 DEM_EVENT_STATUS_PREFAILED）或恢复（DEM_EVENT_STATUS_PASSED 或 DEM_EVENT_STATUS_PREPASSED）时，DEM 由 BSW 通过 Dem_SetEventStatus API 通知- 当错误发生或恢复时，DEM 由 SWC 通过 Dem_SetEventStatus API 通知 |
| 反应 | [SWS_Dem_00184] 事件状态的存储；[SWS_Dem_00190] FreezeFrame 的处理 |
| 报告 | - [SWS_Dem_00016] 根据 DEM 配置，它可以通知 FIM（[SWS_Dem_00029]）和/或通过 CallbackEventStatusChange DEM 客户端-服务器接口的 EventStatusChanged 操作通知 SWC（连接到可配置接口 EventStatusChanged [DEM285] 或 DTCStatusChanged [SWS_Dem_00284] 函数）- SWC 可以轮询 DEM 以获取事件的状态（ DiagnosticMonitor 客户端-服务器接口的 GetEventStatus 操作，连接到 Dem_GetEventStatus 函数 [SWS_Dem_00195]） |
| 恢复 | DEM 具备一些：- [DEM127] 治愈能力（针对 BSW 通过定义的治愈周期，或针对 SWC 通过监视功能）- [DEM004] 去抖动能力 |
4.1.2.3 DET
DET（Default Error Tracer，默认错误跟踪器）通过集成商特定代码提供对 DEM 和 RTE（SW-C）的访问。运行时错误（通过调用 Det_ReportRuntimeError API 发出信号）或瞬态故障（通过调用 Det_ReportTransientFault API 发出信号）的发生触发相应错误处理程序的执行，该错误处理程序可以作为特定 ECU 集成商在 Det 中实现的callout，且仅可包括：
- 将相应的错误事件存储到内存
- 调用 Dem 模块
- 执行短且合理的动作
4.1.2.4 功能抑制管理器（FIM）
| 项目 | 内容 |
|---|---|
| 检测 | 存在不同的检测机制：- 通过访问 DEM 信息（通过 Dem_GetEventStatus 轮询与请求的 FID 关联的事件 [SWS_Fim_00072]，或在启动时转储事件状态 [SWS_Fim_00018]）- [SWS_Fim_00021] 由 DEM 通过 Fim_DemTriggerOnEventStatus callout 通知 |
| 反应 | 根据实现，在 DEM 报告状态变化时存储事件状态 |
| 报告 | FIM 可被 SWC 通过 Fim_GetFunctionPermission [SWS_Fim_00011] 轮询。它不通知 SWC |
| 恢复 | — |
4.1.2.5 RTE
RTE 为 SWC 提供对 DEM 和 FIM 操作的访问。当需要 SWC 的信息或必须通知 SWC 时，它执行与 DEM 监视器（DEM 回调）关联的 runnables。
RTE 不为 DEM 提供特定功能。
4.1.2.6 通知到 SWC
| 项目 | 内容 |
|---|---|
| 检测 | 由 FIM 或 DEM（通过 RTE）通知 |
| 反应 | N/A |
| 报告 | N/A |
| 恢复 | N/A |
5 通信相关错误
5.1 概述
5.1.1 错误处理机制
图 2：CAN 错误处理机制概述
（架构示意图：CAN 错误处理机制涵盖以下模块：CAN Driver、CAN Interface（CanIf）、CAN State Manager（CanSM）、AUTOSAR COM、CAN NM、CAN TP、PDU Router、ComM、BswM、Dem、Det 等）
5.1.2 CAN 栈错误列表
表 1：CAN 栈错误列表
| 错误 | 描述 | 检测模块 | DEM/DET（运行时）错误（报告者以粗体显示） | 具有 BSW 恢复动作的缓解器 |
|---|---|---|---|---|
| 驱动层错误 | ||||
| CAN Bus Off | 一个 CAN 网络上的总线关闭错误 | CAN | CANSM_E_BUS_OFF¹ | CanSM：→ Bus Off Recovery 状态机 |
| CAN Controller Hardware Timeout | 与 CAN 控制器的通信超时 | CanSM | CANSM_E_MODE_REQUEST_TIMEOUT | CanSM：→ Timeout Recovery 状态机 |
| 信号错误 | ||||
| CAN Transmission buffer full | 因为传输队列已满，无法传输新消息 | CanIf | 未报告到 DEM 报告到 CANIF 报告到 SWC |
NONE（间接地，TX 截止时间监控） |
| CAN Reception DLC error | 接收到 DLC 意外的 CAN 帧（启用了 DLC 检查） | CanIf | CANIF_E_INVALID_DATA_LENGTH | NONE（间接地，RX 截止时间监控） |
| COM RX Deadline Monitoring | 预期消息未在时间内被 COM 接收 | AUTOSAR COM | 未报告到 DEM 报告到 SWC |
AUTOSAR COM/SW-C |
| COM TX Deadline Monitoring | 在等待传输确认时超时 | AUTOSAR COM | 未报告到 DEM 报告到 SWC |
SW-C |
| CAN Transport Protocol error during transmission | CAN TP 消息传输期间超时 | CanTp | CANTP_E_COM | 用户，DCM |
| CAN Transport Protocol error during reception | CAN TP 消息接收期间超时 | CanTp | CANTP_E_COM | 用户，DCM |
| CANNM TX Deadline Monitoring | NM 消息传输错误 | CanNm | 未报告到 DEM | CanNM/SW-C |
| PDU replication error | 复制的 PDU 在所有副本中不相同 | AUTOSAR COM | 未报告到 DEM | AUTOSAR COM |
| PDU counter error | PDU 计数器与预期计数器不同 | AUTOSAR COM | 未报告到 DEM | AUTOSAR COM |
| Client/Server timeout | 客户端/服务器操作中的超时 | AUTOSAR COM/RTE | 未报告到 DEM | SW-C |
¹
CANSM_E_BUS_OFF不是 DEM 事件的名称（由 DEM 配置生成）。它是一个 CanSM 配置元素，允许为每个 CAN 网络定义不同的 DEM 事件。² 为每个错过的截止时间引发 DEM 事件可能影响太大，并且该事件不允许识别失败的部分。有关 AUTOSAR 中 COM 超时处理的详细信息，请参见 5.3.3 节 COM RX 截止时间监控和 5.3.4 节 COM TX 截止时间监控。
5.1.3 EH 机制到硬件失效模式的映射
以下通信硬件失效模式已被考虑：
表 2：通信硬件失效模式
| ID | 简称 | 描述 |
|---|---|---|
| CH01 | 永久丢失一个 CAN 帧 ID 类型 | 在接收或传输期间，特定 ID 的所有 CAN 帧都丢失 |
| CH02 | 临时丢失一个 CAN 帧 | 在接收或传输期间，一个 CAN 帧临时丢失 |
| CH03 | 一个重复的 CAN 帧 | 一个 CAN 帧（具有相同 ID 和内容）在 CAN 总线上被意外地重复一次或多次。非洪水总线 |
| CH04 | 一个伪 CAN 帧 | 一个具有可信内容的 CAN 帧被意外传输（并因此被接收） |
| CH05 | CAN 帧乱序 | 发送 CAN 帧的顺序与接收到的顺序不同 |
| CH06 | 一个损坏的 CAN 帧 | 一个 CAN 帧的内容被损坏 |
| CH07 | 一个延迟的 CAN 帧 | 一个预期的 CAN 帧传输比预期传输延迟 |
| CH08 | CAN 总线阻塞 | 所有用户的 CAN 通信丢失 |
| CH09 | CAN 总线洪泛 | 连续不断地在 CAN 总线上传输 CAN 帧 |
| CH10 | 错误路由 | CAN 帧被错误的目标接收或从错误的源接收 |
| CH11 | 永久丢失一个 CAN 用户（ECU） | 一个 CAN 用户既不能发送也不能接收 |
表 3：检测和恢复机制到 CAN 失效模式的映射
下表显示了与每个失效模式（以下简称 FM）相关的错误处理机制以及机制效率的定性估计。定性度量定义如下：
- A_D – 对所考虑 FM 的检测具有完全覆盖
- A_R – 对所考虑 FM 的恢复具有完全覆盖
- P_D – 对所考虑 FM 的检测具有部分覆盖
- P_R – 对所考虑 FM 的恢复具有部分覆盖
| ID | 描述 | Bus Off | 控制器硬件超时 | 传输缓冲区满 | 接收 DLC 错误 | 接收截止时间监控 | 传输截止时间监控 | PDU 复制监控 | PDU 计数器 |
|---|---|---|---|---|---|---|---|---|---|
| CH01 | 永久丢失一个 CAN 帧 ID 类型 | P_D / A_R | A_D / P_R | ||||||
| CH02 | 临时丢失一个 CAN 帧 | P_D / A_R | A_D / P_R | A_D | |||||
| CH03 | 一个重复的 CAN 帧 | A_D / A_R | A_D / A_R | ||||||
| CH04 | 一个伪 CAN 帧 | P_D / A_R | A_D / A_R | P_D / A_R | |||||
| CH05 | CAN 帧乱序 | A_D / P_R | A_D / P_R | ||||||
| CH06 | 一个损坏的 CAN 帧 | P_D | A_D / A_R | P_D / A_R | |||||
| CH07 | 一个延迟的 CAN 帧 | A_D / P_R | A_D / A_R | ||||||
| CH08 | CAN 总线阻塞 | A_D / P_R | A_D / A_R | A_D / P_R | |||||
| CH09 | CAN 总线洪泛 | P_D / P_R | P_D / P_R | ||||||
| CH10 | 错误路由 | P_D / P_R | P_D / P_R | A_D / P_R | P_D / P_R | ||||
| CH11 | 永久丢失一个 CAN 用户（ECU） | A_D / P_R | A_D / P_R |
5.2 通信信道丢失
5.2.1 CAN Bus Off
5.2.1.1 概述
图 3：CAN Bus Off 错误的信息路径
（信息流示意图：检测（CAN Driver/外部 CAN Controller）→ 报告（CanIf）→ 通知（CanSM）→ 缓解（ComM, BswM）→ 恢复（CanSM：控制器复位、Tx 路径启用/禁用））
注意：AUTOSAR COM 模块（或其他模块如 CanNm 或 CanTp）将间接对 Bus Off 做出反应，原因是通信信道的丢失，但它不知道具体的错误类型。因此，这些模块在本节中不予考虑。
5.2.1.2 模块的角色
5.2.1.2.1 CAN 控制器（外设）
| 项目 | 内容 |
|---|---|
| 检测 | 取决于硬件 |
| 反应 | [SWS_Can_00274] CAN 控制器的任何 Bus Off 恢复应被禁用 |
| 报告 | 取决于 CAN 驱动配置：- 将错误记录在寄存器中 - 如果配置了中断，报告错误给 CAN 驱动 |
| 恢复 | 参见 CAN State Manager。[SWS_Can_00274] CAN 控制器的任何 Bus Off 恢复应被禁用 |
5.2.1.2.2 CAN 驱动
| 项目 | 内容 |
|---|---|
| 检测 | [SWS_Can_00020]、[SWS_Can_00099]。取决于 CAN 驱动配置：- [SWS_Can_00109] 轮询 CAN 控制器寄存器- 由中断激活 |
| 反应 | [SWS_Can_00272] 驱动过渡到 CANIF_CS_STOPPED；[SWS_Can_00273] 尝试取消待处理的消息 |
| 报告 | [SWS_Can_00020] 错误通过 CanIf_ControllerBusOff(controller) API 报告给 CAN Interface |
| 恢复 | 参见 CAN State Manager |
5.2.1.2.3 CAN Interface
| 项目 | 内容 |
|---|---|
| 检测 | 由 CanIf_ControllerBusOff(controller) 通知（参见上面的 CAN Driver） |
| 反应 | [SWS_CanIf_00298] 控制器操作模式设置为 CANIF_CS_STOPPED |
| 报告 | 错误通过 CanSm_ControllerBusOff(controller) 报告给 CAN State Manager |
| 恢复 | 由 CAN State Manager 触发恢复：- CanIf_SetControllerMode(Controller, CANIF_CS_STARTED)- Can_InitController(Controller, *Config)- Can_SetControllerMode(Controller, CAN_T_STARTED) |
5.2.1.2.4 CAN State Manager
| 项目 | 内容 |
|---|---|
| 检测 | 由 CanSm_ControllerBusOff(controller) 通知（参见上面的 CAN Interface） |
| 反应 | - 计数 Bus Off 事件 - 启动错误恢复机制 |
| 报告 | - [SWS_CanSM_00605] [SWS_CanSM_00498] [SWS_CanSM_00522] 如果错误得到确认，则报告给 DEM。如果恢复成功，事件从 DEM 中清除。[ECUC_CanSM_00070] 此错误的 DEM 事件在 CANSM_E_BUS_OFF 配置中按 CAN 网络配置- [SWS_CanSM_00521] CanSM 通过 ComM_BusSM_ModeIndication 通知 ComM 通信状态（COMM_SILENT_COMMUNICATION）- [SWS_CanSM_00508] CanSM 通过 BswM_CanSM_CurrentState 通知 BswM Bus Off 事件 |
| 恢复 | [SWS_CanSM_00509] CAN State Manager 控制错误恢复机制，其中包括：- 复位 CAN 控制器：CanIf_SetControllerMode(..., CANSM_CS_STARTED)- 禁用/启用发送路径： CanIf_SetPduMode(..., CANIF_SET_TX_OFFLINE / CANIF_SET_TX_ONLINE) |
5.2.1.2.5 Communication Manager
| 项目 | 内容 |
|---|---|
| 检测 | 当 Bus Off 确认或恢复时，由 ComM_BusSM_ModeIndication 通知（参见上面的 CAN State Manager） |
| 反应 | N/A |
| 报告 | 将指示的状态传播给用户（通过 RTE） |
| 恢复 | N/A |
5.2.1.2.6 BSW State Manager
| 项目 | 内容 |
|---|---|
| 检测 | 当 Bus Off 确认或恢复时，由 BswM_CanSM_RequestMode 通知（参见上面的 CAN State Manager） |
| 反应 | 未标准化 |
| 报告 | 未标准化 |
| 恢复 | N/A |
5.2.2 CAN Controller Hardware Timeout
5.2.2.1 概述
图 4：CAN Controller Hardware Timeout 的信息路径
（信息流示意图：检测（CAN Driver）→ 报告（CanSM）→ 通知（ComM, BswM）→ 恢复（CanSM：控制器复位、Tx 路径启用/禁用））
5.2.2.2 模块的角色
5.2.2.2.1 CAN 驱动
| 项目 | 内容 |
|---|---|
| 检测 | CAN 驱动负责在以下函数中检测超时（或硬件故障）：- Can_SetBaudrate()- Can_SetControllerMode()当 CanTimeoutDuration 到期时，在每个函数中执行检测 |
| 反应 | CAN 驱动不执行任何反应。在超时的情况下，CAN 驱动不完成请求的操作，并返回 NOT_OK 错误给调用方 |
| 报告 | CAN 驱动不报告任何超时事件给上层 |
| 恢复 | 参见 CAN State Manager |
5.2.2.2.2 CAN Interface
| 项目 | 内容 |
|---|---|
| 检测 | CanIf 无超时检测 |
| 反应 | CanIf 不执行任何反应 |
| 报告 | CanIf 不报告任何超时事件给上层 |
| 恢复 | 由 CAN State Manager 触发恢复：- CanIf_SetControllerMode(Controller, CANIF_CS_STARTED)- Can_InitController(Controller, *Config)- Can_SetControllerMode(Controller, CAN_T_STARTED) |
5.2.2.2.3 CAN State Manager
| 项目 | 内容 |
|---|---|
| 检测 | 当最大模式请求重复次数（CanSMModeRequestRepetitionMax）[ECUC_CanSM_00335] 到期时，无来自 CanIf 的相应模式指示，检测到超时 |
| 反应 | - 计数控制器超时事件 - 启动错误恢复机制 |
| 报告 | - [SWS_CanSM_00385] 当 CanSM 状态机被 T_REPEAT_MAX 触发时，将 CANSM_E_MODE_REQUEST_TIMEOUT 作为运行时错误报告给 DET- [SWS_CanSM_00435]、[SWS_CanSM_00538]、[SWS_CanSM_00651] CanSM 通过 ComM_BusSM_ModeIndication 通知 ComM 通信状态（COMM_SILENT_COMMUNICATION、COMM_NO_COMMUNICATION、COMM_FULL_COMMUNICATION）- [SWS_CanSM_00431]、[SWS_CanSM_00434]、[SWS_CanSM_00508] CanSM 通过 BswM_CanSM_CurrentState 通知 ComM 通信状态（CANSM_BSWM_NO_COMMUNICATION、CANSM_BSWM_SILENT_COMMUNICATION、CANSM_BSWM_BUS_OFF） |
| 恢复 | CAN State Manager 控制错误恢复机制，其中包括：- 复位 CAN 控制器：CanIf_SetControllerMode(..., CANSM_CS_STARTED)- 禁用/启用发送路径： CanIf_SetPduMode(..., CANIF_SET_TX_OFFLINE / CANIF_SET_TX_ONLINE) |
5.2.2.2.4 Communication Manager
| 项目 | 内容 |
|---|---|
| 检测 | 当 Bus Off 确认或恢复时，由 ComM_BusSM_ModeIndication 通知（参见上面的 CAN State Manager） |
| 反应 | N/A |
| 报告 | 将指示的状态传播给用户（通过 RTE） |
| 恢复 | N/A |
5.2.2.2.5 BSW State Manager
| 项目 | 内容 |
|---|---|
| 检测 | 当 Bus Off 确认或恢复时，由 BswM_CanSM_RequestMode 通知（参见上面的 CAN State Manager） |
| 反应 | 未标准化 |
| 报告 | 未标准化 |
| 恢复 | N/A |
5.3 信号错误
5.3.1 CAN 传输缓冲区满
5.3.1.1 概述
图 5：CAN 传输缓冲区满的信息路径
（信息流示意图：CAN Driver 检测缓冲区已满 → 通知 CanIf → 返回错误码或间接通过 TX 截止时间监控报告给 COM/SWC）
注意：此机制可与 COM TX 截止时间监控或传输期间 CAN 传输协议错误机制结合使用。
5.3.1.2 模块的角色
5.3.1.2.1 CAN 驱动
| 项目 | 内容 |
|---|---|
| 检测 | 在没有更多可用的硬件对象用于此传输时收到写入请求，并且其他传输不能被抢占：Can_Write [SWS_Can_00233] [SWS_Can_00213] [SWS_Can_00215] [SWS_Can_00214] [SWS_Can_00039] |
| 反应 | N/A |
| 报告 | CAN 驱动通知 CAN Interface 它当前正忙于较高优先级的消息或不能被抢占，并且当前不能发送新消息 |
| 恢复 | N/A |
5.3.1.2.2 CAN Interface
| 项目 | 内容 |
|---|---|
| 检测 | 发送缓冲可以启用或禁用：- 发送缓冲禁用：如果发送请求失败，则要传输的 L-PDU 丢失，API CanIf_Transmit() 返回值 E_NOT_OK- [SWS_CanIf_00068] 如果调用 CanIf_Transmit() 并且 CanIf 必须将 L-PDU 存储在发送 L-PDU 缓冲区中，那么如果相应的 CanIfTxBuffer 已填充，则 CanIf 应使用最近的 L-PDU 覆盖较旧的 L-PDU |
| 反应 | N/A |
| 报告 | 错误要么通过 CanIf_Transmit() 的返回码报告，要么通过之后缺少传输确认来间接报告 |
| 恢复 | N/A |
另见 COM TX 截止时间监控，它提供了一种在出现此类错误时检测和反应（从 SWC）的机制。
此错误还可能影响 TP（传输协议）通信；在这种情况下，将检测为传输期间的 CAN 传输协议错误。
5.3.2 CAN 接收 DLC 错误
5.3.2.1 概述
图 6：CAN 接收 DLC 错误的信息路径
（信息流示意图：CanIf 在 CanIf_RxIndication 中检查 DLC → 报告 CANIF_E_INVALID_DATA_LENGTH 给 DET → 间接通过 RX 截止时间监控）
注意：CAN 接收 DLC 错误机制可与 COM RX 截止时间监控机制结合使用。
此外，接收到错误的 DLC 不一定表示 ECU 内的故障，而可能是由 ECU 的环境引起的。
5.3.2.2 模块的角色
5.3.2.2.1 CAN Interface
| 项目 | 内容 |
|---|---|
| 检测 | [SWS_CanIf_00026]（CanIf_RxIndication）CAN Interface 负责在触发接收指示时检查长度。此检查仅在开发模式下进行，或者在生产模式下当模块配置了 DLC 检查功能且 PDU 配置了非空 DLC 时进行 |
| 反应 | N/A |
| 报告 | SWS_CanIf_00168：如果 DLC 检查失败，则 CANIF 将 CANIF_E_INVALID_DATA_LENGTH 错误作为运行时错误报告给 DET。不通知其他上层。不执行接收指示。错误反应应基于 COM RX 截止时间监控机制。SWS_CanIf_00006：CanDlc 的无效值（针对 CanIf_RxIndication API）将报告给 DET（CANIF_E_INVALID_DATA_LENGTH） |
| 恢复 | [SWS_CanIf_00168] 不执行接收指示 |
另见 COM RX 截止时间监控，它提供了一种在出现此类错误时检测和反应（从 SWC）的机制。
此错误还可能影响 CAN 传输或网络管理协议；在这些情况下，错误也将通过传输期间的 CAN 传输协议错误机制或网络管理协议检测到。
5.3.3 COM RX 截止时间监控
5.3.3.1 概述
图 7：COM 接收截止时间监控的信息路径
（信息流示意图：AUTOSAR COM 监控接收截止时间 → 通知 RTE → RTE 通知 SWC → SWC 决定重发或忽略）
5.3.3.2 模块的角色
5.3.3.2.1 AUTOSAR COM
| 项目 | 内容 |
|---|---|
| 检测 | [SWS_Com_00292] 如果已配置，AUTOSAR COM 将注意到失败，因为在给定时间段内未接收到信号 |
| 反应 | [SWS_Com_00470] [SWS_Com_00513] [SWS_Com_00500] AUTOSAR COM 可以用默认值替换值或保留先前的值 |
| 报告 | [SWS_Com_00556] 通过 Com_CbkRxTOut 通知上层（RTE） |
| 恢复 | [SWS_Com_00470] [SWS_Com_00513] [SWS_Com_00500] AUTOSAR COM 可以用默认值替换值或保留先前的值 |
5.3.3.2.2 RTE
| 项目 | 内容 |
|---|---|
| 检测 | RTE 由 AUTOSAR COM 通过 Rte_COMCbkRxTOut_<sn>（或 Rte_COMCbkRxTOut_<sg>）通知（参见上面的 AUTOSAR COM） |
| 反应 | N/A |
| 报告 | RTE 通过 DataReceiveErrorEvent 通知 SWC |
| 恢复 | 参见 AUTOSAR COM 和 SWC |
5.3.3.2.3 SWC
| 项目 | 内容 |
|---|---|
| 检测 | SWC 由 RTE 通知（DataReceiveErrorEvent），传输的状态通过 Rte_Feedback API 请求（参见上面的 RTE） |
| 反应 | SWC 可以决定重新发送信号或忽略错误 |
| 报告 | N/A |
| 恢复 | SWC 可以决定重新发送信号 |
5.3.4 COM TX 截止时间监控
5.3.4.1 概述
图 8：COM 传输截止时间监控的信息路径
（信息流示意图：AUTOSAR COM 监控传输截止时间 → 通知 RTE → RTE 通知 SWC → SWC 决定重发或记录错误）
此功能应仅在下层通信模块为传输提供确认时使用。
5.3.4.2 模块的角色
5.3.4.2.1 AUTOSAR COM
| 项目 | 内容 |
|---|---|
| 检测 | [SWS_Com_00304] 如果已配置传输截止时间监控，则当传输截止时间到期时，如果下层模块不确认传输，AUTOSAR COM 将注意到超时 |
| 反应 | N/A |
| 报告 | [SWS_Com_00554] 通过 Com_CbkTxTOut 通知上层（RTE） |
| 恢复 | 参见 SWC |
5.3.4.2.2 RTE
| 项目 | 内容 |
|---|---|
| 检测 | RTE 由 AUTOSAR COM 通知：[SWS_Rte_03775] Rte_COMCbkTxTErr_<sn>（或 Rte_COMCbkTxTOut_<sn>?） |
| 反应 | N/A |
| 报告 | RTE 通过 DataSendCompletedEvent 通知 SWC，并通过 Rte_Feedback API 提供状态 |
| 恢复 | 参见 SWC |
5.3.4.2.3 SWC
| 项目 | 内容 |
|---|---|
| 检测 | SWC 由 RTE 通知（DataSendCompletedEvent），传输的状态通过 Rte_Feedback API 请求 |
| 反应 | SWC 可以决定重新发送信号，记录或忽略错误 |
| 报告 | N/A |
| 恢复 | SWC 可以决定重新发送信号 |
5.3.5 CAN 传输协议错误（传输期间）
此用例是传输协议的功能，在 CanTp 模块的功能行为中定义。它在此处提及是为了完整地说明 CAN 帧传输失败的用例。
下面的分析仅考虑 CanTP 协议中的超时错误，但行为对于其他总线或其他传输协议错误是相同的。
5.3.5.1 概述
图 9：传输期间 CAN 传输协议错误的信息路径
（信息流示意图：CanTp 检测到超时 → 取消传输 → 报告给 DET → 通过 PduR_CanTpTxConfirmation 通知用户（DCM））
注意：在上图中，DCM 代表 CANTP 用户。CanTP 的其他用户应类似地反应（它们将收到失败指示，并负责启动恢复）。另一个用户可以是 SWC，其通信通过 PDU Router 路由到 AUTOSAR COM，或复杂驱动。
5.3.5.2 模块的角色
5.3.5.2.1 CanTp
| 项目 | 内容 |
|---|---|
| 检测 | CanTp 模块实现 CAN 传输层协议，并负责检测传输期间的任何超时 |
| 反应 | [SWS_CanTp_00205] 如果检测到超时，则取消传输。模块准备好处理另一个传输请求 |
| 报告 | [SWS_CanTp_00229] 任何错误作为运行时错误报告给 DET（事件 CANTP_E_TX_COM、CANTP_E_COM）。注意：这些事件不能在运行时用于为此错误情况构建反应，因为它不区分不同的错误情况或不同的通信信道。[SWS_CanTp_00205] 错误也通过 PduR_CanTpTxConfirmation 报告给 CanTP 的用户（例如，通过 PDUR 的 DCM） |
| 恢复 | N/A |
5.3.5.2.2 PDUR
| 项目 | 内容 |
|---|---|
| 检测 | PDUR 通过 PduR_CanTpTxConfirmation API 被通知（参见上面的 CanTp） |
| 反应 | N/A |
| 报告 | 错误路由到 CanTP 用户（Dcm_TxConfirmation） |
| 恢复 | N/A |
5.3.5.2.3 DCM
| 项目 | 内容 |
|---|---|
| 检测 | [SWS_Dcm_00351] DCM 由 Dcm_TxConfirmation 的 Result 参数通知（参见上面的 PDUR）。还有针对诊断会话的内部超时处理程序 |
| 反应 | [SWS_Dcm_00351] 传输资源（传输缓冲区）被解锁。其他错误处理功能（DCM 中的超时）被取消 |
| 报告 | 通过 ConfirmationRespPend 操作通知用户 |
| 恢复 | N/A |
注意：CanTP 的其他用户应提供类似的通知 callout 并应类似地反应。例如，AUTOSAR COM 模块就是这种情况。
5.3.6 CAN 传输协议错误（接收期间）
5.3.6.1 概述
图 10：接收期间 CAN 传输协议错误的信息路径
（信息流示意图：CanTp 检测到超时 → 取消接收 → 报告给 DET → 通过 PduR_CanTpRxIndication 通知用户（DCM））
注意：在上图中，DCM 代表 CANTP 用户。CanTP 的其他用户应类似地反应（它们将收到失败指示，并负责启动恢复）。另一个用户可以是 SWC，其通信通过 PDU Router 路由到 AUTOSAR COM，或复杂驱动。
5.3.6.2 模块的角色
5.3.6.2.1 CanTp
| 项目 | 内容 |
|---|---|
| 检测 | CanTp 模块实现 CAN 传输层协议，并负责检测接收期间的任何超时 |
| 反应 | [SWS_CanTp_00205] 如果检测到超时，则取消接收 |
| 报告 | [SWS_CanTp_00229] 任何错误作为运行时错误报告给 DET（事件 CANTP_E_RX_COM、CANTP_E_COM）。注意：这些事件不能用于为此错误情况构建反应，因为它不区分不同的错误情况或不同的通信信道。[SWS_CanTp_00205] 错误也通过 PduR_CanTpRxIndication 报告给 CanTP 的用户（例如，通过 PDUR 的 DCM） |
| 恢复 | N/A |
5.3.6.2.2 PDUR
| 项目 | 内容 |
|---|---|
| 检测 | PDUR 通过 PduR_CanTpRxIndication API 被通知（参见上面的 CanTp） |
| 反应 | N/A |
| 报告 | 错误路由到 CanTP 用户（例如，Dcm_RxIndication） |
| 恢复 | N/A |
5.3.6.2.3 DCM
| 项目 | 内容 |
|---|---|
| 检测 | DCM 由 Dcm_RxIndication 的 Result 参数通知。还有针对诊断会话的内部超时处理程序 |
| 反应 | 接收资源（接收缓冲区）被解锁 |
| 报告 | N/A |
| 恢复 | N/A |
注意：CanTP 的其他用户应提供类似的通知 callout 并应类似地反应。例如，AUTOSAR COM 模块就是这种情况。
5.3.7 CANNM TX 截止时间监控
此用例实际上不是错误。它是网络管理的功能，在 CanNm 模块的功能行为中定义。它在此处提及是为了完整地说明 CAN 帧传输失败的用例。
5.3.8 PDU 复制错误
5.3.8.1 概述
图 11：PDU 复制错误的信息路径
（信息流示意图：AUTOSAR COM 内部：PDU 复制 → 投票 → 仅在达到法定数量后才报告给 RTE）
此机制是 AUTOSAR COM 模块的内部机制。不存在专门针对此错误的通知。
注意：PDU 复制错误机制可与 COM RX 截止时间监控机制结合使用。
5.3.8.2 模块的角色
5.3.8.2.1 AUTOSAR COM
| 项目 | 内容 |
|---|---|
| 检测 | 检测是间接的，因为只有已投票的信号或信号组才会报告给 RTE。其他 PDU 被丢弃，并可能通过 COM RX 截止时间监控机制导致检测 |
| 反应 | [SWS_Com_00596] PDU 仅在接收到相同值的法定数量后才报告给 RTE。[SWS_Com_00597] 信号和信号组仅向 RTE 报告一次 |
| 报告 | N/A |
| 恢复 | 如果为 PDU 接收到足够多的副本，则将已投票的 PDU 报告给 RTE |
5.3.9 PDU 计数器错误
5.3.9.1 概述
图 12：PDU 计数器错误的信息路径
（信息流示意图：AUTOSAR COM 内部：PDU 计数器不匹配 → 丢弃 PDU → 通过 RX 截止时间监控报告）
此机制是 AUTOSAR COM 模块的内部机制。不存在专门针对此错误的通知。
注意：PDU 计数器错误机制可与 COM RX 截止时间监控机制结合使用。
5.3.9.2 模块的角色
5.3.9.2.1 AUTOSAR COM
| 项目 | 内容 |
|---|---|
| 检测 | AUTOSAR COM 模块负责检测乱序 PDU |
| 反应 | [SWS_Com_00590] 如果接收到的 PDU 的 PDU 计数器与预期计数器（在定义的阈值范围内）不匹配，则 PDU 被丢弃 |
| 报告 | N/A |
| 恢复 | 此机制不引入新机制：作为已丢弃 PDU的结果，可能检测到 RX 超时 |
5.3.10 客户端/服务器超时
5.3.10.1 概述
图 13：客户端/服务器超时的信息路径
（信息流示意图：RTE 检测客户端/服务器超时 → 通知 SWC → SWC 决定重新发送或忽略）
5.3.10.2 模块的角色
5.3.10.2.1 RTE
| 项目 | 内容 |
|---|---|
| 检测 | [SWS_Rte_3763] 如果已配置，RTE 负责检测超时。（注意：对于本地 ECU 间通信，有一些例外，其中不考虑超时） |
| 反应 | N/A |
| 报告 | [SWS_Rte_1107] [SWS_Rte_1114] RTE 通过 AsynchronousServerCallReturnsEvent 通知 SWC，并通过 Rte_Call 或 Rte_Result API 提供状态 |
| 恢复 | 参见 SWC |
5.3.10.2.2 SWC
| 项目 | 内容 |
|---|---|
| 检测 | SWC 由 RTE 通知（DataSendCompletedEvent），传输的状态通过 Rte_Call 或 Rte_Result API 返回 |
| 反应 | SWC 可以决定重新发送请求，记录或忽略错误 |
| 报告 | N/A |
| 恢复 | SWC 可以决定重新发送请求 |
6 NVRAM 相关错误
6.1 概述
6.1.1 错误处理机制
图 14：NVRAM 错误处理机制概述
（架构示意图：NVRAM 错误处理机制涵盖以下模块：内部/外部 Flash Driver、Flash EEPROM Emulation（Fee）、EEPROM Abstraction（Ea）、Memory Abstraction Interface（MemIf）、NVRAM Manager（NvM）、DEM/DET/FIM）
错误检测机制：
- Job failure detection confirmation（作业失败检测确认）
- CRC check（CRC 检查）
- Static block check（静态块检查）
- Write verification（写入验证）
- Loss of redundancy detection（冗余丢失检测）
- Read consistency check（读取一致性检查）
恢复机制：
- Read Retry（读取重试）
- Read Redundant Block（读取冗余块）
- Read ROM data（读取 ROM 数据）
- Write Retry（写入重试）
- Write Redundant Block（写入冗余块）
在 NVRAM 栈的较低层，机制在驱动程序中实现以检测硬件访问问题。检测机制在 EEPROM 和 Flash 驱动之间是统一的。
在 NVRAM 栈的上层（主要在 NVRAM 管理器中），机制实现以检测数据损坏、内存地址损坏和冗余丢失。NVRAM 栈中检测到的错误的所有恢复机制都由 NVRAM Manager 处理。
错误可以以轮询或中断模式报告。整个内存栈必须与 SWC 和 BSW 用户的使用一致地配置。
6.1.2 NVRAM 栈错误列表
表 4：NVRAM 栈错误列表
| 错误 | 描述 | 检测模块 | DEM 错误（报告者以粗体显示） | 具有 BSW 恢复动作的缓解器 |
|---|---|---|---|---|
| 驱动层错误 | ||||
| Flash write job error | 由于硬件错误，Flash 写入作业失败 | FLS | FLS_E_WRITE_FAILED | NVM：→ 写入重试 |
| Flash erase job error | 由于硬件错误，Flash 擦除作业失败 | FLS | FLS_E_ERASE_FAILED | NVM：如果涉及写入处理，→ 写入重试 |
| Flash read job error | 由于硬件错误，Flash 读取作业失败 | FLS | FLS_E_READ_FAILED | NVM：→ 读取重试、读取冗余块、读取 ROM 块 |
| Flash compare job error | 由于硬件错误，Flash 比较作业失败 | FLS | FLS_E_COMPARE_FAILED | 无 |
| External Flash Hardware ID Mismatch | 在驱动初始化期间，期望的硬件 ID 不匹配 | FLS | FLS_E_UNEXPECTED_FLASH_ID | 无 |
| EEPROM write job error | 由于硬件错误，EEPROM 写入作业失败 | EEP | EEP_E_WRITE_FAILED | NVM：→ 写入重试 |
| EEPROM erase job error | 由于硬件错误，EEPROM 擦除作业失败 | EEP | EEP_E_ERASE_FAILED | NVM：如果涉及写入处理，→ 写入重试 |
| EEPROM read job error | 由于硬件错误，EEPROM 读取作业失败 | EEP | EEP_E_READ_FAILED | NVM：→ 读取重试、读取冗余块、读取 ROM 块 |
| EEPROM compare job error | 由于硬件错误，EEPROM 比较作业失败 | EEP | EEP_E_COMPARE_FAILED | 无 |
| EEPROM 抽象 / Flash 仿真层错误 | ||||
| FEE consistency check error | Flash EEPROM Emulation 检测到要读取的块的一致性问题 | FEE | NVM_E_INTEGRITY_FAILED | NVM：→ 读取冗余块、读取 ROM 块 |
| EA consistency check error | EEPROM Abstraction emulation 检测到要读取的块的一致性问题 | EA | NVM_E_INTEGRITY_FAILED | NVM：→ 读取冗余块、读取 ROM 块 |
| NVRAM 管理器层错误 | ||||
| NVM CRC check | RAM 块上的 CRC 检查失败 | NVM | NVM_E_INTEGRITY_FAILED | NVM：→ 读取冗余块、读取 ROM 块 |
| NVM write verification error | 写入 NVRAM 的 NVRAM 块立即被读回并与 RAM 中的原始内容进行比较 | NVM | NVM_E_VERIFY_FAILED | NVM：→ 写入重试 |
| Static block check error | 静态块 ID 检查失败 | NVM | NVM_E_WRONG_BLOCK_ID | NVM：→ 读取重试、读取冗余块、读取 ROM 块 |
| Loss of redundancy | 读取或写入期间冗余块无效 | NVM | NVM_E_LOSS_OF_REDUNDANCY | NVM：→ 恢复损坏的 NV 块 |
| NVM API request failure | 恢复失败后作业失败得到确认 | NVM | NVM_E_REQ_FAILED | 无 |
6.1.3 EH 机制到 NVRAM 硬件失效模式的映射
以下 NVRAM 硬件失效模式已被考虑：
表 5：NVRAM 硬件失效模式
| ID | 简称 | 描述 |
|---|---|---|
| FM01 | No access（无法访问） | 内存设备无法被访问 |
| FM02 | Read corrupt data（读取损坏数据） | 从内存读取的数据已损坏，即与预期不符 |
| FM03 | Read from incorrect address（从错误地址读取） | 未读取预期地址的单元格。而是获得其他单元格的值 |
| FM04 | Write corrupt data（写入损坏数据） | 写入内存的数据被内存设备损坏，即存储的数据与预期不符 |
| FM05 | Write to incorrect address（写入错误地址） | 未写入预期地址的单元格。而是覆盖其他单元格的值 |
下表显示了与每个 FM 相关的错误处理机制以及机制效率的定性估计。定性度量定义如下：
- A – 对所考虑 FM 的完全覆盖
- P – 对所考虑 FM 的部分覆盖
- N – 对所考虑 FM 的无覆盖
表 6：检测机制到失效模式的映射
| ID | 失效模式 | 描述 | 作业失败检测 | CRC 检查 | 静态块 ID 检查 | 写入验证 |
|---|---|---|---|---|---|---|
| FM01 | No access | 内存设备无法被访问 | A | N | N | N |
| FM02 | Read corrupt data | 从内存读取的数据已损坏 | N | P | N | N |
| FM03 | Read from incorrect address | 未读取预期地址的单元格 | N | P | P | N |
| FM04 | Write corrupt data | 写入内存的数据被内存设备损坏 | N | N | N | A |
| FM05 | Write to incorrect address | 未写入预期地址的单元格 | N | N | N | P |
表 7：恢复机制到失效模式的映射
| ID | 失效模式 | 描述 | 读取重试 (1) | 读取冗余块 | 读取 ROM 数据 | 写入重试 | 写入冗余块 |
|---|---|---|---|---|---|---|---|
| FM01 | No access | 内存设备无法被访问 | P | N | P | P | N |
| FM02 | Read corrupt data | 从内存读取的数据已损坏 | P | P | P | N | N |
| FM03 | Read from incorrect address | 未读取预期地址的单元格 | P | P | P | N | N |
| FM04 | Write corrupt data | 写入内存的数据被内存设备损坏 | N | N | N | P | P |
| FM05 | Write to incorrect address | 未写入预期地址的单元格 | N | N | N | P | P |
(1) 针对瞬态错误。
6.2 驱动层错误
6.2.1 Flash 写入作业错误
6.2.1.1 概述
图 15：Flash 写入作业错误的信息路径（针对内部 Flash）
（信息流示意图：检测（Flash 控制器，1）→ 报告（Flash 驱动，2）→ 通知（FEE，3）→ 恢复（NVM：写入重试，3）→ 如果失败，报告 NVM_E_REQ_FAILED 给 DEM（4）→ 任务结果为 NOK（5））
写入作业错误由 HW 检测（1）。Flash 驱动是涉及的第一个 SW 模块，并负责报告给 DEM 和上层（2）。上层必须重置一些内部状态以接受新请求。NVM 模块中存在恢复机制，允许在失败的情况下重试写入作业（3）。如果恢复也失败（4），NVRAM 管理器将 NVM_E_REQ_FAILED 错误报告给 DEM，并将任务结果设置为 NOK（5），参见 NVM API 请求失败。
6.2.1.2 模块的角色
6.2.1.2.1 Flash 控制器
| 项目 | 内容 |
|---|---|
| 检测 | 取决于硬件 |
| 反应 | N/A |
| 报告 | 取决于驱动配置或硬件实现，错误可以报告在寄存器中，或者控制器可以通过中断将错误报告给驱动 |
| 恢复 | 参见 NVRAM Manager |
6.2.1.2.2 Flash 驱动
| 项目 | 内容 |
|---|---|
| 检测 | 由 Flash 控制器报告（参见上面的 Flash 控制器） |
| 反应 | - [SWS_Fls_00105] 作业被中止- [FLS052] 模块状态设置为 MEMIF_IDLE，准备好接受新作业 |
| 报告 | - [SWS_Fls_00004] [SWS_Fls_00105] 错误作为错误码 FLS_E_WRITE_FAILED 报告给 DEM。取决于 Flash 驱动配置：- [SWS_Fls_00105] [SWS_Fls_00035] 错误应由 Flash EEPROM Emulation 通过函数 Fls_GetJobResult 轮询（作业结果设置为 MEMIF_JOB_FAILED）- [SWS_Fls_00263] [FLS168] 错误应通过回调函数 Fee_JobErrorNotification 报告给 Flash EEPROM Emulation |
| 恢复 | 参见 NVRAM Manager |
6.2.1.2.3 Flash EEPROM Emulation
| 项目 | 内容 |
|---|---|
| 检测 | 由 Flash 驱动报告（参见上面的 Flash 驱动） |
| 反应 | [SWS_Fee_00054] 实现特定的错误处理 |
| 报告 | 取决于配置：- [SWS_Fee_00091] [SWS_Fee_00035] 错误应由 Memory Abstraction Interface 通过函数 Fee_GetJobResult 轮询（作业结果设置为 MEMIF_JOB_FAILED）- [SWS_Fee_00056] [SWS_Fee_00054] 错误应通过回调函数 NvM_JobErrorNotification 报告给 NVRAM Manager |
| 恢复 | 参见 NVRAM Manager |
6.2.1.2.4 Memory Abstraction Interface
| 项目 | 内容 |
|---|---|
| 检测 | 由 Flash EEPROM Emulation 报告（参见上面的 Flash EEPROM Emulation），仅在栈配置为轮询模式时 |
| 反应 | N/A |
| 报告 | 仅在栈配置为轮询模式时：- [MemIf043] [MemIf053] 错误应由 NVRAM 管理器通过函数 MemIf_GetJobResult 轮询（作业结果设置为 MEMIF_JOB_FAILED） |
| 恢复 | 参见 NVRAM Manager |
6.2.1.2.5 NVRAM Manager
| 项目 | 内容 |
|---|---|
| 检测 | 取决于栈配置：- 通过函数 MemIf_GetJobResult 轮询作业结果 MEMIF_JOB_FAILED（参见上面的 Memory Abstraction Interface）- 由 FEE 通过回调函数 NvM_JobErrorNotification 通知（参见上面的 Flash EEPROM Emulation） |
| 反应 | [SWS_NvM_00213] [SWS_NvM_00296] 递增写入重试计数器。如果重试次数超过，则中止请求 |
| 报告 | - [SWS_NvM_00213] [SWS_NvM_00296] 如果恢复动作中止，则将错误 NVM_E_REQ_FAILED 报告给 DEM。取决于配置：- [SWS_NvM_00451] [SWS_NvM_00213] [SWS_NvM_00296] 错误应由用户通过函数 NvM_GetErrorStatus 轮询（作业结果设置为 NVM_REQ_NOT_OK）- [SWS_NvM_00113] [SWS_NvM_00260] 错误应通过可配置回调 SingleBlockCallbackFunction 或 MultiBlockCallbackFunction 报告给用户 |
| 恢复 | [SWS_NvM_00168] [SWS_NvM_00213] [SWS_NvM_00296] NVRAM Manager 控制错误恢复机制。恢复机制是（如果已配置）"写入重试" |
6.2.1.2.6 Application Software Component
| 项目 | 内容 |
|---|---|
| 检测 | 如果错误处理策略的设计需要，SWC 可以以两种不同的方式设计：- 它通过连接到 NVM 的客户端端口上的 GetErrorStatus 操作轮询作业状态- 它提供连接到 NvMNotifyJobFinished 服务器端口的服务器 runnables，该端口应由 NVM 调用。参见 Autosar_SWS_NVRAMManager.pdf 的章节 13.3.1.3 端口接口 和 13.3.2 通知的端口和端口接口 |
6.2.2 Flash 擦除作业错误
6.2.2.1 概述
图 16：Flash 擦除作业错误的信息路径（针对内部 Flash）
（信息流示意图：检测（Flash 控制器，1）→ 报告（Flash 驱动，2）→ 通知（FEE，3）→ 恢复（NVM：写入重试，3）→ 如果失败，报告 NVM_E_REQ_FAILED 给 DEM（4）→ 任务结果为 NOK（5））
擦除作业错误由 HW 检测（1）。Flash 驱动是涉及的第一个 SW 模块，并负责报告给 DEM 和上层（2）。上层必须重置一些内部状态以接受新请求。如果擦除驱动作业是写入操作的一部分，则一旦错误报告给该层，写入重试将由 NVRAM 管理器启动（3）。如果恢复也失败（4），NVRAM 管理器将 NVM_E_REQ_FAILED 错误报告给 DEM，并将任务结果设置为 NOK（5），参见 NVM API 请求失败。
6.2.2.2 模块的角色
6.2.2.2.1 Flash 控制器
| 项目 | 内容 |
|---|---|
| 检测 | 取决于硬件 |
| 反应 | N/A |
| 报告 | 取决于驱动配置或硬件实现，错误可以报告在寄存器中，或者控制器可以通过中断将错误报告给驱动 |
| 恢复 | 参见 NVRAM Manager |
6.2.2.2.2 Flash 驱动
| 项目 | 内容 |
|---|---|
| 检测 | 由 Flash 控制器报告（参见上面的 Flash 控制器） |
| 反应 | - [SWS_Fls_00104] 作业被中止- [FLS052] 模块状态设置为 MEMIF_IDLE，准备好接受新作业 |
| 报告 | - [SWS_Fls_00004] [SWS_Fls_00104] 错误作为错误码 FLS_E_ERASE_FAILED 报告给 DEM。取决于 Flash 驱动配置：- [SWS_Fls_00104] [SWS_Fls_00035] 错误应由 Flash EEPROM Emulation 通过函数 Fls_GetJobResult 轮询（作业结果设置为 MEMIF_JOB_FAILED）- [SWS_Fls_00263] [FLS168] 错误应通过回调函数 Fee_JobErrorNotification 报告给 Flash EEPROM Emulation |
| 恢复 | 参见 NVRAM Manager |
6.2.2.2.3 Flash EEPROM Emulation
| 项目 | 内容 |
|---|---|
| 检测 | 由 Flash 驱动报告（参见上面的 Flash 驱动） |
| 反应 | [SWS_Fee_00054] 实现特定的错误处理 |
| 报告 | 取决于配置：- [SWS_Fee_00091] [SWS_Fee_00035] 错误应由 Memory Abstraction Interface 通过函数 Fee_GetJobResult 轮询（作业结果设置为 MEMIF_JOB_FAILED）- [SWS_Fee_00056] [SWS_Fee_00054] 错误应通过回调函数 NvM_JobErrorNotification 报告给 NVRAM Manager |
| 恢复 | 参见 NVRAM Manager |
6.2.2.2.4 Memory Abstraction Interface
| 项目 | 内容 |
|---|---|
| 检测 | 由 Flash EEPROM Emulation 报告（参见上面的 Flash EEPROM Emulation），仅在栈配置为轮询模式时 |
| 反应 | N/A |
| 报告 | 取决于配置：- [MemIf043] [MemIf053] 错误应由 NVRAM 管理器通过函数 MemIf_GetJobResult 轮询（作业结果设置为 MEMIF_JOB_FAILED） |
| 恢复 | 参见 NVRAM Manager |
6.2.2.2.5 NVRAM Manager
| 项目 | 内容 |
|---|---|
| 检测 | 取决于栈配置：- 通过函数 MemIf_GetJobResult 轮询作业结果 MEMIF_JOB_FAILED- 由 FEE 通过回调函数 NvM_JobErrorNotification 通知 |
| 反应 | 如果涉及写入处理：[SWS_NvM_00213] [SWS_NvM_00296] 递增写入重试计数器。如果重试次数超过，则中止请求 |
| 报告 | - [SWS_NvM_00271] [SWS_NvM_00269] 错误 NVM_E_REQ_FAILED 报告给 DEM- 错误可通过使用函数 NvM_GetErrorStatus 轮询 NVRAM Manager 获得（作业结果设置为 NVM_REQ_NOT_OK） |
| 恢复 | 如果涉及写入处理：[SWS_NvM_00168] [SWS_NvM_00213] [SWS_NvM_00296] NVRAM Manager 控制错误恢复机制。恢复机制是（如果已配置）"写入重试" |
6.2.2.2.6 Application Software Component
| 项目 | 内容 |
|---|---|
| 检测 | 如果错误处理策略的设计需要，SWC 可以以两种不同的方式设计：- 它通过连接到 NVM 的客户端端口上的 GetErrorStatus 操作轮询作业状态- 它提供连接到 NvMNotifyJobFinished 服务器端口的服务器 runnables，该端口应由 NVM 调用。参见 Autosar_SWS_NVRAMManager.pdf 的章节 13.3.1.3 端口接口 和 13.3.2 通知的端口和端口接口 |
6.2.3 Flash 读取作业错误
6.2.3.1 概述
图 17：Flash 读取作业错误的信息路径（内部 Flash）
（信息流示意图：检测（Flash 控制器）→ 报告（Flash 驱动）→ 通知（FEE）→ 恢复（NVM：读取重试）→ 如果失败，报告 NVM_E_REQ_FAILED 给 DEM）
读取作业错误由 HW 检测。Flash 驱动是涉及的第一个 SW 模块，并负责报告给 DEM 和上层（2）。上层必须重置一些内部状态以接受新请求。恢复由 NVRAM 管理器启动（3）：在继续读取冗余块或 ROM 数据之前，应进行一次或多次读取尝试。如果恢复动作意味着冗余丢失或使用 ROM 数据，NVRAM 管理器通过作业结果报告数据质量损失。针对冗余丢失报告 DEM 错误（参见冗余丢失）。如果恢复也失败（4），NVRAM 管理器将 NVM_E_REQ_FAILED 错误报告给 DEM，并将任务结果设置为 NOK（5），参见 NVM API 请求失败。
6.2.3.2 模块的角色
6.2.3.2.1 Flash 控制器
| 项目 | 内容 |
|---|---|
| 检测 | 取决于硬件 |
| 反应 | N/A |
| 报告 | 取决于驱动配置或硬件实现，错误可以报告在寄存器中，或者控制器可以通过中断将错误报告给驱动 |
| 恢复 | 参见 NVRAM Manager |
6.2.3.2.2 Flash 驱动
| 项目 | 内容 |
|---|---|
| 检测 | 由 Flash 控制器报告（参见上面的 Flash 控制器） |
| 反应 | - [SWS_Fls_00106] 作业被中止- [FLS052] 模块状态设置为 MEMIF_IDLE，准备好接受新作业 |
| 报告 | - [SWS_Fls_00004] [SWS_Fls_00106] 错误作为错误码 FLS_E_READ_FAILED 报告给 DEM。取决于 Flash 驱动配置：- [SWS_Fls_00106] [SWS_Fls_00035] 错误应由 Flash EEPROM Emulation 通过函数 Fls_GetJobResult 轮询（作业结果设置为 MEMIF_JOB_FAILED）- [SWS_Fls_00263] [FLS168] 错误应通过回调函数 Fee_JobErrorNotification 报告给 Flash EEPROM Emulation |
| 恢复 | 参见 NVRAM Manager |
6.2.3.2.3 Flash EEPROM Emulation
| 项目 | 内容 |
|---|---|
| 检测 | 由 Flash 驱动报告（参见上面的 Flash 驱动） |
| 反应 | 实现特定的错误处理 |
| 报告 | 取决于配置：- 错误应由 Memory Abstraction Interface 通过函数 Fee_GetJobResult 轮询（作业结果设置为 MEMIF_JOB_FAILED）- 错误应通过回调函数 NvM_JobErrorNotification 报告给 NVRAM Manager |
| 恢复 | 参见 NVRAM Manager |
（更多 EEPROM 读取作业错误、EEPROM 写入/擦除/比较作业错误、FEE 一致性检查错误、EA 一致性检查错误、NVM CRC 检查、NVM 写入验证错误、静态块检查错误、冗余丢失、NVM API 请求失败等的描述，结构与上述类似。）
6.3 EEPROM 抽象 / Flash 仿真层错误
6.3.1 FEE 一致性检查错误
6.3.1.1 概述
图 24：FEE 一致性检查错误的信息路径
（信息流示意图：检测（FEE，1）→ 通知（MemIf，2）→ 报告和恢复（NVM，3）→ 如果失败，任务结果为 NVM_REQ_INTEGRITY_FAILED（4））
Flash EEPROM Emulation 检查读取数据的一致性（1）。如果检测到一致性错误，则错误状态转发给 NVRAM 管理器（2）。NVRAM 管理器将 NVM_E_INTEGRITY_FAILED 报告给 DEM（3）。恢复也启动："读取重试"、"读取冗余块" 和 "读取 ROM 块"（如果已配置）（3）。如果恢复动作意味着冗余丢失或使用 ROM 数据，NVRAM 管理器通过作业结果报告数据质量损失。针对冗余丢失报告 DEM 错误（参见冗余丢失）。如果恢复失败（4），则作业结果设置为 NVM_REQ_INTEGRITY_FAILED（5）。
6.3.1.2 模块的角色
6.3.1.2.1 Flash EEPROM Emulation
| 项目 | 内容 |
|---|---|
| 检测 | [SWS_Fee_00023] Fee 模块检查读取数据的一致性 |
| 反应 | N/A |
| 报告 | 取决于配置：- [SWS_Fee_00091] [SWS_Fee_00023] 错误应由 Memory Abstraction Interface 通过函数 Fee_GetJobResult 轮询（作业结果设置为 MEMIF_BLOCK_INCONSISTENT）- [SWS_Fee_00056] [SWS_Fee_00054] 错误应通过回调函数 报告给 NVRAM Manager |
| 恢复 | 参见 NVRAM Manager |
6.3.1.2.2 Memory Abstraction Interface
| 项目 | 内容 |
|---|---|
| 检测 | 由 Flash EEPROM Emulation 报告（参见上面的 Flash EEPROM Emulation），仅在栈配置为轮询模式时 |
| 反应 | N/A |
| 报告 | 取决于配置：- [MemIf043] [MemIf053] 错误应由 NVRAM 管理器通过函数 MemIf_GetJobResult 轮询（作业结果设置为 MEMIF_JOB_FAILED） |
| 恢复 | 参见 NVRAM Manager |
6.3.1.2.3 NVRAM Manager
| 项目 | 内容 |
|---|---|
| 检测 | 由 Memory Abstraction Interface 报告（参见上面的 Memory Abstraction Interface） |
| 反应 | N/A |
| 报告 | - [SWS_NvM_00470] [SWS_NvM_00546] 如果检测到冗余丢失，则作业结果设置为 NVM_REQ_REDUNDANCY_FAILED，并且 NVM_E_LOSS_OF_REDUNDANCY 错误报告给 DEM- [SWS_NvM_00470] 如果恢复期间使用 ROM 数据，则作业结果设置为 NVM_REQ_RESTORED_FROM_ROM- [SWS_NvM_00358] [SWS_NvM_00360] 如果恢复机制失败，则 NVM 将错误 NVM_E_INTEGRITY_FAILED 报告给 DEM- 如果恢复机制失败，取决于栈配置： - [SWS_NvM_00451] [SWS_NvM_00358] [SWS_NvM_00360] 错误应由用户通过函数 NvM_GetErrorStatus 轮询（作业结果设置为 NVM_REQ_INTEGRITY_FAILED）- [SWS_NvM_00113] [SWS_NvM_00260] 错误应通过可配置回调 SingleBlockCallbackFunction 或 MultiBlockCallbackFunction 报告给用户 |
| 恢复 | - [SWS_NvM_00390] [SWS_NvM_00171] [SWS_NvM_00172] [SWS_NvM_00391] [SWS_NvM_00388] NVRAM Manager 控制错误恢复机制。恢复机制包括（如果已配置）"读取冗余块" 和 "读取 ROM 块" |
6.3.1.2.4 Application Software Component
参见 6.2.1.2.6 节中描述的 SWC 设计模式。
6.3.2 EA 一致性检查错误
6.3.2.1 概述
图 25：EA 一致性检查错误的信息路径
（信息流示意图：检测（EA，1）→ 通知（MemIf，2）→ 报告和恢复（NVM，3）→ 如果失败，任务结果为 NVM_REQ_INTEGRITY_FAILED（4））
EEPROM Abstraction 检查读取数据的一致性（1）。如果检测到一致性错误，则错误状态转发给 NVRAM 管理器（2）。NVRAM 管理器将 NVM_E_INTEGRITY_FAILED 报告给 DEM，并且恢复启动："读取重试"、"读取冗余块" 和 "读取 ROM 块"（如果已配置）（3）。如果恢复动作意味着冗余丢失或使用 ROM 数据，NVRAM 管理器通过作业结果报告数据质量损失。针对冗余丢失报告 DEM 错误（参见冗余丢失）。如果恢复失败（4），则作业结果设置为 NVM_REQ_INTEGRITY_FAILED（5）。
6.3.2.2 模块的角色
6.3.2.2.1 EEPROM Abstraction
| 项目 | 内容 |
|---|---|
| 检测 | [SWS_Ea_00104] Eeprom Abstraction 模块检查读取数据的一致性 |
| 反应 | N/A |
| 报告 | 取决于配置：- [SWS_Ea_00035] 错误应由 Memory Abstraction Interface 通过函数 Eep_GetJobResult 轮询（作业结果设置为 MEMIF_JOB_FAILED）- [SWS_Ea_00053] [SWS_Ea_00095] 错误应通过回调函数 NvM_JobErrorNotification 报告给 NVRAM Manager |
| 恢复 | 参见 NVRAM Manager |
6.3.2.2.2 Memory Abstraction Interface
| 项目 | 内容 |
|---|---|
| 检测 | 由 Eeprom Abstraction 报告（参见上面的 Eeprom Abstraction），仅在栈配置为轮询模式时 |
| 反应 | N/A |
| 报告 | 取决于配置：- [MemIf043] [MemIf053] 错误应由 NVRAM 管理器通过函数 MemIf_GetJobResult 轮询（作业结果设置为 MEMIF_JOB_FAILED） |
| 恢复 | 参见 NVRAM Manager |
6.3.2.2.3 NVRAM Manager
| 项目 | 内容 |
|---|---|
| 检测 | 由 Memory Abstraction Interface 报告 |
| 反应 | N/A |
| 报告 | - [SWS_NvM_00470] [SWS_NvM_00546] 如果检测到冗余丢失，则作业结果设置为 NVM_REQ_REDUNDANCY_FAILED，并且 NVM_E_LOSS_OF_REDUNDANCY 错误报告给 DEM- [SWS_NvM_00470] 如果恢复期间使用 ROM 数据，则作业结果设置为 NVM_REQ_RESTORED_FROM_ROM- [SWS_NvM_00279] [SWS_NvM_00288] 如果恢复机制失败，则错误 NVM_E_REQ_FAILED 报告给 DEM- 如果恢复机制失败，取决于配置： - [SWS_NvM_00451] [SWS_NvM_00359] [SWS_NvM_00213] 错误应由用户通过函数 NvM_GetErrorStatus 轮询（作业结果设置为 NVM_REQ_NOT_OK）- [SWS_NvM_00113] [SWS_NvM_00260] 错误应通过可配置回调 SingleBlockCallbackFunction 或 MultiBlockCallbackFunction 报告给用户 |
| 恢复 | - [SWS_NvM_00390] [SWS_NvM_00171] [SWS_NvM_00172] [SWS_NvM_00391] [SWS_NvM_00388] NVRAM Manager 控制错误恢复机制。恢复机制包括（如果已配置）"读取冗余块" 和 "读取 ROM 块" |
6.3.2.2.4 Application Software Component
参见 6.2.1.2.6 节中描述的 SWC 设计模式。
6.4 NVRAM 管理器层错误
6.4.1 NVM CRC 检查
6.4.1.1 概述
图 26：NVRAM 管理器 CRC 检查错误的信息路径
（信息流示意图：检测（NVM，1）→ 报告（2）→ 恢复（2）→ 如果失败，任务结果为 NVM_REQ_INTEGRITY_FAILED（3））
如果 NV 块配置了 CRC，NVRAM Manager 在读取操作结束时检查 RAM 块上是否存在 CRC 不匹配（1）。如果是，则 NVM_E_INTEGRITY_FAILED 错误报告给 DEM。恢复也启动："读取重试"、"读取冗余块" 和 "读取 ROM 块"（如果已配置）（2）。如果恢复动作意味着冗余丢失或使用 ROM 数据，NVRAM 管理器通过作业结果报告数据质量损失。针对冗余丢失报告 DEM 错误（参见冗余丢失）。如果恢复失败（3），则作业结果设置为 NVM_REQ_INTEGRITY_FAILED（4）。
6.4.1.2 模块的角色
6.4.1.2.1 NVRAM Manager
| 项目 | 内容 |
|---|---|
| 检测 | [SWS_NvM_00292] [SWS_NvM_00201] [SWS_NvM_00292] 在读取操作结束时请求 CRC 检查 |
| 反应 | N/A |
| 报告 | - [SWS_NvM_00470] [SWS_NvM_00546] 如果检测到冗余丢失，则作业结果设置为 NVM_REQ_REDUNDANCY_FAILED，并且 NVM_E_LOSS_OF_REDUNDANCY 错误报告给 DEM- [SWS_NvM_00470] 如果恢复期间使用 ROM 数据，则作业结果设置为 NVM_REQ_RESTORED_FROM_ROM- [SWS_NvM_00294] [SWS_NvM_00203] [SWS_NvM_00204] [SWS_NvM_00294] 如果发生 CRC 不匹配，NVM 将错误 NVM_E_INTEGRITY_FAILED 报告给 DEM，作业结果设置为 NVM_REQ_INTEGRITY_FAILED- 取决于配置： - [SWS_NvM_00451] [SWS_NvM_00295] [SWS_NvM_00204] 错误应由用户通过函数 NvM_GetErrorStatus 轮询- [SWS_NvM_00113] [SWS_NvM_00260] 错误应通过可配置回调 SingleBlockCallbackFunction 或 MultiBlockCallbackFunction 报告给用户 |
| 恢复 | [SWS_NvM_00390] [SWS_NvM_00171] [SWS_NvM_00172] [SWS_NvM_00391] [SWS_NvM_00388] [SWS_NvM_00526] [SWS_NvM_00293] NVRAM Manager 控制错误恢复机制。恢复机制包括（如果已配置）"读取重试"、"读取冗余块" 和 "读取 ROM 块" |
6.4.2 NVM 写入验证错误
6.4.2.1 概述
图 27：写入验证错误的信息路径
（信息流示意图：检测（NVM，1）→ 报告和恢复（2）→ 如果失败，报告 NVM_E_REQ_FAILED 给 DEM（3）→ 任务结果为 NVM_REQ_NOT_OK（4））
写入 NV 内存的 NVRAM 块立即被读回并与 RAM 中的原始内容进行比较（1）。如果验证失败，则 NVM_E_VERIFY_FAILED 错误报告给 DEM，并且恢复启动，使用写入重试（如果已配置）（2）。如果恢复失败（3），NVRAM 管理器将 NVM_E_REQ_FAILED 错误报告给 DEM，并将作业结果设置为 NVM_REQ_NOT_OK（4），参见 NVM API 请求失败。
6.4.2.2 模块的角色
6.4.2.2.1 NVRAM Manager
| 项目 | 内容 |
|---|---|
| 检测 | [SWS_NvM_00528] [SWS_NvM_00530] 写入 NV 内存的 NVRAM 块立即被读回并与 RAM 中的原始内容进行比较。注意：如果读回失败，则写入验证应失败，且不执行读取重试 |
| 反应 | N/A |
| 报告 | - [SWS_NvM_00528] 如果存在不匹配，则错误 NVM_E_VERIFY_FAILED 报告给 DEM- [SWS_NvM_00213] 如果恢复动作失败，作业结果设置为 NVM_REQ_NOT_OK，NVRAM 管理器将 NVM_E_REQ_FAILED 报告给 DEM（参见 NVM API 请求失败） |
| 恢复 | [SWS_NvM_00529] 如果写入验证失败，则执行写入重试 |
6.4.3 静态块检查错误
6.4.3.1 概述
图 28：静态块检查错误的信息路径
（信息流示意图：检测（NVM，1）→ 报告和恢复（2）→ 如果失败，报告 NVM_E_REQ_FAILED 给 DEM（3）→ 任务结果为 NVM_REQ_NOT_OK（4））
位于 NVRAM 管理器中的静态块 ID 检查机制提供了检测是否由于寻址问题而从 NV 内存读取了错误的块的方法。NVRAM Manager 每次将块写入 NV 内存时，将 NV 块头（包括静态块 ID）存储在 NV 块中。在读取操作期间，NV 头与请求的块 ID 进行比较（1）。如果静态块 ID 检查失败，则失败 NVM_E_WRONG_BLOCK_ID 报告给 DEM，并且读取恢复启动（"读取重试"、"读取冗余块" 和 "读取 ROM 块"，如果已配置）（2）。如果恢复动作意味着冗余丢失或使用 ROM 数据，NVRAM 管理器通过作业结果报告数据质量损失。针对冗余丢失报告 DEM 错误（参见冗余丢失）。如果恢复也失败（3），NVRAM 管理器将 NVM_E_REQ_FAILED 错误报告给 DEM，并将作业结果设置为 NVM_REQ_NOT_OK（4），参见 NVM API 请求失败。
6.4.3.2 模块的角色
6.4.3.2.1 NVRAM Manager
| 项目 | 内容 |
|---|---|
| 检测 | [SWS_NvM_00524] NVRAM 管理器检查存储在 NVRAM 块头中的块 ID |
| 反应 | N/A |
| 报告 | - [SWS_NvM_00470] [SWS_NvM_00546] 如果检测到冗余丢失，则作业结果设置为 NVM_REQ_REDUNDANCY_FAILED，并且 NVM_E_LOSS_OF_REDUNDANCY 错误报告给 DEM- [SWS_NvM_00470] 如果恢复期间使用 ROM 数据，则作业结果设置为 NVM_REQ_RESTORED_FROM_ROM- [SWS_NvM_00525] 错误 NVM_E_WRONG_BLOCK_ID 报告给 DEM- 如果恢复动作失败，作业结果设置为 NVM_REQ_NOT_OK，NVRAM 管理器将 NVM_E_REQ_FAILED 报告给 DEM（参见 NVM API 请求失败） |
| 恢复 | [SWS_NvM_00525] [SWS_NvM_00526] 如果静态块 ID 检查失败，则启动读取恢复（"读取重试"、"读取冗余块" 和 "读取 ROM 块"） |
6.4.4 冗余丢失
6.4.4.1 概述
图 29：冗余丢失错误的信息路径
（信息流示意图：检测（NVM，1）→ 恢复（2）→ 报告 NVM_E_LOSS_OF_REDUNDANCY 给 DEM（3）→ 任务结果为 NVM_REQ_REDUNDANCY_FAILED（4））
在读取或写入期间一个冗余块无效的情况下（1），NVRAM 管理器尝试使用未损坏的 NV 块的数据****立即恢复 NV 块（2）。如果恢复失败（3），则错误码 NVM_E_LOSS_OF_REDUNDANCY 报告给 DEM，并且 NVRAM 管理器将作业结果设置为 NVM_REQ_REDUNDANCY_FAILED（4）。
6.4.4.2 模块的角色
6.4.4.2.1 NVRAM Manager
| 项目 | 内容 |
|---|---|
| 检测 | [SWS_NvM_00531] NVRAM 管理器检测读取操作或写入操作期间的冗余丢失 |
| 反应 | N/A |
| 报告 | [SWS_NvM_00546] 如果恢复失败（参见下文），则错误码 NVM_E_LOSS_OF_REDUNDANCY 报告给 DEM。取决于配置：- [SWS_NvM_00451] [SWS_NvM_00470] 错误应由用户通过函数 NvM_GetErrorStatus 轮询（作业结果设置为 NVM_REQ_REDUNDANCY_FAILED）- [SWS_NvM_00113] [SWS_NvM_00260] 错误应通过可配置回调 SingleBlockCallbackFunction 或 MultiBlockCallbackFunction 报告给用户 |
| 恢复 | [SWS_NvM_00531] 尝试使用未损坏的 NV 块的数据****立即恢复 NV 块 |
6.4.4.2.2 Application Software Component
参见 6.2.1.2.6 节中描述的 SWC 设计模式。
6.4.5 NVM API 请求失败
6.4.5.1 概述
图 30：NVM API 请求失败的信息路径
（信息流示意图：检测（NVM 通过写验证、静态块检查、Config ID 不匹配，1）→ 恢复（NVM，2）→ 如果失败，报告 NVM_E_REQ_FAILED 给 DEM（3）→ 任务结果为 NVM_REQ_NOT_OK（4））
NVRAM 管理器被通知后续层在 NVM 函数处理过程中检测到的错误，或通过内部检测机制（写验证、静态块检查、Config ID 不匹配）检测到的错误（1）。
根据所涉及函数的类型（写入或读取），NVRAM 管理器层有不同的恢复机制可用（2）。如果可用的恢复机制失败（3），NVM 管理器将 NVM_E_REQ_FAILED 错误报告给 DEM，并将作业结果设置为 NVM_REQ_NOT_OK（4）。
6.4.5.2 模块的角色
6.4.5.2.1 NVRAM Manager
| 项目 | 内容 |
|---|---|
| 检测 | [SWS_NvM_00275] [SWS_NvM_00305] [SWS_NvM_00361] [SWS_NvM_00302] [SWS_NvM_00296] [SWS_NvM_00023] [SWS_NvM_00359] [SWS_NvM_00213] [SWS_NvM_00271] NVRAM 管理器被通知在 NVM 函数（NvM_ReadAll、NvM_InvalidateNvBlock、NvM_WriteAll、NvM_ReadBlock、NvM_WriteBlock、NvM_EraseNvBlock）处理过程中后续层检测到的错误 |
| 反应 | N/A |
| 报告 | - [SWS_NvM_00213] [SWS_NvM_00296] [SWS_NvM_00279] [SWS_NvM_00288] 如果恢复机制失败（参见下文），则错误 NVM_E_REQ_FAILED 报告给 DEM- 取决于配置： - [SWS_NvM_00451] [SWS_NvM_00295] [SWS_NvM_00204] 错误应由用户通过函数 NvM_GetErrorStatus 轮询（作业结果设置为 NVM_REQ_NOT_OK）- [SWS_NvM_00113] [SWS_NvM_00260] 错误应通过可配置回调 SingleBlockCallbackFunction 或 MultiBlockCallbackFunction 报告给用户 |
| 恢复 | [SWS_NvM_00168] [SWS_NvM_00213] [SWS_NvM_00296] [SWS_NvM_00390] [SWS_NvM_00171] [SWS_NvM_00172] [SWS_NvM_00391] [SWS_NvM_00388] NVRAM Manager 控制错误恢复机制。恢复动作取决于正在进行的操作的类型：写入操作、读取操作或其他。对于读取操作，恢复机制包括（如果已配置）"读取重试"、"读取冗余块" 和 "读取 ROM 块"。对于写入操作，恢复机制是（如果已配置）"写入重试" |
6.4.5.2.2 Application Software Component
| 项目 | 内容 |
|---|---|
| 检测 | 如果错误处理策略的设计需要，SWC 可以以两种不同的方式设计：- 它通过连接到 NVM 的客户端端口上的 GetErrorStatus 操作轮询作业状态- 它提供连接到 NvMNotifyJobFinished 服务器端口的服务器 runnables，该端口应由 NVM 调用。参见 Autosar_SWS_NVRAMManager.pdf 的章节 13.3.1.3 端口接口 和 13.3.2 通知的端口和端口接口 |
翻译说明
- 本文档为说明性文档（EXP），描述了 AUTOSAR 基础软件中的标准错误及其处理机制
- 第 4 章描述通用错误处理机制：DEM/DET/FIM/RTE 的角色
- 第 5 章涵盖通信相关错误（CAN 栈）：Bus Off、Controller Timeout、传输缓冲区满、接收 DLC 错误、COM RX/TX 截止时间监控、CAN TP 错误、CAN NM 错误、PDU 复制/计数器错误、客户端/服务器超时
- 第 6 章涵盖NVRAM 相关错误：Flash/EEPROM 作业错误、硬件 ID 不匹配、FEE/EA 一致性检查、CRC 检查、写验证、静态块检查、冗余丢失、API 请求失败
- 主要 AUTOSAR 模块：
Dem、Det、Fim、Can、CanIf、CanSM、CanTp、CanNm、ComM、BswM、Com、Dcm、PduR、Fls、Fee、Eep、Ea、MemIf、NvM - 主要 API：
Dem_SetEventStatus、Det_ReportRuntimeError、Det_ReportTransientFault、Fim_GetFunctionPermission、Fim_DemTriggerOnEventStatus、CanIf_ControllerBusOff、CanSm_ControllerBusOff、BswM_CanSM_CurrentState、ComM_BusSM_ModeIndication、Fls_GetJobResult、Fee_JobErrorNotification、Eep_GetJobResult、MemIf_GetJobResult、NvM_GetErrorStatus、NvM_JobErrorNotification、SingleBlockCallbackFunction、MultiBlockCallbackFunction - 主要错误标识符（保留英文）：
CANSM_E_BUS_OFF、CANSM_E_MODE_REQUEST_TIMEOUT、CANIF_E_INVALID_DATA_LENGTH、CANTP_E_TX_COM、CANTP_E_RX_COM、CANTP_E_COM、FLS_E_WRITE_FAILED、FLS_E_ERASE_FAILED、FLS_E_READ_FAILED、FLS_E_COMPARE_FAILED、FLS_E_UNEXPECTED_FLASH_ID、EEP_E_WRITE_FAILED、EEP_E_ERASE_FAILED、EEP_E_READ_FAILED、EEP_E_COMPARE_FAILED、NVM_E_INTEGRITY_FAILED、NVM_E_VERIFY_FAILED、NVM_E_WRONG_BLOCK_ID、NVM_E_LOSS_OF_REDUNDANCY、NVM_E_REQ_FAILED - 主要作业结果（保留英文）：
MEMIF_JOB_FAILED、MEMIF_BLOCK_INCONSISTENT、NVM_REQ_NOT_OK、NVM_REQ_INTEGRITY_FAILED、NVM_REQ_REDUNDANCY_FAILED、NVM_REQ_RESTORED_FROM_ROM - DEM 状态（保留英文）：
DEM_EVENT_STATUS_FAILED、DEM_EVENT_STATUS_PREFAILED、DEM_EVENT_STATUS_PASSED、DEM_EVENT_STATUS_PREPASSED - 控制器模式（保留英文）：
CANIF_CS_STARTED、CANIF_CS_STOPPED、CAN_T_STARTED - PduR 模式（保留英文）：
CANIF_SET_TX_OFFLINE、CANIF_SET_TX_ONLINE - ComM 模式（保留英文）：
COMM_SILENT_COMMUNICATION、COMM_NO_COMMUNICATION、COMM_FULL_COMMUNICATION - 通信模式（保留英文）：
CANSM_BSWM_NO_COMMUNICATION、CANSM_BSWM_SILENT_COMMUNICATION、CANSM_BSWM_BUS_OFF - 全部需求 ID 保留英文：
SWS_xxx、ECUC_xxx、DEMxxx、FLSxxx、MemIfxxx等 - 失效模式标记 CH01-CH11（CAN）和 FM01-FM05（NVRAM）保留英文
翻译：opencode-translator / Step 3 P0 批量翻译