# 内存硬件抽象层需求规范

> **文档标题**: Requirements on Memory Hardware Abstraction Layer
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 116
> **文档类型**: SRS (Software Requirements Specification)

---

## 文档标识

| 项目 | 内容 |
|------|------|
| Document Title | Requirements on Memory Hardware Abstraction Layer |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 116 |
| Document Status | Final |
| Part of AUTOSAR Standard | Classic Platform |
| Part of Standard Release | 4.4.0 |

---

## 文档变更历史

| 日期 | 版本 | 变更者 | 变更描述 |
|------|------|--------|----------|
| 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 | 需求与 BSW 特性关联 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 需求与 BSW 特性关联 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 编辑性修订 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 对需求追溯进行形式化重做;按 TPS_STDT_00078 重做需求;关联 BSW & RTE 特性 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 法律免责声明修订 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 文档元信息扩充;小幅排版调整 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | "用户须知"修订;增加"版本信息" |
| 2006-11-28 | 2.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始版本发布 |

---

## 目录

1. [文档范围](#1-文档范围)
2. [如何阅读本文档](#2-如何阅读本文档)
3. [缩略语](#3-缩略语)
4. [功能概述](#4-功能概述)
5. [需求追溯](#5-需求追溯)
6. [需求规范](#6-需求规范)
   - 6.1 [功能性需求](#61-功能性需求)
   - 6.2 [非功能性需求(质量)](#62-非功能性需求质量)
7. [参考文献](#7-参考文献)

---

## 1 文档范围

本文档规定了构成内存硬件抽象层(Memory Hardware Abstraction Layer, MemHwA)的模块的需求。下图展示了内存硬件抽象层的架构与上下文。

```
NVRAM Manager
    │
    ▼
Memory Hardware Abstraction
    ├── Memory Abstraction Interface (MemIf)
    │       │
    │       ▼
    ├── Flash EEPROM Emulation (FEE)        ─── ▶ Flash Driver
    └── EEPROM Abstraction (EA)             ─── ▶ EEPROM Driver
                                                  ↕
                                           Vendor Specific Library
```
*图 1:内存硬件抽象层的组件与接口*

**EEPROM Abstraction (EA)** 模块应抽象出底层 EEPROM 驱动的寻址方案,并提供统一的寻址方案。它还应允许可配置的"虚拟无限"擦/写周期数。这样,如果底层 EEPROM 驱动和器件改变,无需更改上层(NVRAM 管理器)。

**Flash EEPROM Emulation (FEE)** 模块应抽象出底层 Flash 驱动的寻址方案,并提供统一的寻址方案以及可配置的"虚拟无限"擦/写周期数。这样,如果底层 Flash 驱动和器件改变,无需更改上层(NVRAM 管理器)。

驱动接口层(EEPROM 与 Flash 接口)已被略去,以允许 FEE/EA 模块的高效实现。FEE 和 EA 直接对接底层内存驱动。为那些接口层制定的需求改为适用于 Memory Abstraction Interface。

**Memory Abstraction Interface (MemIf)** 应替代驱动接口层(EEPROM 与 Flash 接口),允许 NVRAM 管理器访问多个内存抽象模块(FEE 与 EA 模块)。

可使用厂商特定库代替 FEE/Flash 驱动 和/或 EA/EEPROM 驱动的组合,以提供与那些内存抽象模块相同的功能和 API。只要功能和 API 受支持,这类库的内部实现无关紧要。当厂商库替换所有所需的 FEE 和 EA 模块时,Memory Abstraction Interface 应仅为一组宏。

---

## 2 如何阅读本文档

### 2.1 使用的约定

关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 按 IETF 风格解读。AUTOSAR 文档中需求的表示形式遵循 [5] 中规定的表格格式。

### 2.2 需求结构

**功能性需求**:配置、初始化、正常运行、关机运行、故障运行、……
**非功能性需求**:时序需求、资源使用、易用性、为其他工作包提供的输出、……

---

## 3 缩略语

| 缩略语 | 描述 |
|--------|------|
| (Logical) Block(逻辑块) | 可由模块用户单独寻址的连续内存区域(用于读/写/擦/比较操作)。块大小可静态配置(预编译时)。 |
| Page(页) | 一次可写入的最小内存量。 |
| Sector(扇区) | 一次可擦除的最小内存量。 |
| FEE | Flash EEPROM Emulation(Flash EEPROM 仿真) |
| EA | EEPROM Abstraction Layer(EEPROM 抽象层) |
| MemIf | Memory Abstraction Interface(内存抽象接口) |

---

## 4 功能概述

### 4.1 EEPROM 抽象层

EEPROM Abstraction Layer (EA) 应扩展 EEPROM 驱动,为上层提供线性地址空间上的虚拟分段和"虚拟无限"的擦/写周期数。除此之外,它应提供与 EEPROM 驱动相同的功能。

### 4.2 Flash EEPROM 仿真

Flash EEPROM Emulation (FEE) 应在 Flash 内存技术上仿真 EEPROM 抽象层的行为。因此它应具有与 EEPROM 抽象层相同的功能范围和 API,并允许基于底层 Flash 驱动和 Flash 器件的类似配置。

### 4.3 内存抽象接口

Memory Abstraction Interface (MemIf) 应抽象出底层 FEE 或 EA 模块的数量,并为上层提供统一线性地址空间上的虚拟分段。

---

## 5 需求追溯

| 需求 | 描述 | 满足者 |
|------|------|--------|
| RS_BFR_01816 | - | SRS_MemHwAb_14013, 14026 |
| RS_BRF_00129 | AUTOSAR 应支持数据损坏检测与保护 | SRS_MemHwAb_14014, 14015, 14016 |
| RS_BRF_01000 | AUTOSAR 架构应将 BSW 组织为硬件无关层和硬件相关层 | SRS_MemHwAb_14017, 14018, 14019, 14022, 14024 |
| RS_BRF_01800 | AUTOSAR 非易失存储器功能应划分为硬件相关层和硬件无关层 | SRS_MemHwAb_14017, 14018, 14019, 14022, 14024 |
| RS_BRF_01808 | AUTOSAR 非易失存储器处理应支持不同种类的存储器硬件 | SRS_MemHwAb_14019, 14020, 14021 |
| RS_BRF_01812 | AUTOSAR 非易失存储器功能应支持作业的优先级化和异步执行 | SRS_MemHwAb_14031 |
| RS_BRF_01816 | AUTOSAR 非易失存储器功能应基于逻辑内存块组织持久数据 | SRS_MemHwAb_14001, 14002, 14010, 14028, 14029, 14032 |
| RS_BRF_01832 | AUTOSAR 非易失存储器应独立于物理地址处理逻辑内存块 | SRS_MemHwAb_14005, 14006, 14007, 14009 |
| RS_BRF_01840 | AUTOSAR 非易失存储器功能应保护内存块的完整性 | SRS_MemHwAb_14014, 14015, 14016 |
| RS_BRF_01848 | AUTOSAR 非易失存储器功能应提供增强硬件可靠性的机制 | SRS_MemHwAb_14002, 14012 |
| RS_BRF_01850 | AUTOSAR 非易失存储器功能应能应对硬件寿命约束 | SRS_MemHwAb_14002, 14012 |
| RS_BRF_02040 | AUTOSAR BSW 与 RTE 应确保数据一致性 | SRS_MemHwAb_14015 |
| RS_BRF_02232 | AUTOSAR 应支持具有运行时断言检查的开发 | SRS_MemHwAb_14023 |

---

## 6 需求规范

### 6.1 功能性需求

#### 6.1.1 内存抽象模块

##### 6.1.1.1 配置

###### 6.1.1.1.1 [SRS_MemHwAb_14001] FEE 和 EA 模块应允许配置逻辑块起始/结束地址的对齐

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | FEE 和 EA 模块应允许配置逻辑块起始与结束地址的对齐。配置工具应使用此配置参数,根据块起始地址生成块编号。 |
| 理由 | 1) 通过将逻辑块对齐到底层物理内存技术,简化 FEE 和 EA 模块内的块处理。2) 允许 FEE 和 EA 模块计算块起始地址,而非要求查找表将逻辑地址映射到物理地址。 |
| 用例 | 1) Freescale Star12 具有 4 字节扇区和 2 字节页大小的内部 EEPROM。通过将块起始与结束地址对齐到 4 字节边界,可简化块处理,不再需要读-修改-写行为。2) 示例:地址对齐设置为 4(字节)。第一个逻辑块编号 1,起始地址 0。块大小 22 字节,因此占用 6 个 4 字节"页"。下一个逻辑块编号应不是 2 而是 7,从而允许内存抽象模块推断其起始地址为 24((块编号-1) * 页大小)。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01816)

###### 6.1.1.1.2 [SRS_MemHwAb_14002] FEE 和 EA 模块应允许为每个逻辑块配置所需的写周期数

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | FEE 和 EA 模块应允许为每个逻辑块配置所需的写周期数。 |
| 理由 | 抽象出底层物理器件的硬件属性。 |
| 用例 | 一个外部 Flash 器件规定每擦除单元 10,000 次擦除周期。配置的逻辑块需要 50,000 次擦除周期。FEE 必须确保此逻辑块可写入 50,000 次,同时任何 Flash 单元的擦除次数不得超过 10,000 次。 |
| 依赖 | [SRS_MemHwAb_14012] 写访问的分散 |
| 支持材料 | -- |
⌋(RS_BRF_01848, RS_BRF_01850, RS_BRF_01816)

###### 6.1.1.1.3 [SRS_MemHwAb_14026] 块编号 0x0000 和 0xFFFF 不应使用

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 块编号 0x0000 和 0xFFFF 不应由内存抽象模块使用 / 配置工具生成。 |
| 理由 | 这些数字无法与 Flash 或 EEPROM 器件的已擦除值区分。 |
| 用例 | 实现将块编号存储在非易失存储器中,例如标记逻辑块的起始或结束。当使用这些数字时,该标记将无法被找到/与空 EEPROM 或 Flash 内存区分。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BFR_01816)

##### 6.1.1.2 初始化

无附加需求,适用 SPAL SRS 通用章节关于初始化的"标准"需求。

##### 6.1.1.3 正常运行

###### 6.1.1.3.1 [SRS_MemHwAb_14005] FEE 和 EA 模块应为上层提供 32 位虚拟地址空间

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash EEPROM Emulation (FEE) 和 EEPROM Abstraction (EA) 应为上层提供 32 位虚拟地址空间。<br><br>这些 32 位虚拟(逻辑)地址应由 16 位逻辑块标识符和该逻辑块内 16 位地址偏移组成。因此,内存抽象层应支持每个底层物理器件(理论上)65534 个逻辑(可区分)块。每个块可有(理论上)64 KB 的大小。 |
| 理由 | 抽象出会要求在底层器件/驱动改变时变更 NVRAM 管理器的硬件属性。 |
| 用例 | 1) 支持具有大量小块的系统;2) 支持具有少量大块的系统,如 MMI 系统(字体、语音)或导航(地图、路线);3) 允许 NVRAM 管理器在逻辑块标识符中编码块管理信息(如块类型,通过使其足够大)。 |
| 依赖 | [SRS_MemHwAb_14026] 不使用特定块编号 |
| 支持材料 | 图 2:虚拟与物理地址空间 |
⌋(RS_BRF_01832)

