# 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. [目的](#1-目的)
2. [与其他文档的关系](#2-与其他文档的关系)
3. [文档导读](#3-文档导读)
4. [通用机制](#4-通用机制)
5. [通信相关错误](#5-通信相关错误)
6. [NVRAM 相关错误](#6-nvram-相关错误)
---
## 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_`（或 `Rte_COMCbkRxTOut_`）**通知**（参见上面的 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_`（或 `Rte_COMCbkTxTOut_`?） |
| **反应** | 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 批量翻译*