###### 6.1.1.3.2 [SRS_MemHwAb_14006] 块擦除或写操作的起始地址应始终对齐到虚拟 64K 边界

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 块擦除或写操作的起始地址应始终对齐到虚拟 64K 边界。<br><br>换言之:对于块擦除/写请求,偏移应被忽略,每个块擦除/写请求从地址偏移 0 开始。 |
| 理由 | 如果虚拟 64K 边界映射到物理扇区/页边界,允许底层仿真模块和驱动中的优化擦除/写操作。 |
| 用例 | FEE 和 EA 的优化,简化配置和实现。 |
| 依赖 | -- |
| 支持材料 | 明确:不能仅擦除或写入已配置块的一部分,要么全部,要么什么都不做。 |
⌋(RS_BRF_01832)

###### 6.1.1.3.3 [SRS_MemHwAb_14007] 读取块的起始地址和长度不应限制为特定对齐

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 读取块的起始地址和长度不应限制为特定对齐,即应可能从任何内存地址开始读取一个字节。 |
| 理由 | Flash/EEPROM 的按字节读取。 |
| 用例 | NVRAM 管理器中的 CRC 计算。 |
| 依赖 | -- |
| 支持材料 | 这允许分多次读取逻辑块,例如 CRC 计算所需。如果某些硬件属性要求读地址对齐(如仅 32 位对齐读取可能),应由底层驱动处理。此需求允许 NVRAM 管理器对逻辑块进行按字节读访问,但并不要求 NVRAM 管理器必须这样做。 |
⌋(RS_BRF_01832)

###### 6.1.1.3.4 [SRS_MemHwAb_14009] FEE 和 EA 模块应提供逻辑线性地址与物理内存地址之间的转换

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | FEE 和 EA 模块应在逻辑线性地址和用于访问底层 Flash 内存或 EEPROM 的地址之间提供明确的转换。 |
| 理由 | 物理器件和逻辑块的起始地址应从逻辑块标识符派生。 |
| 用例 | 逻辑块到多个物理非易失存储设备的透明映射。 |
| 依赖 | -- |
| 支持材料 | 通过该转换获得的内存地址是相对于 Flash 和 EEPROM 驱动规范中描述的器件特定基地址的地址偏移。 |
⌋(RS_BRF_01832)

###### 6.1.1.3.5 [SRS_MemHwAb_14010] FEE 和 EA 模块应提供仅操作完整已配置逻辑块的写服务

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | FEE 和 EA 模块应提供仅操作完整已配置逻辑块的写服务。 |
| 理由 | 将上层与驱动内部解耦。 |
| 用例 | 上层只需对 Memory Abstraction Interface 进行一次调用,即可将逻辑块写入非易失存储器。如果需要多次操作才能写入所有寻址的内存区域,应在 FEE 或 EA 模块内或底层器件驱动中内部处理。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01816)

###### 6.1.1.3.6 [SRS_MemHwAb_14029] FEE 和 EA 模块应提供允许读取逻辑块全部或部分的读服务

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | FEE 和 EA 模块应提供允许读取逻辑块全部或部分的读服务。 |
| 理由 | 允许读取 NV 内存。 |
| 用例 | NVRAM 管理器的读功能。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01816)

###### 6.1.1.3.7 [SRS_MemHwAb_14031] FEE 和 EA 模块应提供允许取消正在进行的异步操作的服务

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | FEE 和 EA 模块应提供允许取消正在进行的异步操作(如读、写、擦或比较操作)的服务。 |
| 理由 | 写入"立即数据"所需。 |
| 用例 | 立即数据(崩溃数据)必须写入,而当前正在进行读操作。 |
| 依赖 | [SRS_MemHwAb_14013] 写入"立即"数据不得延迟 |
| 支持材料 | -- |
⌋(RS_BRF_01812)

###### 6.1.1.3.8 [SRS_MemHwAb_14028] FEE 和 EA 模块应提供使逻辑块无效化的服务

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | FEE 和 EA 模块应提供使逻辑块无效化的服务。这应通过适当设置模块内部块管理数据来完成。<br>注:擦除物理内存内容是实现选项但非必需。 |
| 理由 | 使上层能够将数据块标记为无效。 |
| 用例 | 当物理擦除数据不可能或不可取(如 Flash 内存技术上)时,允许应用将数据标记为过时或不再有效。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01816)

###### 6.1.1.3.9 [SRS_MemHwAb_14012] 写访问的分散

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 如果为逻辑块配置的写周期数超过底层物理器件提供的数量,FEE 或 EA 模块必须提供足够的机制,将该逻辑块的写请求分散到更大的内存区域。 |
| 理由 | 允许"无限"写周期数,同时防止内存单元的擦除次数超过硬件厂商规定的次数。 |
| 用例 | 一个外部 Flash 器件规定每擦除单元 10,000 次擦除周期。配置的逻辑块需要 50,000 次写周期。FEE 必须确保此逻辑块可写入 50,000 次,同时任何 Flash 单元的擦除次数不得超过 10,000 次。 |
| 依赖 | [SRS_MemHwAb_14002] 所需写周期数配置 |
| 支持材料 | 此需求替换 MemSvc SRS 中的 [BSW032] 写访问分散和 [SRS_LIBS_08530] NVRAM 块类型 – 漫游。 |
⌋(RS_BRF_01848, RS_BRF_01850)

###### 6.1.1.3.10 [SRS_MemHwAb_14013] 立即数据的写入不得因内部管理操作或被写入内存区域的擦除而延迟

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 立即数据的写入不得因内部管理操作或被写入内存区域的擦除而延迟。<br>如果在必须写入立即数据时正在进行内部管理操作,必须中断它们,直到数据已写入非易失存储器。<br><br>必须始终有一个预擦除的内存区域可用于写入立即数据。 |
| 理由 | 立即数据必须立即写入(这就是其名称的含义),即与底层硬件允许的速度一样快。 |
| 用例 | 当需要写入崩溃数据时,FEE 正在重组当前存储在 Flash 中的块。 |
| 依赖 | 如果正在进行的硬件访问(如擦除操作)不能被中止,其运行时间必须作为立即写操作的最大允许延迟。 |
| 支持材料 | -- |
⌋(RS_BFR_01816)

###### 6.1.1.3.11 [SRS_MemHwAb_14032] FEE 和 EA 模块应提供仅操作包含立即数据的完整逻辑块的擦除服务

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | FEE 和 EA 模块应提供仅操作包含立即数据的完整逻辑块的擦除服务。 |
| 理由 | SRS_MemHwAb_14013 需要预擦除内存,因此这些内存区域必须以某种方式可擦除。 |
| 用例 | -- |
| 依赖 | [SRS_MemHwAb_14013] 写入"立即"数据不得延迟 |
| 支持材料 | - 此服务只应由特殊应用(如诊断)调用。<br>- 一种可能的实现是使包含立即数据的块无效化,随后强制重组块。重组期间无效块不应复制到新的内存位置,因此立即数据的内存区域将(保持)擦除状态。 |
⌋(RS_BRF_01816)

##### 6.1.1.4 关机操作

内存抽象层的模块不需要任何关机能力(Flash 或 EEPROM 驱动中也没有关机能力)。

##### 6.1.1.5 故障操作

###### 6.1.1.5.1 [SRS_MemHwAb_14014] FEE 和 EA 模块应检测因中止/中断的写操作可能导致的数据不一致

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | FEE 和 EA 模块应检测因中止/中断的写操作可能导致的数据不一致。 |
| 理由 | "用户"不应使用不一致数据,因此必须识别。 |
| 用例 | 1) 写操作因断电而中断,上电复位后,在下次对受影响内存区域的读访问时应检测到可能的数据不一致。2) 写操作被上层取消。下次对受影响内存区域的读访问时应检测到可能的数据不一致。 |
| 依赖 | -- |
| 支持材料 | 取决于实现、物理器件和发生中断的写操作时间点,FEE 或 EA 模块可能能够确定操作已失败,但无法确定哪个块本应被写入。 |
⌋(RS_BRF_00129, RS_BRF_01840)

###### 6.1.1.5.2 [SRS_MemHwAb_14015] FEE 和 EA 模块应报告可能的数据不一致

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | FEE 和 EA 模块应仅一次向 DEM 报告因中止/中断的写操作导致的可能数据不一致。之后,不一致的内存区域必须被标记,使得不再为该块报告进一步的错误。 |
| 理由 | 避免每次块读操作中错误报告的"无限循环"。 |
| 用例 | 写操作被中断或取消,在下次对受影响内存区域的读访问时检测并报告不一致。 |
| 依赖 | [SRS_MemHwAb_14014] 数据不一致检测 |
| 支持材料 | 取决于实现和发生中断的写操作时间点,FEE 或 EA 模块可能能够确定操作已失败,但无法确定哪个块本应被写入。这种情况下,对该块的读操作可能向调用方返回旧(过时)数据(如果存在此类数据)。如果应用不希望这样,必须在覆盖前显式使该块无效化。 |
⌋(RS_BRF_00129, RS_BRF_01840, RS_BRF_02040)

###### 6.1.1.5.3 [SRS_MemHwAb_14016] FEE 和 EA 模块不应将不一致数据返回给调用方

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | FEE 和 EA 模块不应将不一致数据返回给调用方。 |
| 理由 | "用户"不应使用不一致数据。 |
| 用例 | 写操作被中断或取消,因此该块的数据不一致。在下次对该块的读访问时检测到此不一致,数据不应返回给调用方。 |
| 依赖 | [SRS_MemHwAb_14014] 数据不一致检测 |
| 支持材料 | 为不一致块提供默认数据是 NVRAM 管理器的工作。 |
⌋(RS_BRF_00129, RS_BRF_01840)

#### 6.1.2 内存抽象接口

以下需求已从 SPAL SRS 关于内存抽象的部分接管,并已(仅在措辞上)适配图 1 所示的架构概念。

##### 6.1.2.1 通用

###### 6.1.2.1.1 [SRS_MemHwAb_14019] 内存抽象接口应提供对底层内存抽象模块 API 服务的统一访问

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 内存抽象接口应为 NVRAM 管理器内使用所需的、底层内存抽象模块的 API 服务提供统一访问。<br>进一步说明:初始化例程和作业处理函数不由内存抽象接口映射。 |
| 理由 | 通过一个统一接口允许使用内存抽象模块。 |
| 用例 | 允许上层无差别地访问内部和外部内存设备。 |
| 依赖 | -- |
| 支持材料 | 此需求应替换 [BSW12172]。 |
⌋(RS_BRF_01000, RS_BRF_01800, RS_BRF_01808)

###### 6.1.2.1.2 [SRS_MemHwAb_14020] 内存抽象接口应允许使用设备索引选择底层内存抽象模块

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 内存抽象接口应允许使用设备索引选择底层内存抽象模块(FEE 或 EA 模块)。 |
| 理由 | NVRAM 管理器的需求 |
| 用例 | NVRAM 管理器使用设备索引选择适当的内存抽象模块。 |
| 依赖 | -- |
| 支持材料 | SWS NVRAM Manager。此需求应替换 [BSW12173]。 |
⌋(RS_BRF_01808)

##### 6.1.2.2 配置

###### 6.1.2.2.1 [SRS_MemHwAb_14021] 内存抽象接口应允许预编译时配置底层内存抽象模块的数量

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 内存抽象接口应允许预编译时配置底层内存抽象模块的数量。 |
| 理由 | 灵活性 |
| 用例 | 一个 ECU 仅使用内部 EEPROM(因此需要一个 EA 模块),另一个 ECU 同时使用内部和外部 EEPROM(因此需要两个 EA 模块)。 |
| 依赖 | -- |
| 支持材料 | WP Architecture。此需求应替换 [BSW12174]。 |
⌋(RS_BRF_01808)

##### 6.1.2.3 正常运行

###### 6.1.2.3.1 [SRS_MemHwAb_14022] 内存抽象接口应保留底层内存抽象模块的功能

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 内存抽象接口应保留底层内存抽象模块的功能。它不应提供附加功能。 |
| 理由 | 简单性、效率 |
| 用例 | 内存抽象模块抽象出所有硬件属性,内存抽象接口无需添加任何内容(仅在需要访问多个内存抽象模块时才需要)。 |
| 依赖 | -- |
| 支持材料 | 此需求应替换 [BSW12175]。 |
⌋(RS_BRF_01000, RS_BRF_01800)

##### 6.1.2.4 故障操作

###### 6.1.2.4.1 [SRS_MemHwAb_14023] 内存抽象接口应仅检查接口本身内使用的参数

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 内存抽象接口应仅检查接口本身内使用且不传递给底层内存抽象模块的参数。 |
| 理由 | 简单性、效率:避免参数的双重检查。 |
| 用例 | 设备索引可以被检查(取决于开发错误检测开关的设置)。块地址不应被检查。 |
| 依赖 | -- |
| 支持材料 | 此需求应替换 [BSW12176]。 |
⌋(RS_BRF_02232)

#### 6.1.3 板载设备抽象

板载设备抽象适用与内存硬件抽象相同的需求。板载设备抽象的一个成员是看门狗接口。

### 6.2 非功能性需求(质量)

#### 6.2.1 内存抽象模块

##### 6.2.1.1 [SRS_MemHwAb_14017] EA 模块应扩展 EEPROM 驱动的功能范围

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | EEPROM Abstraction Layer (EA) 应扩展 EEPROM 驱动的功能范围。除 EEPROM 驱动的属性外,EA 应工作于 32 位虚拟地址空间,并应完全抽象出底层器件给出的擦/写周期限制。 |
| 理由 | 所有 EEPROM 器件的统一处理。 |
| 用例 | 如果底层 EEPROM 驱动和器件改变,NVRAM 管理器无需改变。 |
| 依赖 | -- |
| 支持材料 | AUTOSAR SRS EEPROM driver |
⌋(RS_BRF_01000, RS_BRF_01800)

##### 6.2.1.2 [SRS_MemHwAb_14018] FEE 模块应扩展内部 Flash 驱动的功能范围

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash EEPROM Emulation (FEE) 应扩展内部 Flash 驱动的功能范围。它应具有与 EA 模块相同的功能范围和 API。 |
| 理由 | 所有 Flash 器件的统一处理。 |
| 用例 | 如果底层 Flash 驱动和器件改变,NVRAM 管理器无需改变。 |
| 依赖 | [SRS_MemHwAb_14017] EEPROM 抽象层的范围 |
| 支持材料 | AUTOSAR SRS EEPROM driver; AUTOSAR SRS Flash driver |
⌋(RS_BRF_01000, RS_BRF_01800)

#### 6.2.2 内存抽象接口

##### 6.2.2.1 时序需求

###### 6.2.2.1.1 [SRS_MemHwAb_14024] 内存抽象接口应保留底层内存抽象模块及其 API 的时序行为

⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 内存抽象接口应通过将内存抽象接口 API 1:1 映射到内存抽象模块的 API,保留底层内存抽象模块及其 API 的时序行为。 |
| 理由 | 简单性、效率 |
| 用例 | 示例:内存抽象接口的写服务直接映射到底层内存抽象模块(FEE 或 EA)的写服务。 |
| 依赖 | -- |
| 支持材料 | WP Architecture。此需求应替换 [BSW12177]。 |
⌋(RS_BRF_01000, RS_BRF_01800)

#### 6.2.3 板载设备抽象

板载设备抽象适用与内存硬件抽象相同的需求。板载设备抽象的一个成员是看门狗接口。

---

## 7 参考文献

### 7.1 AUTOSAR 交付物

[1] List of Basic Software Modules
    AUTOSAR_TR_BSWModuleList.pdf

[2] Layered Software Architecture
    AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf

[3] General Requirements on Basic Software Modules
    AUTOSAR_SRS_BSWGeneral.pdf

[4] General Requirements on SPAL
    AUTOSAR_SRS_SPALGeneral.pdf

[5] Software Standardization Template
    AUTOSAR_TPS_StandardizationTemplate.pdf

### 7.2 相关标准与规范

无

---

## 翻译说明

- 本文档完整翻译自 AUTOSAR_SRS_MemoryHWAbstractionLayer v4.4.0(Document ID 116)。
- 保留所有需求 ID(SRS_MemHwAb_xxxxx、RS_BRF_xxxxx)。
- 保留 AUTOSAR 方框符 ⌈⌋。
- 模块缩写(FEE、EA、MemIf、NVRAM 等)保持英文。