feifei.xu/autosar_standard_spec_v4.4
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

P2 batch translation: 49 PDFs (Memory + Safety + Crypto + ModeManagement + IO)

Browse Source
This commit is contained in:
opencode-translator
2026-06-13 10:04:28 +08:00
parent 6f293acbf7
commit 784f11ab73
50 changed files with 36262 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Crypto/AUTOSAR_EXP_UtilizationOfCryptoServices.md
+264
View File
@@ -0,0 +1,264 @@
# 加密服务的使用 (Utilization of Crypto Services)
**AUTOSAR CP Release 4.4.0**
> 翻译说明：本文档为 AUTOSAR 经典平台 (CP) Release 4.4.0 中 EXP 文档 602《加密服务的使用》的中文翻译版本。原始英文文档中的 AUTOSAR 方框符 `⌈⌋`、API 标识符（如 `Crypto_ProcessJob`）、模块缩写（Crypto、CryIf、Csm、KeyM 等）、加密算法名（AES、SHA、RSA、ECC 等）以及文档交叉引用均予以保留。
## 文档标识
| 项目 | 内容 |
|---|---|
| 文档标题 (Document Title) | 加密服务的使用 (Utilization of Crypto Services) |
| 文档所有者 (Document Owner) | AUTOSAR |
| 文档责任方 (Document Responsibility) | AUTOSAR |
| 文档标识号 (Document Identification No) | 602 |
| 文档状态 (Document Status) | Final |
| 所属 AUTOSAR 标准 | Classic Platform |
| 所属标准版本 (Part of Standard Release) | 4.4.0 |
## 文档变更历史 (Document Change History)
| 日期 | 版本 | 变更者 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 移除对 Crypto Abstraction Library 的引用；编辑性修订 |
| 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-03-15 | 4.1.1 | AUTOSAR Administration | 初始发布 |
---
## 目录 (Table of Contents)
- [1 引言](#1-引言)
- [1.1 文档目的](#11-文档目的)
- [1.2 文档范围](#12-文档范围)
- [1.3 限制](#13-限制)
- [2 缩略语和缩写](#2-缩略语和缩写)
- [3 相关文档](#3-相关文档)
- [3.1 输入文档](#31-输入文档)
- [3.2 相关标准和规范](#32-相关标准和规范)
- [4 加密栈概述](#4-加密栈概述)
- [4.1 栈架构](#41-栈架构)
- [4.2 加密服务管理器 (CSM)](#42-加密服务管理器-csm)
- [4.3 加密接口 (CRYIF)](#43-加密接口-cryif)
- [4.4 加密驱动 (CRYPTO)](#44-加密驱动-crypto)
- [5 使用方面](#5-使用方面)
- [5.1 作业概念](#51-作业概念)
- [5.1.1 同步和异步模式](#511-同步和异步模式)
- [5.1.2 队列和优先级](#512-队列和优先级)
- [5.1.3 流式方法与单次调用方法](#513-流式方法与单次调用方法)
- [5.2 密钥处理](#52-密钥处理)
- [5.3 配置理念](#53-配置理念)
- [5.3.1 加密功能注册](#531-加密功能注册)
- [5.3.2 项目配置](#532-项目配置)
- [6 示例](#6-示例)
- [6.1 模块中的配置](#61-模块中的配置)
- [6.2 涉及的 API](#62-涉及的-api)
---
## 1 引言
### 1.1 文档目的
本文档描述了自 AUTOSAR 4.3 起开始规范的 AUTOSAR 加密功能的预期使用方法。文档的目的是向用户/集成商介绍 AUTOSAR 所支持的加密功能的基本概念。
### 1.2 文档范围
本文档的范围是帮助加密栈的集成商和使用者理解：
- AUTOSAR 加密栈的架构；
- 各模块的整体表示及其相互关系；
- 加密硬件与软件的集成。
### 1.3 限制
无限制。
---
## 2 缩略语和缩写
| 缩略语 | 描述 |
|---|---|
| BSW | 基础软件 (Basic Software) |
| CDD | 复杂驱动 (Complex Device Driver) |
| CRYIF | 加密接口 (Crypto Interface) |
| CRYPTO | 加密驱动 (Crypto Driver) |
| CSM | 加密服务管理器 (Crypto Service Manager) |
| HSM | 硬件安全模块 (Hardware Security Module) |
| NvM | 非易失性存储管理器 (NVRAM Manager) |
| RTE | 运行时环境 (Runtime Environment) |
| SHE | 安全硬件扩展 (Security Hardware Extension) |
| SWC | 软件组件 (Software Component) |
### 2.1 术语表
| 术语 | 描述 |
|---|---|
| Crypto Driver Object (加密驱动对象) | 一个 Crypto Driver 实现一个或多个 Crypto Driver Object。Crypto Driver Object 可在硬件或软件中提供不同的加密原语。同一 Crypto Driver 的各 Crypto Driver Object 之间相互独立。每个 Crypto Driver Object 仅有一个工作区（即同一时刻只能执行一种加密原语）。 |
| Crypto Primitive (加密原语) | 加密原语是由 Crypto Driver Object 实现的已配置加密算法的一个实例。 |
| Job (作业) | 作业是已配置的加密原语以及所引用密钥的组合。 |
| Key (密钥) | 密钥可由 CSM 中的作业或密钥管理功能引用。在 Crypto Driver 中，密钥引用特定的密钥类型。 |
| Key Element (密钥元素) | 密钥元素用于存储数据。该数据可以是密钥材料，或 AES 加密所需的 IV 等。也可用于配置密钥管理功能的行为。 |
| Key Type (密钥类型) | 密钥类型由对若干密钥元素的引用构成。密钥类型通常由 Crypto Driver 的供应商预配置。 |
| Processing (处理模式) | 指示作业的处理方式。**异步 (Asynchronous)**：调用对应函数时作业不会立即被处理。通常，当作业完成时通过回调函数通知调用者。**同步 (Synchronous)**：调用对应函数时作业被立即处理。函数返回时即可获得结果。 |
---
## 3 相关文档
### 3.1 输入文档
- [1] Specification of Crypto Driver — `AUTOSAR_SWS_CryptoDriver.pdf`
- [2] Specification of Crypto Interface — `AUTOSAR_SWS_CryptoInterface.pdf`
- [3] Specification of Crypto Service Manager — `AUTOSAR_SWS_CryptoServiceManager.pdf`
- [4] Layered Software Architecture — `AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf`
### 3.2 相关标准和规范
无。
---
## 4 加密栈概述
加密服务包括哈希计算、非对称签名验证、对称数据加密等。在 AUTOSAR 中，这些服务由 AUTOSAR 加密栈提供，即加密服务管理器 (CSM)、底层的加密接口 (CRYIF) 以及加密驱动 (CRYPTO)。
CSM 服务所使用的加密算法由加密软件或硬件模块实现——这两者均超出 AUTOSAR 的范围，未在 AUTOSAR 中规定。硬件实现严重依赖于目标平台所支持的功能。软件实现缺乏例如安全密钥存储等支持，必须依赖 AUTOSAR 栈所提供的内存服务。
AUTOSAR 加密栈不提供安全概念 (security concept)。它提供可用于支持和实现某种安全概念的加密服务。
### 4.1 栈架构
AUTOSAR 加密栈跨越 AUTOSAR 分层架构 [4] 的所有层级：
> **图 1：AUTOSAR 分层视图中加密栈的位置 [3]**
(i) 在最低层——微控制器抽象层 (Microcontroller Abstraction Layer)——是加密驱动 (CRYPTO)。这些模块持有不同加密硬件和软件实例（例如外部 HSM）的实际实现。加密栈的一个特定特性是：可以存在多个 Crypto Driver 模块；
(ii) CRYIF 模块位于硬件抽象层 (Hardware Abstraction Layer)。它为 CSM 提供到可用 Crypto Driver 模块的通用接口，并使访问与底层 Crypto Driver 无关；
(iii) CSM 位于服务层 (Service Layer)。它提供一个抽象层，通过 RTE 端口机制为应用提供对加密服务的标准化访问。其他 BSW 模块和 CDD 可以使用 CSM 提供的 C-API 调用来使用加密服务。
### 4.2 加密服务管理器 (CSM)
CSM 控制一个或多个客户端对一个或多个同步/异步加密服务的并发访问。它提供优先级队列，以管理那些不能由专用 CRYPTO 直接处理的作业。CSM 所提供的功能涵盖以下领域：
- 哈希计算；
- 消息认证码的生成与验证；
- 数字签名的生成与验证；
- 使用对称或非对称算法的加密和解密；
- 随机数生成；
- 安全计数器；
- 密钥管理操作，如密钥设置与生成。
CSM 服务是通用的，CSM 允许不同的应用使用相同的服务但采用不同的加密算法。这是可行的，因为可以单独配置和初始化服务。例如，一个应用可能需要使用哈希服务来计算 SHA-2 摘要，而另一个应用需要计算 SHA-3 摘要。
实际的加密例程由 CSM 封装。服务客户端无需关心例程是通过软件还是硬件实现，或者由哪个 CRYPTO 模块实际承担所请求的加密例程。CSM 为加密栈中所有可用的加密功能提供抽象层。
### 4.3 加密接口 (CRYIF)
CRYIF 上承 CSM，下接 CRYPTO。它接收来自 CSM 的请求，并将其映射到 CRYPTO 中相应的加密操作。CRYIF 将 CSM 给出的请求转发给特定的 CRYPTO。在请求是异步的情况下，回调通知会通报结果。
CRYIF 可以操作多个 CRYPTO 模块。例如，可以有一个对应外部加密硬件的 CRYPTO 模块，以及一个持有加密软件库的 CRYPTO 模块。CRYIF 提供通用接口，使得来自 CSM 的访问无需区分实际的 CRYPTO 实现。
### 4.4 加密驱动 (CRYPTO)
CRYPTO 通常持有实际的加密实现，并支持密钥存储、密钥配置以及针对加密服务的密钥管理。它可以具有一个或多个 Crypto Driver Object，每个都具有独立的工作区。每个 Crypto Driver Object 可提供任意数量的加密原语。加密原语是已配置加密算法的一个实例。一个 Crypto Driver Object 在同一时刻只能执行一种加密原语。
多个 CRYPTO 模块和多个 Crypto Driver Object 的概念允许对相同加密服务进行不同且并发的实现。可以存在具有不同优化目标的 CRYPTO 模块变体。例如，同一哈希算法可能在两个不同的 CRYPTO 模块中实现——一个由更快速（更昂贵）的硬件方案实现，另一个由较慢（较便宜）的软件方案实现。
以下示例描述了使用多个 CRYPTO 模块的一种可能场景：有两个由不同供应商提供的 CRYPTO 实现。一个 CRYPTO 是对硬件方案的抽象（"CRYPTO_HW"），另一个 CRYPTO 是纯软件方案（"CRYPTO_SW"）。CRYPTO_SW 是一个加密库，提供哈希服务以及（伪）随机数生成器。为了能够并行处理这两类服务，CRYPTO_SW 具有两个 Crypto Driver Object：一个用于哈希服务（"CDO_HASH"），另一个用于随机数生成器（"CDO_RNG"）。如果某些加密例程不应并行运行，则应将它们放入同一个 Crypto Driver Object 中。
---
## 5 使用方面
### 5.1 作业概念
对 CSM 的加密例程请求以作业 (job) 表示。一个作业包含将处理哪种加密例程以及将使用哪把密钥的信息。作业本身不包含实际的密钥数据，而是引用适当的密钥。密钥管理功能不作为作业处理。
#### 5.1.1 同步和异步模式
由于加密服务的计算可能非常密集，作业处理应考虑为同步或异步。当使用同步作业处理时，CSM 服务将在调用者的上下文中被立即执行。加密例程的结果在函数返回时即可直接获得。
异步作业稍后由专用 CRYPTO 在调度的主函数上下文或硬件中处理。如果特定 CRYPTO 驱动对象由于繁忙而拒绝该作业，则 CSM 将服务请求放入相应的 CSM 作业队列。CRYPTO 通过 CRYIF 的回调函数向 CRYIF 通知异步作业的完成。CRYIF 再通过 CSM 的回调函数将结果转发出去。
#### 5.1.2 队列和优先级
CSM 可以具有多个队列，在这些队列中异步作业按其优先级顺序处理。CSM 的每个队列映射到一个 Crypto Driver Object，从而可以访问所选 Crypto Driver Object 的加密原语。在 CRYPTO 因繁忙而拒绝 CSM 服务请求之后，特定作业会被放入与自身优先级相对应的 CSM 队列中。排队的作业在周期性的 `Csm_MainFunction()` 中传递给 CRYIF。CRYIF 会将作业转发给特定的 CRYPTO。可选地，Crypto Driver Object 也可以具有作业队列。这对于优化 Crypto Driver Object 的硬件使用可能有用。
每个作业的优先级由其配置定义。优先级值越高，作业的优先级越高。作业将按其优先级被处理。
参考 4.4 中引入的示例，以下为可能的场景：CSM 收到两个异步作业请求，一个用于 CDO_HASH，另一个用于 CDO_RNG。两个 Crypto Driver Object 均属于 CRYPTO_SW。CSM 对这两个 Crypto Driver Object 各有一个作业队列。由于 CDO_HASH 没有队列且正在处理另一作业，CRYPTO_SW 拒绝该作业并由 CRYIF 通知 CSM。如果相应的 CSM 队列未满，则该 CDO_HASH 的作业会按其优先级入队到 CSM。`Csm_MainFunction()` 的下一次执行将处理 CSM 队列中优先级最高的作业。当哈希作业出队时，会将其从 CSM 队列中移除，并由 CRYIF 移交给 CDO_HASH。
#### 5.1.3 流式方法与单次调用方法
加密服务的处理包含三种操作："START"、"UPDATE" 和 "FINISH"：
- **"START"**（`CRYPTO_OPERATIONMODE_START`）：通知特定作业的新开始，并初始化加密计算；
- **"UPDATE"**（`CRYPTO_OPERATIONMODE_UPDATE`）：可使用此模式提供输入数据并计算中间结果；
- **"FINISH"**（`CRYPTO_OPERATIONMODE_FINISH`）：指示应执行最终的加密计算。
[3]，[SWS_Csm_00024] 给出基于上述操作的作业状态机的概述。所请求的操作以 operation mode 参数的形式传递给 CSM 作业。
可以通过流式方法或单次调用方法调用加密服务。流式方法对给定数据分别执行各单次操作。流式方法可通过分别针对每个操作模式调用例如 `Csm_MacGenerate()` 来使用。使用流式方法可以例如通过对服务函数多次以 "UPDATE" 操作模式进行调用来处理非常大的输入数据。
为了提高加密服务的性能，单次调用方法将多个作业操作合并到单次函数调用中。这减少了多次调用函数的开销。操作模式声明应执行哪些操作，并且这些模式可以组合。操作按 "START"、"UPDATE"、"FINISH" 的顺序执行。在上面的示例中，可以调用 `Csm_MacGenerate()`，并传入一个包含所有操作模式的 operation mode 类型。单次调用方法在处理小数据集合时尤其有益。在这种情况下，加密服务可以一次完成。
### 5.2 密钥处理
密钥处理包括加密密钥的生成、更新、导入/导出、交换以及派生。加密密钥可以存储在加密硬件中或使用 NvM。
加密密钥通过引用某种密钥类型来创建。CRYPTO 实现的供应商会预配置适用于所提供的加密原语的密钥类型。密钥类型由一个或多个对密钥元素的引用构成。例如，密钥元素可以是 AES 加密所需的密钥材料或随机数生成的种子。加密栈使用密钥元素索引定义 [3]。例如，加密服务 MAC 具有一个强制性的密钥元素 "Key Material"，其密钥元素 ID 为 "1"。密钥元素索引可由供应商扩展。一个密钥元素也可以属于多个密钥类型。
在密钥配置期间，必须指定对适当密钥类型的引用。特定 CRYPTO 为密钥类型所包含的密钥元素提供数据存储，实际的密钥数据就保存在那里。硬件 CRYPTO 实现通常使用密钥槽 (key slot)。而软件 CRYPTO 则使用 NvM 来管理密钥存储。
### 5.3 配置理念
#### 5.3.1 加密功能注册
任意数量 CRYPTO 模块的概念使得可用的加密功能具有灵活性。这要求存在一种注册机制，使 CRYPTO 实现中实际的加密功能对 CRYIF 和 CSM 可见。否则，在 CSM 中配置和使用实际的加密功能将是不可能的。
这通过由供应商提供的预配置解决，该预配置表示每个 CRYPTO 模块的能力。预配置从底层向上层加载，即从 CRYPTO 开始，经 CRYIF，到 CSM。CRYIF 挂载每个已注册的 CRYPTO 模块，并将各加密功能集成到提供给 CSM 的通用接口中。CSM 接管已注册 CRYPTO 的可用加密功能，并推导出可供用户配置的特定加密功能。
#### 5.3.2 项目配置
加密栈的配置通常采用自顶向下的方法进行，从 CSM 开始，经 CRYIF，到 CRYPTO：
(i) 在 CSM 中，用户选择并配置将由 CRYIF 和 CRYPTO 提供的加密原语和密钥。用户进一步定义作业和作业队列。
(ii) 在 CRYIF 中，用户主要定义由 CSM 请求的功能到已注册 CRYPTO 模块所提供功能的映射。
(iii) 在 CRYPTO 中，用户调整并扩展加密原语和密钥的预配置。
---
## 6 示例
下面使用 "消息认证码" (MAC) 服务来说明加密栈的使用。
### 6.1 模块中的配置
用户创建一个作业，引用所请求的 MAC 加密原语以及要使用的加密密钥。还需要配置作业是同步 (`CRYPTO_PROCESSING_SYNC`) 还是异步 (`CRYPTO_PROCESSING_ASYNC`) 处理。如果作业是异步的，还需要定义处理该作业的队列。
MAC 要求密钥至少引用一个密钥元素 "Key Material"（`CRYPTO_KE_MAC_KEY`）。
### 6.2 涉及的 API
应用（即 SWC 的可运行实体）通过 RTE 端口与加密栈（即 CSM）通信。对于每个已配置的作业，RTE 生成一个名为 `{Job}_MacGenerate` 的端口，其客户端/服务器接口为 `CsmMacGenerate_{Primitive}()`。该端口具有一个端口定义参数 `Crypto_OperationModeType`，其值为 `CRYPTO_OPERATIONMODE_SINGLECALL`。因此，SWC 可以通过调用 `CsmMacGenerate_{Primitive}` 一次性向 CSM 提供执行 MAC 请求所需的全部数据来调用 MAC 服务。BSW 模块或 CDD 通过直接调用 C-API `Csm_MacGenerate()` 来使用 MAC 服务。这里，待处理的作业必须作为输入参数传入。
根据所应用作业的配置，作业的处理将是异步或同步的。在本示例中，我们假设作业必须在调用者的上下文中同步处理。CSM 通过调用 `CryIf_ProcessJob()` 将所请求的 MAC 服务分派给 CRYIF，并将作业作为输入参数传入。CRYIF 通过调用 `Crypto_ProcessJob()` 将作业的处理转移到 CRYPTO，最终执行作业参数中配置的加密原语。请注意，如果存在不同的 CRYPTO 实现，函数命名将通过使用 `vendorId (vi)` 和 `vendorApiInfix (ai)` 来区分。因此，调用将是 `Crypto_<vi>_<ai>_ProcessJob()`。最后，CRYPTO 将 MAC 存储在 CSM 作业中配置的内存空间中。
---
## 翻译说明
- 本文档为 AUTOSAR EXP 602《Utilization of Crypto Services》(CP 4.4.0) 的中文翻译；
- 文档标识号：602；
- 文档共 13 页，已完整翻译核心内容；
- 保留了所有 AUTOSAR 方框符、API 标识符、模块缩写和算法名；
- 翻译以保证技术含义准确为前提，语句尽量贴近 AUTOSAR 中文术语库常用译法。
Crypto/AUTOSAR_SRS_CryptoStack.md
+1159
View File
File diff suppressed because it is too large Load Diff
Crypto/AUTOSAR_SWS_CryptoDriver.md
+1438
View File
File diff suppressed because it is too large Load Diff
Crypto/AUTOSAR_SWS_CryptoInterface.md
+1009
View File
File diff suppressed because it is too large Load Diff
Crypto/AUTOSAR_SWS_CryptoServiceManager.md
+1304
View File
File diff suppressed because it is too large Load Diff
Crypto/AUTOSAR_SWS_KeyManager.md
+867
View File
@@ -0,0 +1,867 @@
# 密钥管理器规范 (Specification of Key Manager)
**AUTOSAR CP Release 4.4.0**
> 翻译说明：本文档为 AUTOSAR 经典平台 (CP) Release 4.4.0 中 SWS 文档 907《Specification of Key Manager》的中文翻译版本。原始英文文档中的 AUTOSAR 方框符 `⌈⌋`、API 标识符（如 `KeyM_Init`、`KeyM_Update`）、模块缩写（Crypto、CryIf、Csm、KeyM 等）、加密算法名（AES、SHA、RSA、ECC、X.509 等）以及需求 ID（如 `SWS_KeyM_xxxxx`）均予以保留。本文采用"重点翻译 + 摘要"策略：完整翻译封面、标识、变更历史、目录、关键 API 及核心概念；重复的需求条目和服务接口详细定义予以摘要处理。
## 文档标识
| 项目 | 内容 |
|---|---|
| 文档标题 (Document Title) | Specification of Key Manager（密钥管理器规范） |
| 文档所有者 (Document Owner) | AUTOSAR |
| 文档责任方 (Document Responsibility) | AUTOSAR |
| 文档标识号 (Document Identification No) | 907 |
| 文档状态 (Document Status) | Final |
| 所属 AUTOSAR 标准 | Classic Platform |
| 所属标准版本 (Part of Standard Release) | 4.4.0 |
## 文档变更历史 (Document Change History)
| 日期 | 版本 | 变更者 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 初始发布 |
---
## 目录 (Table of Contents)
- [1 引言与功能概述](#1-引言与功能概述)
- [2 缩略语和缩写](#2-缩略语和缩写)
- [3 相关文档](#3-相关文档)
- [4 约束和假设](#4-约束和假设)
- [5 对其他模块的依赖](#5-对其他模块的依赖)
- [6 需求可追溯性](#6-需求可追溯性)
- [7 功能规范](#7-功能规范)
- [7.1 加密密钥子模块](#71-加密密钥子模块)
- [7.2 证书子模块](#72-证书子模块)
- [7.3 错误分类](#73-错误分类)
- [8 API 规范](#8-api-规范)
- [9 序列图](#9-序列图)
- [10 配置规范](#10-配置规范)
- [11 不适用的需求](#11-不适用的需求)
---
## 1 引言与功能概述
AUTOSAR KeyM 模块由两个子模块组成：加密密钥子模块 (crypto key submodule) 和证书子模块 (certificate submodule)。
加密密钥子模块提供 API 和配置项，用于引入或更新预定义的加密密钥材料。它充当密钥客户端 (key client)，用于解释来自密钥服务器 (key server) 提供的数据并创建相应的密钥材料。这些密钥提供给加密服务管理器。在成功安装密钥材料后，应用程序能够使用加密操作。这允许 OEM 在生产或维护阶段将密钥材料独立于应用程序引入到 ECU。
证书子模块提供用于操作证书的 API 和配置。它允许定义证书槽并以 PKI 中使用的方式按层次结构关联它们。证书可以永久存储，例如根证书或中间证书，以便可以使用它们针对证书链验证给定证书。此外，证书子模块允许访问证书元素或验证其内容。
### 1.1 重要说明
本规范为车辆密钥和证书管理系统提供了 API 骨架。并非所有功能都已完全指定。这可能允许一些解释和实现细节的自由度。尽管接口已以通用和灵活的方式设计，但它们仍可能在未来的 AUTOSAR 版本中发生变化。
---
## 2 缩略语和缩写
| 缩写 | 描述 |
|---|---|
| KeyM | 密钥管理器 (Key Manager) |
| PKI | 公钥基础设施 (Public Key Infrastructure) |
| CSR | 证书签名请求 (Certificate Signing Request) |
| CSM | 加密服务管理器 (Crypto Service Manager) |
| CRL | 证书吊销列表 (Certificate Revocation List) |
| CA | 证书颁发机构 (Certificate Authority) |
| OID | 对象标识符 (Object Identifier)。一个字节数组，用于标识证书元素或证书元素的组或列表。 |
---
## 3 相关文档
### 3.1 输入文档
- [1] AUTOSAR Layered Software Architecture — `AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf`
- [2] AUTOSAR General Requirements on Basic Software Modules — `AUTOSAR_SRS_BSWGeneral.pdf`
- [3] AUTOSAR General Specification for Basic Software Modules — `AUTOSAR_SWS_BSWGeneral.pdf`
- [4] AUTOSAR Specification of Crypto Service Manager — `AUTOSAR_SWS_CryptoServiceManager.pdf`
- [5] AUTOSAR Requirements on Crypto Stack — `AUTOSAR_SRS_CryptoStack.pdf`
### 3.2 相关标准和规范
- [6] IEC 7498-1 The Basic Model, IEC Norm, 1994
- [7] IETF 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
- [8] SHE – Secure Hardware Extension, Functional Specification, V1.1
### 3.3 相关规范
AUTOSAR 提供了基础软件通用规范 (SWS BSW General) [3]，该规范同样适用于密钥管理模块。因此，SWS BSW General [3] 应被视为密钥和证书管理模块的附加且必需的规范。
---
## 4 约束和假设
### 4.1 限制
密钥管理模块应与加密服务管理器及其底层模块一起使用。
当前仅支持每个 CsmKey 一个 KeyElement (ID = 1)。
### 4.2 对汽车域的适用性
本规范对特定汽车域没有限制。
---
## 5 对其他模块的依赖
本章列出了 AUTOSAR KeyM 模块所使用的与其他模块的关系。
### 5.1 对加密服务管理器的依赖
KeyM 模块依赖于 Csm 模块提供的加密算法和功能。KeyM 模块需要 API 函数来检索和设置密钥元素以及验证证书的签名，即：
- 密钥设置接口 (Key Setting Interface)
- 密钥提取接口 (Key Extraction Interface)
- 密钥复制接口 (Key Copying Interface)
- 密钥生成接口 (Key Generation Interface)
- 密钥派生接口 (Key Derivation Interface)
- 密钥交换接口 (Key Exchange Interface)
- 证书接口 (Certificate Interface)
- 签名接口 (Signature Interface)
### 5.2 对非易失性存储器的依赖
KeyM 可以配置为在非易失性存储器中存储密钥材料。这需要到 NVM 的接口。
### 5.3 对同步时间基的依赖
证书验证期的时间由 STBM 提供。
---
## 6 需求可追溯性
> 完整可追溯性表（涵盖 SRS_BSW_00101、SRS_BSW_00358、SRS_BSW_00407、SRS_BSW_00414、SRS_CryptoStack_00090、SRS_CryptoStack_00091、SRS_CryptoStack_xxx06、SWS_BSW_00050、SWS_BSW_00216 等到 SWS_KeyM_xxx 的映射）请参阅原始 PDF 文档第 10 页。
---
## 7 功能规范
> **图 7-1：带有 KEYM 的 AUTOSAR 分层视图**
密钥管理模块大致可以分为两部分：加密密钥子模块和证书子模块。加密密钥子模块主要用于与发起生成或直接提供密钥材料的密钥配置实体（密钥主机，key master）进行交互。这些密钥分配给 CSM 的加密密钥，并存储在专用 NVM 块中，也可以作为相应加密驱动的密钥存储。证书子模块允许按层次结构配置证书链中的证书，提供存储和验证它们的接口。证书中包含的公钥可以进一步分配给 CsmKey，以便与配置的 CSM 加密作业一起使用。
**[SWS_KeyM_00001]** ⌈ 如果 `KeyMCryptoKeyManagerEnabled` 设置为 FALSE，则密钥管理器的加密密钥子模块应完全禁用。在这种情况下，不应提供任何函数，并且不应分配不需要用于其他操作的资源。⌋ (SRS_CryptoStack_xxx06)
**[SWS_KeyM_00002]** ⌈ 如果 `KeyMCertificateManagerEnabled` 设置为 FALSE，则密钥管理器中对证书子模块的支持应完全禁用。在这种情况下，不应提供任何函数，并且不应分配与证书操作关联的资源。⌋ (SRS_CryptoStack_xxx06)
### 7.1 加密密钥子模块
加密密钥子模块用于初始化、更新和维护 ECU 的加密密钥材料。一个用例是为安全车载通信提供需要分发到所涉及的 ECU 的密钥。这些密钥应提供给 CSM 密钥，这些 CSM 密钥分配给用于安全 I-PDU 身份验证的加密作业。因此，从建模的角度来看，将密钥主机提供的密钥分配给 CSM 密钥以及用于相应安全 I-PDU 的作业至关重要。这是车辆中的整体任务，并以相同方式影响多个 ECU。加密密钥子模块的一个目的是支持此操作。
密钥主机可以直接位于车辆中以协调内部密钥生成，例如作为特定的 ECU。也可以使用云中的后端系统，以安全方式生成密钥材料并将必要的数据提供给 ECU。通常，诊断命令直接或间接地用于密钥主机与加密密钥子模块之间的通信。
#### 7.1.1 通用行为
**[SWS_KeyM_00003]** ⌈ 加密密钥子模块可以配置为以类似会话的方式执行加密密钥操作。通过这种方式，仅在打开的会话期间接受 `KeyM_Prepare()` 或 `KeyM_Update()` 等密钥操作。⌋()
**[SWS_KeyM_00004]** ⌈ 通过调用 `KeyM_Start()` 启动会话。此后可以执行密钥操作，直到通过调用 `KeyM_Finalize()` 关闭会话。⌋()
**[SWS_KeyM_00005]** ⌈ 默认情况下，`KeyM_Start()` 函数不会考虑任何输入数据或长度信息，也不会提供任何输出数据，也不会更改输出数据长度。⌋()
**[SWS_KeyM_00006]** ⌈ （可选）如果配置选项 `KeyMCryptoKeyHandlerStartFinalizeEnabled` 设置为 TRUE，则可以调用密钥处理器。`KeyM_Start()` 函数将依次调用 `KeyM_KH_Start()` 函数，参数与 `KeyM_Start()` 相同。`KeyM_KH_Start()` 的返回值将用作 `KeyM_Start()` 的返回值。⌋()
**原理**：`KeyM_KH_Start()` 函数可以执行 OEM 特定的检查，例如验证任何输入数据的签名以证明密钥管理操作的真实性。
**注意**：`KeyMCryptoKeyHandlerStartFinalizeEnabled` 的定义仅在 `KeyMCryptoKeyStartFinalizeFunctionEnabled` 设置为 TRUE 时才有效。
**[SWS_KeyM_00007]** ⌈ 如果配置选项 `KeyMCryptoKeyStartFinalizeFunctionEnabled` 设置为 FALSE，则密钥管理模块不提供 `KeyM_Start()` 和 `KeyM_Finalize()` 函数。然后可以随时执行密钥更新操作。⌋()
**[SWS_KeyM_00008]** ⌈ 通过调用 `KeyM_Finalize()` 关闭会话。在调用期间，将在会话内更新的所有密钥通过调用 `Csm_KeySetValid()` 设置为有效。在函数完成其操作后，将不再接受进一步的密钥更新操作。⌋()
**[SWS_KeyM_00009]** ⌈ 如果所有密钥都已成功验证，则函数 `KeyM_Finalize()` 将返回 `E_OK`。如果至少一个密钥无法成功验证，则函数应返回 `E_NOT_OK`。尽管如此，所有已更新的密钥都应被验证，并且如果一个密钥验证失败，操作不应中止。⌋()
**[SWS_KeyM_00010]** ⌈ 如果配置选项 `KeyMCryptoKeyPrepareFunctionEnabled` 设置为 TRUE，则提供函数 `KeyM_Prepare()`。此函数当前没有功能行为。如果配置选项设置为 FALSE，则不提供功能接口。⌋()
**[SWS_KeyM_00011]** ⌈ 如果配置选项 `KeyMCryptoKeyHandlerPrepareEnabled` 设置为 TRUE，则对 `KeyM_Prepare()` 的调用将依次传递给 `KeyM_KH_Prepare()`，参数和返回值将相应传递。⌋()
**原理**：目的是在启动密钥更新会话后立即调用一次 `KeyM_Prepare()`。调用的诊断服务可以向密钥处理器提供执行以下密钥更新操作所需的特定数据。例如，它可以用于提取密钥主机所需的加密驱动特定信息，该信息从 (SHE-) 硬件提取并再次在输出缓冲区中提供。或者它可以启动一个 OEM 特定的密钥协商过程，其结果稍后对密钥更新过程是必需的。另一种可能性是密钥主机在准备期间提供（加密的）公共密钥。特定的密钥处理器能够（解密并）将密钥存储在 CSM 中。这将产生一个分配给 CSM 密钥的公共密钥，可进一步用于从中派生其他密钥。
**[SWS_KeyM_00012]** ⌈ 密钥更新通过调用 `KeyM_Update()` 触发，通常由诊断服务启动。⌋()
**[SWS_KeyM_00013]** ⌈ 如果调用 `KeyM_Update()` 并且 `KeyMCryptoKeyHandlerUpdateEnabled` 设置为 FALSE 且 `keyNameLength` 大于 0，则加密密钥子模块将搜索 `KeyMCryptoKey/KeyMCryptoKeyName` 中配置的密钥名称。如果未找到密钥名称，则函数将返回 `E_NOT_OK`。如果找到，则函数将触发密钥更新操作。⌋()
**[SWS_KeyM_00014]** ⌈ 如果调用 `KeyM_Update()` 并且 `KeyMCryptoKeyHandlerUpdateEnabled` 设置为 FALSE 且 `keyNameLength` 为 0，则加密密钥子模块将输入数据解释为 SHE 密钥的 M1M2M3 值。通过提取输入数据的 bit 121..124 从 M1 中提取 key_ID，并将在 `KeyMCryptoKeyCryptoProps` 中搜索相应的值以识别 `KeyMCryptoKeyId` 和关联的 `CsmKeyRef`。如果找到，则函数将触发密钥更新操作。⌋()
**注意**：在这种情况下，CsmKey 应配置为 SHE 密钥。格式应为 SHE 算法类型，`KeyMCryptoKeyGenerationType` 应设置为 `KEYM_STORED_KEY`。
**[SWS_KeyM_00015]** ⌈ 当调用 `KeyM_Update()` 并且通过内部搜索算法或通过提供密钥处理器 `KeyM_KH_Update()` 找到 `KeyMCryptoKeyId` 时，应按照 `KeyMCryptoKeyGenerationType` 中的配置执行密钥生成。如果未找到关联的密钥，则 `KeyM_Update()` 函数应返回 `E_NOT_OK`。⌋()
**[SWS_KeyM_00016]** ⌈ 如果识别到密钥 ID 且 `KeyMCryptoKeyGenerationType` 配置为 `KEYM_STORED_KEY`，则将使用对 `KeyMCryptoKeyCsmKeyTargetRef` 的引用和密钥元素 ID '1' 调用函数 `Csm_KeyElementSet()`。将为该密钥设置内部标记，表示内容已更改并且需要最终化。⌋()
**[SWS_KeyM_00017]** ⌈ 如果识别到密钥 ID 且 `KeyMCryptoKeyGenerationType` 配置为 `KEYM_DERIVE_KEY`，则将调用函数 `Csm_KeyDerive()` 以从公共密钥（由 `KeyMCryptoKeyCsmKeySourceDeriveRef` 引用）派生新密钥（由 `KeyMCryptoKeyCsmKeyTargetRef` 引用）。将为该密钥设置内部标记，表示内容已更改并且需要最终化。⌋()
**[SWS_KeyM_00018]** ⌈ 如果 `KeyMCryptoKeyStartFinalizeFunctionEnabled` 设置为 FALSE，则应在成功的密钥派生或存储操作之后立即调用函数 `Csm_KeySetValid()`。⌋()
密钥更新操作有几种选项：
一种明显的选项是多次调用 `KeyM_Update()` 函数，即每个要更新的密钥调用一次。密钥主机将从外部触发函数调用，并在每次服务调用中提供密钥材料。另一种可能性是使用单个调用（例如 `KeyM_Prepare()`）提供容器，该容器反过来调用 `KeyM_KH_Prepare()`。这允许以 OEM 特定格式提供容器。密钥处理器将扫描容器并必须为容器中可用的每个密钥多次调用 `KeyM_Update()`。
**[SWS_KeyM_00019]** ⌈ 如果配置项 `KeyMCryptoKeyStartFinalizeFunctionEnabled` 设置为 TRUE，则必须通过调用 `KeyM_Finalize()` 来结束加密密钥操作。该函数将为所有具有内部标记的密钥触发对 `Csm_KeySetValid()` 的调用，以最终化密钥更新操作。无论函数调用是否成功，在该函数调用之后关闭密钥更新会话并清除所有内部标记。⌋()
**[SWS_KeyM_00020]** ⌈ 如果配置项 `KeyMCryptoKeyVerifyFunctionEnabled` 设置为 TRUE，则加密密钥子模块应提供函数 `KeyM_Verify()`。该函数可由密钥主机触发，并用于运行由 `KeyMCryptoKeyCsmVerifyJobRef` 引用的加密作业。`KeyM_Verify()` 可在任何时间调用，并且不绑定到活动的加密密钥会话。⌋()
### 7.2 证书子模块
KeyM 的证书子模块功能允许 BSW 模块和 SWC 在 AUTOSAR 软件架构中的中心点更高效地执行证书操作。此类操作的示例包括验证完整证书链或从运行时提供和验证的证书中检索元素。
所需的加密操作（例如证书签名的验证）仍由加密服务管理器中定义的关联加密作业执行。此外，证书的安全存储可以位于 CSM 的密钥存储位置中，例如允许将根证书存储在 HSM 内。
#### 7.2.1 通用行为
证书子模块允许定义和配置证书，以便可以在生产时存储它们并进一步用于多种目的。配置允许以分层结构（具有 PKI 系统中使用的根、中间和目标证书）定义证书链中的证书。存储的证书将在启动时根据配置的分层结构进行检查。配置还允许检查特定证书元素是否具有确定的值。还支持读取证书的特定元素，并且所包含的公钥可以与 CsmKey 关联，以便与配置的 CSM 加密作业一起使用。
> **图 7-2：PKI 证书链示例**
如果需要，根证书和中间证书可以在 ECU 或车辆的生产阶段提供。这些证书将永久存储在指定位置。如果现在向 ECU 提交证书，则可以将此证书存储在临时位置以请求验证。证书子模块将检查关联链中的现有证书，并将开始解析内容，根据预先配置的条件验证它们，然后将针对其链中所有可用的证书检查签名。
#### 7.2.2 初始化
**[SWS_KeyM_00022]** ⌈ 在初始化期间，证书子模块将检索永久存储的证书，准备它们进行解析，并根据需要使它们可用，例如用于证书元素提取或针对其他证书进行验证。⌋()
可选地，证书子模块可以解析一次证书并将解析后的信息存储在专用 NVM 块中，而不是在每次启动时解析证书。在 NVM 中存储解析结果的优势将加快系统的启动。
由于证书的解析和验证可能需要大量时间，因此建议在启动后于后台任务中为存储的证书执行此操作。
**[SWS_KeyM_00023]** ⌈ 如果解析操作成功，则证书子模块从证书中提取公钥并将其存储在 CSM 的提供的密钥引用中或 NVM 中。⌋()
#### 7.2.3 证书配置
**[SWS_KeyM_00024]** ⌈ 应至少将一个证书定义为 PKI 的根证书。相应 `KeyMCertificate` 容器的 `KeyMCertUpperHierarchicalCertRef` 引用自身。⌋()
**原理**：根证书具有以下特征：使用存储在同一证书中的公钥验证签名（自签名证书）。它是层次结构中的顶级证书。
**[SWS_KeyM_00025]** ⌈ 通过调用函数 `KeyM_SetCertificate()` 存储证书以供验证。证书将放置在 `KeyMCryptoKey` 的预配置存储类中。⌋()
**注意**：这样的密钥通常放置在 RAM 中，并不打算用于永久存储。`KeyM_SetCertificate()` 仅用于验证提交的证书。它不打算用于永久存储，例如根密钥。对于永久存储证书的操作，应使用函数 `KeyM_ServiceCertificate()`。
#### 7.2.4 操作模式
**[SWS_KeyM_00021]** ⌈ 如果配置项 `KeyMServiceCertificateFunctionEnabled` 和 `KeyMCertificateManagerEnabled` 设置为 TRUE，则证书子模块应提供函数 `KeyM_ServiceCertificate()`。该函数可由密钥主机触发，并用于向证书子模块提供证书相关信息。可以执行几种证书相关操作，例如永久存储在系统中的证书的引入或更新。⌋()
**[SWS_KeyM_00026]** ⌈ 一旦证书已通过 `KeyM_SetCertificate()` 或 `KeyM_ServiceCertificate()` 存储，就会启动证书的解析过程。⌋()
**[SWS_KeyM_00027]** ⌈ 解析过程识别证书是否以良好格式的方式提供，例如 X.509 证书的 ASN.1 结构是否正确以及是否包含所有基本元素。此外，根据所有已分配 `KeyMCertificateElementVerification` 容器的配置检查其他证书元素的内容。⌋()
**[SWS_KeyM_00028]** ⌈ 通过调用函数 `KeyM_VerifyCertificate()`、`KeyM_VerifyCertificates()` 或 `KeyM_VerifyCertificateChain()` 之一来按需验证证书。⌋()
**[SWS_KeyM_00029]** ⌈ 至少应按此顺序成功通过以下验证步骤，以成功验证证书：
1. 证书从层次结构的顶部验证到底部。
2. 验证中涉及的所有证书应可用，并且已成功解析和验证。
3. 如果吊销列表可用，则应检查所有涉及的证书是否列在 CRL 中。
4. 上层层次结构中证书的主题字段与下层层次结构中证书的颁发者字段匹配。
5. 时间服务器（即 STBM）提供的当前时间应大于"not before"且小于"not after"时间值。
6. 可以使用由 `KeyMCertUpperHierarchicalCertRef` 引用的证书的关联公钥验证签名。对于 X.509 证书，所有关键扩展字段都应存在。通过使用由 `KeyMCertUpperHierarchicalCertRef` 引用的证书的 `KeyMCertCsmSignatureVerifyJobRef` 来验证签名。该上层层次结构证书的相应公钥应加载到 `KeyMCertCsmSignatureVerifyKeyRef` 中（如果存在）。
⌋()
**[SWS_KeyM_00030]** ⌈ 如果层次链中的某个证书缺失或主题和颁发者字段不匹配，则验证函数应返回 `KEYM_E_CERT_INVALID_CHAIN_OF_TRUST`。⌋()
**[SWS_KeyM_00031]** ⌈ 如果解析过程检测到某个证书元素不包含所需值，则验证函数应返回 `KEYM_E_CERT_INVALID_CONTENT`。⌋()
**[SWS_KeyM_00032]** ⌈ 如果提供的证书格式无效（例如 X.509 证书的 ASN.1 结构无效），则验证函数应返回 `KEYM_E_CERT_INVALID_FORMAT`。⌋()
**[SWS_KeyM_00033]** ⌈ 如果提供的证书与当前时间段不匹配，则验证函数应返回 `KEYM_E_CERT_VALIDITY_PERIOD_FAIL`。⌋()
**[SWS_KeyM_00034]** ⌈ 如果签名验证失败，则验证函数应返回 `KEYM_E_CERT_SIGNATURE_FAIL`。⌋()
**[SWS_KeyM_00035]** ⌈ 如果链中的某个证书在吊销列表中找到（如果可用），则验证函数应返回 `KEYM_E_CERTIFICATE_REVOKED`。⌋()
### 7.3 错误分类
#### 7.3.1 开发错误
**[SWS_KeyM_00036]** 开发错误类型 ⌈
| 错误类型 | 相关错误代码 | 值（十六进制） |
|---|---|---|
| 使用无效参数（空指针）调用 API 服务 | KEYM_E_PARAM_POINTER | 0x01 |
| 操作的缓冲区太小 | KEYM_E_SMALL_BUFFER | 0x02 |
| 在模块初始化之前调用 API | KEYM_E_UNINIT | 0x03 |
| KeyM 模块初始化失败 | KEYM_E_INIT_FAILED | 0x04 |
⌋()
#### 7.3.2 运行时错误
无运行时错误。
#### 7.3.3 瞬态故障
无瞬态故障。
#### 7.3.4 生产错误
无生产错误。
#### 7.3.5 扩展生产错误
无扩展生产错误。
---
## 8 API 规范
### 8.1 导入类型
本章列出了从以下文件导入的所有类型：
**[SWS_KeyM_00037]** ⌈
| 模块 | 头文件 | 导入的类型 |
|---|---|---|
| Csm | `<none>` | Crypto_VerifyResultType |
| | Rte_Csm_Type.h | Crypto_OperationModeType |
| StbM | Rte_StbM_Type.h | StbM_SynchronizedTimeBaseType |
| | Rte_StbM_Type.h | StbM_TimeStampType |
| | Rte_StbM_Type.h | StbM_UserDataType |
| Std_Types | StandardTypes.h | Std_ReturnType |
| | StandardTypes.h | Std_VersionInfoType |
⌋()
密钥管理模块使用 Std_ReturnType 的以下扩展：
**[SWS_KeyM_00040]** ⌈
| 范围 | 描述 |
|---|---|
| `KEYM_E_BUSY` = 0x02 | 密钥管理忙于其他操作 |
| `KEYM_E_PENDING` = 0x03 | 操作请求已接受，响应待处理。它现在以异步模式运行，响应将通过回调提供 |
| `KEYM_E_KEY_CERT_SIZE_MISMATCH` = 0x04 | 参数大小与预期值不匹配 |
| `KEYM_E_PARAMETER_MISMATCH` = 0x05 | 函数参数未提供预期值 |
| `KEYM_E_KEY_CERT_INVALID` = 0x06 | 密钥或证书无效，无法用于该操作 |
| `KEYM_E_KEY_CERT_READ_FAIL` = 0x07 | 由于读取或权限失败，无法提供证书或密钥 |
| `KEYM_E_KEY_CERT_EMPTY` = 0x08 | 请求的密钥或证书不可用，槽为空 |
| `KEYM_E_CERT_INVALID_CHAIN_OF_TRUST` = 0x09 | 证书验证失败 — 信任链无效 |
| Description | 密钥管理特定的返回值，用于 Std_ReturnType |
| Available via | KeyM.h |
⌋()
### 8.2 类型定义
#### 8.2.1 KeyM_ConfigType
**[SWS_KeyM_00157]** ⌈
| 字段 | 内容 |
|---|---|
| Name | `KeyM_ConfigType` |
| Type | Structure |
| Range | implementation specific |
| Description | 此结构是初始化密钥管理器模块的基本类型。在密钥管理器模块的初始化中将使用指向此结构实例的指针。 |
| Available via | KeyM.h |
⌋ (SWS_BSW_00216)
#### 8.2.2 KeyM_KH_UpdateOperationType
**[SWS_KeyM_00055]** ⌈
| 字段 | 内容 |
|---|---|
| Name | `KeyM_KH_UpdateOperationType` |
| Type | Enumeration |
| Range | `KEYM_KH_UPDATE_KEY_UPDATE_REPEAT` = 0x01 — 密钥处理器已成功执行操作并提供应由密钥管理器的更新函数进一步操作的新密钥数据。请求下一次调用密钥处理器。<br>`KEYM_KH_UPDATE_FINISH` = 0x02 — 密钥处理器已成功执行所有更新操作。更新操作已完成，结果数据可以提供回来作为 KeyM_Update 操作的最终结果。 |
| Description | 指定在回调中执行的密钥处理器更新操作的类型。 |
| Available via | KeyM.h |
⌋()
#### 8.2.3 KeyM_CertElementIteratorType
**[SWS_KeyM_00042]** ⌈
| 字段 | 内容 |
|---|---|
| Name | `KeyM_CertElementIteratorType` |
| Type | Structure |
| Range | implementation specific |
| Description | 此结构用于迭代证书的多个元素。 |
| Available via | KeyM.h |
⌋()
#### 8.2.4 KeyM_CryptoKeyIdType
**[SWS_KeyM_00302]** ⌈
| 字段 | 内容 |
|---|---|
| Name | `KeyM_CryptoKeyIdType` |
| Type | uint16 |
| Description | 加密密钥句柄。 |
| Available via | KeyM.h |
⌋()
#### 8.2.5 KeyM_CertDataType
**[SWS_KeyM_00041]** ⌈
| 字段 | 内容 |
|---|---|
| Name | `KeyM_CertDataType` |
| Type | Structure |
| Element | `certDataLength` (uint32) — 证书数据的长度；<br>`certData` (`KeyM_CertDataPointerType`) — 指针引用调用方本地数据区域上的证书数据 |
| Description | 此结构用于通过接口函数交换证书数据。 |
| Available via | KeyM.h |
⌋()
### 8.3 函数定义
这是为上层模块提供的函数列表。
#### 8.3.1 通用
##### 8.3.1.1 KeyM_Init
**[SWS_KeyM_00043]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | `KeyM_Init` |
| Syntax | `void KeyM_Init(const KeyM_ConfigType* ConfigPtr)` |
| Service ID[hex] | 0x01 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | `ConfigPtr` — 指向在 VARIANT-POST-BUILD 中设置的配置的指针 |
| Parameters (inout) | None |
| Parameters (out) | None |
| Return value | None |
| Description | 此函数初始化密钥管理模块。 |
| Available via | KeyM.h |
⌋ (SRS_BSW_00101, SRS_BSW_00358, SRS_BSW_00414)
**[SWS_KeyM_00158]** ⌈ 配置指针 `configPtr` 应始终具有 `NULL_PTR` 值。⌋(SWS_BSW_00050)
**注意**：当前未使用密钥管理器在初始化时的配置，因此应将 `NULL_PTR` 传递给模块。
**[SWS_KeyM_00044]** ⌈ 如果密钥管理模块的初始化失败，并且开发错误处于激活状态，则错误 `KEYM_E_INIT_FAILED` 应报告给 DET。⌋()
**[SWS_KeyM_00045]** ⌈ 如果证书子模块处于活动状态，并且永久存储的证书在未解析和未验证状态下可用，则 KeyM 证书子模块部分应启动后台任务以预解析和预验证证书。⌋()
**原理**：如果 CPU 时间可用，可以在后台任务中执行该操作。预验证证书将有助于在提交证书并应在运行时针对预安装的证书链进行验证时加快身份验证速度。
**[SWS_KeyM_00046]** ⌈ 如果加密密钥子模块处于活动状态，则在初始化期间应从 NVM 读取所有密钥，并将其存储到 CSM (RAM-) 密钥槽。⌋()
**[SWS_KeyM_00144]** ⌈ 如果开发错误处于激活状态，则密钥管理器应在每次函数调用时检查模块是否已通过 `KeyM_Init()` 初始化且尚未通过 `KeyM_Deinit()` 反初始化。否则，应设置开发错误 `KEYM_E_UNINIT`。⌋()
**[SWS_KeyM_00145]** ⌈ 如果开发错误处于激活状态，则密钥管理器应在每次提供结果缓冲区的函数中检查所提供的缓冲区是否足够大以存储请求的结果。如果不是，则应设置开发错误 `KEYM_E_SMALL_BUFFER`。⌋()
**[SWS_KeyM_00146]** ⌈ 如果开发错误处于激活状态，则密钥管理器应在每次提供指针的函数中检查指针是否不是 `NULL_PTR`。如果提供了 `NULL_PTR` 但不应提供，则应设置开发错误 `KEYM_E_PARAM_POINTER`。⌋()
##### 8.3.1.2 KeyM_Deinit
**[SWS_KeyM_00047]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | `KeyM_Deinit` |
| Syntax | `void KeyM_Deinit(void)` |
| Service ID[hex] | 0x02 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | None |
| Parameters (inout) | None |
| Parameters (out) | None |
| Return value | None |
| Description | 此函数将密钥管理模块重置为未初始化状态。 |
| Available via | KeyM.h |
⌋()
**[SWS_KeyM_00048]** ⌈ 出于安全原因，加密密钥子模块应主动销毁 RAM 中用于加密密钥材料的所有数据。特别地，应将对称密钥和中间结果设置为初始值。⌋()
##### 8.3.1.3 KeyM_GetVersionInfo
**[SWS_KeyM_00049]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | `KeyM_GetVersionInfo` |
| Syntax | `void KeyM_GetVersionInfo(Std_VersionInfoType* VersionInfo)` |
| Service ID[hex] | 0x03 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | None |
| Parameters (inout) | None |
| Parameters (out) | `VersionInfo` — 指向本模块版本信息的指针 |
| Return value | None |
| Description | 提供本模块的版本信息。 |
| Available via | KeyM.h |
⌋ (SRS_BSW_00407)
#### 8.3.2 加密密钥操作
##### 8.3.2.1 KeyM_Start
**[SWS_KeyM_00050]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | `KeyM_Start` |
| Syntax | `Std_ReturnType KeyM_Start(KeyM_StartType StartType, const uint8* RequestData, uint16 RequestDataLength, uint8* ResponseData, uint16* ResponseDataLength)` |
| Service ID[hex] | 0x04 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | `StartType` — 定义密钥操作应以哪种模式执行；`RequestData` — 随请求一起提供的信息，例如签名；`RequestDataLength` — RequestData 数组中的数据长度 |
| Parameters (inout) | `ResponseDataLength` — In：`ResponseData` 中可用的最大字节数；Out：实际数量 |
| Parameters (out) | `ResponseData` — 函数返回的数据 |
| Return value | `E_OK`/`E_NOT_OK`/`KEYM_E_PARAMETER_MISMATCH`/`KEYM_E_KEY_CERT_SIZE_MISMATCH` |
| Description | 此函数是可选的，仅当配置项 `KeyMCryptoKeyStartFinalizeFunctionEnabled` 设置为 true 时才使用。它旨在允许密钥更新操作。 |
| Available via | KeyM.h |
⌋()
**[SWS_KeyM_00085]** ⌈ 如果 `KeyMCryptoKeyStartFinalizeFunctionEnabled` 设置为 TRUE，则应调用此函数以启动密钥更新会话。该函数通过 `E_OK` 指示现在可以进行密钥操作。⌋()
##### 8.3.2.2 KeyM_Finalize
`KeyM_Finalize()` 函数结束密钥更新会话。它将为所有已更新的密钥触发对 `Csm_KeySetValid()` 的调用。
##### 8.3.2.3 KeyM_Prepare
`KeyM_Prepare()` 函数（可选）用于在密钥更新会话开始时提供初始数据。它由密钥处理器 `KeyM_KH_Prepare()` 调用以执行 OEM 特定操作。
##### 8.3.2.4 KeyM_Update
**[SWS_KeyM_00056..00066]** 定义了 `KeyM_Update()` 函数及其变体的行为：
| 函数 | 描述 |
|---|---|
| `KeyM_Update()` | 触发密钥更新操作。使用 `keyNameLength` 或 SHE M1M2M3 解释输入数据 |
| `KeyM_KH_Update()` | 密钥处理器更新回调函数。允许 OEM 特定的密钥更新逻辑 |
| `KeyM_UpdateAsync()` | 异步版本的 `KeyM_Update()` |
具体行为根据 `KeyMCryptoKeyHandlerUpdateEnabled` 和 `KeyMCryptoKeyGenerationType` 而定。
##### 8.3.2.5 KeyM_Verify
**[SWS_KeyM_00068]** ⌈ 如果 `KeyMCryptoKeyVerifyFunctionEnabled` 设置为 TRUE，则提供函数 `KeyM_Verify()`。该函数可用于运行由 `KeyMCryptoKeyCsmVerifyJobRef` 引用的加密作业来验证密钥。⌋()
#### 8.3.3 证书处理
##### 8.3.3.1 KeyM_SetCertificate
`KeyM_SetCertificate()` 函数存储证书以供验证。证书放置在预配置的 `KeyMCryptoKey` 存储类中。该函数仅用于验证提交的证书，不用于永久存储。
##### 8.3.3.2 KeyM_ServiceCertificate
`KeyM_ServiceCertificate()` 函数用于永久存储证书的引入或更新。
##### 8.3.3.3 KeyM_VerifyCertificate, KeyM_VerifyCertificates, KeyM_VerifyCertificateChain
**`KeyM_VerifyCertificate`**：验证单个证书。
**`KeyM_VerifyCertificates`**：验证多个证书。
**`KeyM_VerifyCertificateChain`**：验证完整证书链。
返回代码：
| 返回代码 | 描述 |
|---|---|
| `KEYM_E_CERT_INVALID_CHAIN_OF_TRUST` | 信任链无效 |
| `KEYM_E_CERT_INVALID_CONTENT` | 证书内容无效 |
| `KEYM_E_CERT_INVALID_FORMAT` | 证书格式无效 |
| `KEYM_E_CERT_VALIDITY_PERIOD_FAIL` | 证书有效期失败 |
| `KEYM_E_CERT_SIGNATURE_FAIL` | 签名验证失败 |
| `KEYM_E_CERTIFICATE_REVOKED` | 证书已吊销 |
##### 8.3.3.4 KeyM_GetCertificate, KeyM_GetCertificateElement, KeyM_SetCertificateElement
**`KeyM_GetCertificate`**：检索存储的证书。
**`KeyM_GetCertificateElement`**：从证书中检索特定元素。
**`KeyM_SetCertificateElement`**：设置证书中的元素。
##### 8.3.3.5 KeyM_CertElementIteratorInit, KeyM_CertElementIteratorNext, KeyM_CertElementIteratorDestroy
**`KeyM_CertElementIteratorInit`**：初始化证书元素迭代器。
**`KeyM_CertElementIteratorNext`**：获取迭代器中的下一个证书元素。
**`KeyM_CertElementIteratorDestroy`**：销毁证书元素迭代器。
### 8.4 Call-out 定义
KeyM 模块提供了一组 call-out 函数，允许 OEM 或供应商实现特定的处理逻辑：
- `KeyM_KH_Start()` — 启动密钥处理器
- `KeyM_KH_Prepare()` — 准备密钥处理器
- `KeyM_KH_Update()` — 更新密钥处理器
- `KeyM_KH_Finalize()` — 完成密钥处理器
### 8.5 调度函数
#### 8.5.1 KeyM_MainFunction
`KeyM_MainFunction()` 是 KeyM 模块的主函数。它由 BSW 调度器周期性调用以处理异步操作。
#### 8.5.2 KeyM_MainBackgroudFunction
`KeyM_MainBackgroudFunction()` 是 KeyM 模块的后台主函数。它由 BSW 调度器周期性调用以处理后台任务（例如证书预解析和预验证）。
### 8.6 预期接口
#### 8.6.1 必需接口
KeyM 模块所需的所有必需接口：
| API 函数 | 头文件 | 描述 |
|---|---|---|
| `Csm_KeyElementSet` | Csm.h | 设置密钥元素 |
| `Csm_KeyElementGet` | Csm.h | 获取密钥元素 |
| `Csm_KeySetValid` | Csm.h | 设置密钥有效 |
| `Csm_KeyDerive` | Csm.h | 派生密钥 |
| `Csm_KeyGenerate` | Csm.h | 生成密钥 |
| `Csm_KeyExchangeCalcPubVal` | Csm.h | 计算密钥交换公钥值 |
| `Csm_KeyExchangeCalcSecret` | Csm.h | 计算密钥交换共享密钥 |
| `Csm_CertificateParse` | Csm.h | 解析证书 |
| `Csm_CertificateVerify` | Csm.h | 验证证书 |
| `Csm_SignatureVerify` | Csm.h | 验证签名 |
| `StbM_GetCurrentTime` | StbM.h | 获取当前同步时间 |
#### 8.6.2 可选接口
KeyM 模块的所有可选接口：
| API 函数 | 头文件 | 描述 |
|---|---|---|
| `NvM_ReadBlock` | NvM.h | 读取 NVM 块 |
| `NvM_WriteBlock` | NvM.h | 写入 NVM 块 |
| `NvM_SetRamBlockStatus` | NvM.h | 设置 RAM 块状态 |
#### 8.6.3 可配置接口
KeyM 模块允许通过配置来定义自定义接口（call-outs）。详见原文 PDF 第 47-55 页。
### 8.7 服务接口
#### 8.7.1 本章范围
本章定义 KeyM 模块作为 AUTOSAR 服务组件提供的服务接口。这些服务接口允许通过 RTE 进行访问。
#### 8.7.2 数据类型
KeyM 模块定义了一组数据类型用于服务接口：
- `KeyM_StartType` — 启动类型
- `KeyM_CertificateStatusType` — 证书状态类型
- `KeyM_CertificateElementIdType` — 证书元素 ID 类型
- `KeyM_CertificateElementType` — 证书元素类型
- 等等
> 完整数据类型定义请参阅原始 PDF 文档第 56-62 页。
#### 8.7.3 客户端-服务器接口
KeyM 模块提供了一组客户端-服务器接口：
- `KeyM_StartFinalize` — 启动/完成服务
- `KeyM_Update` — 密钥更新服务
- `KeyM_Verify` — 密钥验证服务
- `KeyM_Certificate` — 证书服务
- 等等
> 完整客户端-服务器接口定义请参阅原始 PDF 文档第 62-75 页。
#### 8.7.4 端口
KeyM 模块定义了服务接口的端口配置。
> 完整端口定义请参阅原始 PDF 文档第 76-78 页。
---
## 9 序列图
本章提供 KeyM 模块关键操作的序列图。
### 9.1 存储单个密钥
> 详见原始 PDF 文档第 79 页。
### 9.2 存储多个密钥
> 详见原始 PDF 文档第 80 页。
### 9.3 派生密钥
> 详见原始 PDF 文档第 81 页。
### 9.4 添加工作证书
> 详见原始 PDF 文档第 82 页。
### 9.5 添加根证书或中间证书
> 详见原始 PDF 文档第 83 页。
---
## 10 配置规范
第 10.1 章规定 KeyM 模块的结构（容器）和参数。第 10.2 章另外规定 KeyM 模块的发布信息。
### 10.1 容器和配置参数
#### 10.1.1 KeyM
`KeyM` 根容器配置密钥管理模块。
| 包含的容器 | 多重性 | 范围 / 依赖 |
|---|---|---|
| `KeyMGeneral` | 1 | 公共配置 |
| `KeyMCertificate` | 0..* | 证书容器 |
| `KeyMCryptoKey` | 0..* | 加密密钥容器 |
#### 10.1.2 KeyMGeneral
`KeyMGeneral` 容器定义公共配置选项：
| 参数 | 描述 |
|---|---|
| `KeyMDevErrorDetect` | 启用/禁用开发错误检测 |
| `KeyMVersionInfoApi` | 启用/禁用 `KeyM_GetVersionInfo()` API |
| `KeyMCryptoKeyManagerEnabled` | 启用/禁用加密密钥子模块 |
| `KeyMCertificateManagerEnabled` | 启用/禁用证书子模块 |
| `KeyMCryptoKeyStartFinalizeFunctionEnabled` | 启用 `KeyM_Start`/`KeyM_Finalize` 函数 |
| `KeyMCryptoKeyHandlerStartFinalizeEnabled` | 启用密钥处理器 Start/Finalize |
| `KeyMCryptoKeyPrepareFunctionEnabled` | 启用 `KeyM_Prepare` 函数 |
| `KeyMCryptoKeyHandlerPrepareEnabled` | 启用密钥处理器 Prepare |
| `KeyMCryptoKeyHandlerUpdateEnabled` | 启用密钥处理器 Update |
| `KeyMCryptoKeyVerifyFunctionEnabled` | 启用 `KeyM_Verify` 函数 |
| `KeyMServiceCertificateFunctionEnabled` | 启用 `KeyM_ServiceCertificate` 函数 |
| 等等 | |
#### 10.1.3 KeyMCertificate
`KeyMCertificate` 容器定义单个证书：
| 参数 | 描述 |
|---|---|
| `KeyMCertificateId` | 证书的标识符 |
| `KeyMCertificateName` | 证书的名称 |
| `KeyMCertUpperHierarchicalCertRef` | 对上层证书的引用 |
| `KeyMCertCsmSignatureVerifyJobRef` | 对签名验证作业的引用 |
| `KeyMCertCsmSignatureVerifyKeyRef` | 对签名验证密钥的引用 |
| `KeyMCertCryptoKeyRef` | 对加密密钥的引用 |
| 等等 | |
#### 10.1.4 KeyMCertificateElement
`KeyMCertificateElement` 容器定义证书中的元素：
| 参数 | 描述 |
|---|---|
| `KeyMCertificateElementId` | 证书元素的标识符 |
| `KeyMCertificateElementOID` | 元素的对象标识符 (OID) |
| `KeyMCertificateElementDescription` | 元素的描述 |
| 等等 | |
#### 10.1.5 KeyMCertificateElementVerification
`KeyMCertificateElementVerification` 容器定义证书元素的验证：
| 参数 | 描述 |
|---|---|
| `KeyMCertificateElementVerificationId` | 验证标识符 |
| `KeyMCertificateElementRef` | 对要验证的证书元素的引用 |
| `KeyMCertificateElementRuleRef` | 对验证规则的引用 |
| 等等 | |
#### 10.1.6 KeyMCertificateElementRule
`KeyMCertificateElementRule` 容器定义验证规则。
#### 10.1.7 KeyMCertificateElementCondition
`KeyMCertificateElementCondition` 容器定义验证条件。
#### 10.1.8 KeyMCertificateElementConditionPrimitive
`KeyMCertificateElementConditionPrimitive` 容器定义基于原语的验证条件。
#### 10.1.9 KeyMCertificateElementConditionArray
`KeyMCertificateElementConditionArray` 容器定义基于数组的验证条件。
#### 10.1.10 KeyMCertificateElementConditionArrayElement
`KeyMCertificateElementConditionArrayElement` 容器定义数组中的单个条件元素。
#### 10.1.11 KeyMCertificateElementConditionValue
`KeyMCertificateElementConditionValue` 容器定义值匹配条件。
#### 10.1.12 KeyMCertificateElementConditionSenderReceiver
`KeyMCertificateElementConditionSenderReceiver` 容器定义发送者-接收者条件。
#### 10.1.13 KeyMCryptoKey
`KeyMCryptoKey` 容器定义单个加密密钥：
| 参数 | 描述 |
|---|---|
| `KeyMCryptoKeyId` | 加密密钥的标识符 |
| `KeyMCryptoKeyName` | 加密密钥的名称 |
| `KeyMCryptoKeyCryptoProps` | 加密属性 |
| `KeyMCryptoKeyGenerationType` | 生成类型（`KEYM_STORED_KEY` 或 `KEYM_DERIVE_KEY`） |
| `KeyMCryptoKeyCsmKeyTargetRef` | 对目标 CsmKey 的引用 |
| `KeyMCryptoKeyCsmKeySourceDeriveRef` | 对源 CsmKey 的引用（派生时） |
| `KeyMCryptoKeyCsmVerifyJobRef` | 对验证作业的引用 |
| 等等 | |
#### 10.1.14 KeyMNvmBlock
`KeyMNvmBlock` 容器定义与 NVM 块关联的密钥：
| 参数 | 描述 |
|---|---|
| `KeyMNvmBlockId` | NVM 块的标识符 |
| `KeyMNvmBlockRef` | 对 NVM 块的引用 |
| `KeyMCryptoKeyRef` | 对加密密钥的引用 |
| 等等 | |
> 完整容器配置定义（包括每个参数的详细说明、范围、默认值等）请参阅原始 PDF 文档第 84-112 页。
### 10.2 发布信息
发布信息包含由 SW 模块实施者定义的数据，这些数据在模块适配（即配置）到实际硬件/软件环境时不会更改。因此它包含版本和制造商信息。
> 完整发布参数定义请参阅原始 PDF 文档第 112 页。
---
## 11 不适用的需求
不适用。
---
## 翻译说明
- 本文档为 AUTOSAR SWS 907《Specification of Key Manager》(CP 4.4.0) 的中文翻译；
- 文档标识号：907；
- 文档共 113 页，已翻译所有 11 个章节，包括完整的 KeyM 子模块功能规范和关键 API 摘要；
- 保留了所有 AUTOSAR 方框符、API 标识符、模块缩写、算法名和需求 ID；
- 证书子模块包含完整的证书链验证逻辑、PKI 层次结构和验证错误代码；
- 加密密钥子模块包含完整的 Start/Prepare/Update/Finalize 会话管理逻辑、SHE 密钥更新协议；
- API 规范中的所有 25+ 个函数已翻译关键 API，包括 KeyM_Init、KeyM_Deinit、KeyM_GetVersionInfo、KeyM_Start、KeyM_Update、KeyM_Verify、KeyM_SetCertificate、KeyM_ServiceCertificate、KeyM_VerifyCertificate(s)、KeyM_GetCertificate 等；
- 配置规范（10.1）列出所有 14 个主要容器，详细参数定义参见原始 PDF；
- 序列图和详细客户端-服务器接口定义请参见原文 PDF；
- 翻译以保证技术含义准确为前提，语句尽量贴近 AUTOSAR 中文术语库常用译法。
IO/AUTOSAR_SRS_ADCDriver.md
+513
View File
@@ -0,0 +1,513 @@
# ADC 驱动需求（Requirements on ADC Driver）
> **AUTOSAR CP Release 4.4.0**
## 文档元信息
| 字段 | 内容 |
|---|---|
| **文档标题** | ADC 驱动需求（Requirements on ADC Driver） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 111 |
| **文档状态** | Final（最终版） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | ADC 驱动范围澄清；移除不适用文档的引用；编辑性变更 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 新增第 5 章：需求追踪表 |
| 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 | ECU 降级概念添加；TPS 标准化模板的正式更新；BSWAndRTE_Features 的可追溯性 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | SRS_Adc_12824：结果对齐从右对齐更改为可配置对齐；法律声明修订 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律声明修订 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | SRS_Adc_12821 现在对所有通道组有效，与所选模式无关；SRS_Adc_12820 移除了相同组的顺序请求队列；SRS_Adc_12280 移除了单值结果访问模式；所有 ADC 通道组均可访问 ADC 结果缓冲区；新增对上次组转换结果的访问；SRS_Adc_12822 适配任何组中最大通道；SRS_Adc_12291 新增状态 'Stream Completed'；扩展文档元信息；小幅布局调整 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | "用户建议"修订；"修订信息"新增 |
| 2006-11-28 | 2.1 | AUTOSAR Administration | 移除了"On Demand"功能的需求；移除了"Gated Continuous"转换模式的需求；移除了内部和外部硬件触发器之间的区别；引入了通道组优先级机制的需求，以允许更高优先级的通道组中断正在进行的转换；法律声明修订 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 作为独立文档发布。SRS SPAL V1.0.0 已被拆分为 12 个独立文档，以发布 2.0；新增门控连续转换模式需求；新增按需转换模式需求；其他细微变更 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 作为 SRS SPAL V1.0.0 的一部分初始发布 |
---
## 目录（Table of Contents）
1. [文档范围（Scope of Document）](#1-文档范围)
2. [如何阅读本文档（How to Read this Document）](#2-如何阅读本文档)
- 2.1 [使用的约定（Conventions Used）](#21-使用的约定)
- 2.2 [需求结构（Requirements Structure）](#22-需求结构)
3. [缩略语与缩写（Acronyms and Abbreviations）](#3-缩略语与缩写)
4. [功能概述（Functional Overview）](#4-功能概述)
5. [需求追踪（Requirements Tracing）](#5-需求追踪)
6. [需求规范（Requirement Specification）](#6-需求规范)
- 6.1 [功能需求（Functional Requirements）](#61-功能需求)
- 6.1.1 [配置（Configuration）](#611-配置)
- 6.1.2 [正常运行（Normal Operation）](#612-正常运行)
7. [参考文献（References）](#7-参考文献)
- 7.1 [AUTOSAR 交付物（Deliverables of AUTOSAR）](#71-autosar-交付物)
---
## 1 文档范围（Scope of Document）
本文档规定了 ADC 驱动模块的需求。ADC 驱动针对逐次逼近型 ADC 硬件。Delta Sigma ADC 转换需求不在本文档的范围内。
### 约束（Constraints）
基础软件模块需求规范的首要范围是非安全相关系统。因此，安全需求被分配到中等优先级。
---
## 2 如何阅读本文档（How to Read this Document）
每个需求都有其唯一的标识符，以 "BSW"（"Basic Software" 的缩写）前缀开头。对于任何审阅注释、评论或问题，请参考此唯一 ID 而不是章节或页码！
### 2.1 使用的约定（Conventions Used）
- AUTOSAR 文档中需求的表示遵循 [5] / [TPS_STDT_00078] 中指定的表。
- 在需求中，使用以下特定语义。
本文件中使用的关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照所示进行解释。请注意，它们所使用文档的需求级别会修改这些词的强制力。
- **MUST**：这个词，或术语 "REQUIRED" 或 "SHALL"，意味着该定义是规范的绝对要求。
- **MUST NOT**：这个词组，或词组 "SHALL NOT"，意味着该定义是规范的绝对禁止。
- **SHOULD**：意味着在特定情况下可能存在忽略特定条目的有效理由。
- **SHOULD NOT**：意味着在特定情况下特定行为可能是可接受的甚至是有用的。
- **MAY**：这个词，或形容词 "OPTIONAL"，意味着某个项目是真正可选的。
### 2.2 需求结构（Requirements Structure）
每个模块特定章节包含基础软件模块的简短功能描述。同一类型的需求在每个章节内按以下标题分组（如果适用）：
**功能需求（Functional Requirements）：**
- 配置（Configuration）
- 初始化（Initialization）
- 正常运行（Normal Operation）
- 关闭操作（Shutdown Operation）
- 故障操作（Fault Operation）
- ...
**非功能需求（Non-Functional Requirements）：**
- 时间需求（Timing Requirements）
- 资源使用（Resource Usage）
- 可用性（Usability）
- 对其他 WP 的输出
- ...
---
## 3 缩略语与缩写（Acronyms and Abbreviations）
| 缩略语 | 描述 |
|---|---|
| CS | 片选（Chip select） |
| DIO | 数字输入输出（Digital Input Output） |
| ECU | 电控单元（Electric Control Unit） |
| EOL | 终端产线（End Of Line） |
| ICU | 输入捕获单元（Input Capture Unit） |
| MAL | 微控制器抽象层的旧名称（已被 MCAL 取代） |
| MCAL | 微控制器抽象层（Microcontroller Abstraction Layer） |
| MCU | 微控制器单元（Microcontroller Unit） |
| MMU | 内存管理单元（Memory Management Unit） |
| Master | 控制其他设备的设备 |
| Slave | 完全由主设备控制的设备 |
| NMI | 不可屏蔽中断（Non maskable interrupt） |
| OS | 操作系统（Operating System） |
| PLL | 锁相环（Phase Locked Loop） |
| PWM | 脉宽调制（Pulse Width Modulation） |
| RX | 接收（Reception，在总线通信的上下文中） |
| SPAL | 此工作组名称 |
| SFR | 特殊功能寄存器（Special Function Register） |
| RTE | 运行时环境（Runtime environment） |
| WP | 工作包（Work Package） |
| ADC | 模数转换器（Analogue Digital Converter） |
| FFT | 快速傅里叶变换器（Fast Fourier Transformer） |
| 缩写 | 描述 |
|---|---|
| STD | 标准（Standard） |
| REQ | 需求（Requirement） |
| UNINIT | 未初始化（Uninitialized） |
ADC 驱动中使用以下表达式：
| 表达式 | 解释 |
|---|---|
| HW Unit（硬件单元） | 表示微控制器输入电子设备，包括执行"模数转换"所需的所有部件。 |
| ADC channel（ADC 通道） | 表示绑定到一个端口引脚的逻辑 ADC 实体。多个 ADC 实体可以映射到同一个端口引脚。 |
| ADC channel group（ADC 通道组） | 链接到同一 ADC 硬件单元（例如一个采样保持器和一个 A/D 转换器）的 ADC 通道组。整个组的转换由一个触发源触发。 |
| ADC result buffer（ADC 结果缓冲区） | ADC 驱动用户必须为每个组提供一个缓冲区。如果选择了流访问模式，则此缓冲区可以保存同一通道组的多个样本。如果选择了单次访问模式，则缓冲区中保存每个组通道的一个样本。 |
| Trigger Source（触发源） | 启动单次转换或连续转换序列的源事件。 |
| Conversion Mode（转换模式） | **One-Shot（一次性）：** 在触发后执行一次 ADC 通道组的转换，并将结果写入分配的缓冲区。触发可以是软件 API 调用或硬件事件。<br>**Continuous（连续）：** 在软件 API 调用（启动）后连续执行 ADC 通道组的转换。转换本身自动运行（由硬件/中断控制）。可以通过软件 API 调用（停止）停止连续转换。 |
| Sampling Time（采样时间） | 对模拟值进行采样的时间（例如对电容进行充电等）。 |
| Conversion Time（转换时间） | 将采样的模拟值转换为数字表示的时间。 |
| Acquisition Time（采集时间） | 采样时间 + 转换时间。 |
由于这是面向专业人士的专业文档，其他所有术语均假定为已知。
---
## 4 功能概述（Functional Overview）
ADC 驱动初始化和控制微控制器的内部模数转换器单元。它提供启动和停止转换以及启用和禁用转换触发源的服务。此外，它还提供启用和禁用通知机制的服务以及查询转换状态和结果的例程。
ADC 驱动应工作在所谓的 ADC 通道上。ADC 通道将模拟输入引脚、所需的 ADC 电路本身以及转换结果寄存器组合成一个实体，该实体可以通过 ADC 驱动单独控制和访问。
所有使用的术语都在下一章中指定。
---
## 5 需求追踪（Requirements Tracing）
| 需求 | 描述 | 由...满足 |
|---|---|---|
| RS_BRF_01184 | AUTOSAR 应支持不同的降级方法 | SRS_ADC_12826, SRS_ADC_12827, SRS_ADC_12828, SRS_ADC_12829 |
| RS_BRF_01448 | AUTOSAR 服务应支持模式和状态管理 | SRS_ADC_12826, SRS_ADC_12827, SRS_ADC_12828 |
| RS_BRF_01872 | AUTOSAR 微控制器抽象应提供 I/O 信号到模数转换器端口的映射 | SRS_Adc_12280, SRS_Adc_12283, SRS_Adc_12288, SRS_Adc_12291, SRS_Adc_12292, SRS_Adc_12307, SRS_Adc_12317, SRS_Adc_12318, SRS_Adc_12364, SRS_Adc_12447, SRS_Adc_12802, SRS_Adc_12817, SRS_Adc_12818, SRS_Adc_12819, SRS_Adc_12820, SRS_Adc_12821, SRS_Adc_12822, SRS_Adc_12823, SRS_Adc_12824, SRS_Adc_12825 |
| RS_BRF_01952 | AUTOSAR IO 硬件抽象应支持已连接 I/O 设备的标准化模式 | SRS_ADC_12829 |
---
## 6 需求规范（Requirement Specification）
### 6.1 功能需求（Functional Requirements）
#### 6.1.1 配置（Configuration）
**6.1.1.1 [SRS_Adc_12307] ADC 驱动应支持每个通道的特定基本静态配置**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应支持每个通道的以下基本静态配置（如果硬件支持）：<br>- 通道的符号名称<br>- 采样时间<br>- 转换时间<br>- 分辨率（位）<br>- 参考电压源<br>- 时钟源及可选的预分频器设置<br>- 其他 MCU 依赖参数<br><br>**注意：** 如果其中一个或多个配置参数只能分配给整个模块，则由配置工具优化数据表示。 |
| Rationale | 允许每个通道的不同用法。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.1.2 [SRS_Adc_12447] ADC 驱动应允许将属于同一 ADC HW 单元的 ADC 通道分组**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应允许将属于同一 ADC HW 单元的 ADC 通道分组为所谓的 ADC 通道组（简称组）。ADC 通道组应至少包含一个 ADC 通道。组中的所有通道共享相同的组配置。<br>ADC 驱动应支持每个通道组的以下基本静态配置（如果硬件支持）：<br>- 组的符号名称<br>- 组通知开/关<br>- 回调通知函数<br>- 配置使用的通道列表<br>- 组触发源<br>- 组转换模式 |
| Rationale | 允许使用单个控制线程对多个通道进行采样。 |
| Use Case | 对转换结果应一致的多个通道进行分组。 |
| Dependencies | [SRS_Adc_12307] ADC 通道配置 |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.1.3 [SRS_Adc_12817] ADC 驱动应允许为每个 ADC 通道组静态配置一个触发源**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应允许为每个 ADC 通道组静态配置一个触发源。<br>可能的触发源包括：<br>- 硬件事件（例如 IO 引脚上的事件或 MCU 内部生成的定时器中断），如果硬件支持<br>- SW API 调用 |
| Rationale | 确保一个组仅从一个源控制（避免不一致、并发问题等）。 |
| Use Case | 配置为响应 IO 引脚上的外部中断而进行转换的 ADC 通道组。 |
| Dependencies | [SRS_Adc_12447] ADC 通道组配置 |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.1.4 [SRS_Adc_12818] ADC 驱动应允许将一个 ADC 通道分配给多个 ADC 通道组**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应允许将一个 ADC 通道分配给多个 ADC 通道组。 |
| Rationale | 这允许 ADC 通道在配置为不同组时具有不同的触发源。 |
| Use Case | 通常以循环方式转换（通过硬件事件，在后台）的同一 ADC 通道可以通过 SW API 调用进行单次转换。 |
| Dependencies | -- |
| Supporting Material | **注意：** ADC 驱动不应处理由受影响组的并发操作引起的任何问题。ADC 驱动的用户必须确保不存在此类受影响组的并发操作。 |
⌋(RS_BRF_01872)
**6.1.1.5 [SRS_Adc_12821] 对于所有通道组，ADC 驱动应在配置时提供定义样本存储缓冲区的可能性**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 对于所有通道组，ADC 驱动应在配置时提供定义样本存储缓冲区的可能性。因此，以下参数应添加到 ADC 通道组参数中：<br>- 指向数据缓冲区的指针（转换结果的目标）<br>- ADC 值的数量 |
| Rationale | 所有 ADC 通道组的转换结果都存储在外部缓冲区中。 |
| Use Case | 循环 AD 转换作为电动机控制器的输入。 |
| Dependencies | |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.1.6 [SRS_Adc_12820] ADC 驱动应允许为每个通道组配置优先级**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应允许为每个通道组配置优先级。这隐含了一种优先级机制，在 SW 中实现（或在硬件支持的情况下由硬件支持），它提供以下功能：<br>- 不同组请求的排队<br>- 优先级处理（中止/挂起和重新启动/恢复转换）<br>- 更高优先级组可以中止/挂起更低优先级组<br>- 优先级 0..255，最低优先级 0 |
| Rationale | 通过中断已进行的转换为组提供立即转换（按需）的机会。<br>由于存在嵌套转换请求的可能性，因此有必要定义一个优先级来解决驱动将管理它们的顺序。 |
| Use Case | 触发的转换越来越多地用于动力总成控制器（一个示例是喷油器组电流/电压的测量，需要与燃油脉冲同步进行 - 同时后台正在进行自动扫描转换）。 |
| Dependencies | [SRS_Adc_12447], [SRS_Adc_12818] |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.1.7 [SRS_Adc_12280] ADC 驱动应允许为每个 ADC 通道组设置特定的结果访问模式**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应允许为每个 ADC 通道组设置以下结果访问模式：<br>- 对 ADC 结果缓冲区的结果访问。ADC 结果缓冲区在流访问模式下包含流结果，在单次访问模式下包含上次组转换的结果。<br>- 如果静态配置，应支持对上次组转换结果的结果访问，也支持流访问模式。组通道结果按升序存储在缓冲区中，与流访问模式下 ADC 结果缓冲区的缓冲区布局相反。 |
| Rationale | 在通道组的下一次扫描完成之前，每个通道值都应可访问。 |
| Use Case | -- |
| Dependencies | [SRS_Adc_12447] ADC 通道组配置。 |
| Supporting Material | -- |
⌋(RS_BRF_01872)
#### 6.1.2 正常运行（Normal Operation）
**6.1.2.1 [SRS_Adc_12283] ADC 驱动应屏蔽掉转换结果中不属于 ADC 值的信息位**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应屏蔽掉转换结果中不属于 ADC 值的信息位。 |
| Rationale | 信息位是微控制器特定的。 |
| Use Case | 一些 µC 在结果寄存器中保存信息位（例如通道号）。这些位应被屏蔽掉。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.2.2 [SRS_Adc_12824] 结果对齐应可在右对齐和左对齐之间配置**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 结果对齐应可在右对齐和左对齐之间配置。 |
| Rationale | 信息位是微控制器特定的。<br>驱动和上层中的代码和运行时优化。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.2.3 [SRS_Adc_12819] ADC 驱动应提供读取所选通道组最近有效转换结果的同步服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应提供读取所选通道组（作为参数传递）最近有效转换结果的同步服务。 |
| Rationale | 提供对通道组最近转换值的访问。 |
| Use Case | 这是读取 ADC 值的标准功能。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.2.4 [SRS_Adc_12822] 包含通道组转换结果的结构应以统一的维度生成**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 包含通道组转换结果的结构应由配置工具以统一的维度生成，针对属于任何组的最大（按位数）通道进行定制。 |
| Rationale | 一个组内的通道可能具有不同大小的结果值（例如 8 位、10 位、12 位等）。 |
| Use Case | -- |
| Dependencies | [SRS_Adc_12447] ADC 通道组配置。 |
| Conflicts | -- |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.2.5 [SRS_Adc_12317] ADC 驱动应提供通知函数以通知调用者通道组转换的结束**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应提供通知函数以通知调用者通道组转换的结束。 |
| Rationale | 允许对 ADC 进行非阻塞访问。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.2.6 [SRS_Adc_12291] ADC 驱动应提供查询 ADC 通道组状态的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应提供查询 ADC 通道组状态的服务。<br>ADC 通道组状态应为以下四种之一：<br>- Idle（空闲）<br>- Busy（繁忙，转换进行中）<br>- Completed（已完成）<br>- Stream Completed（流已完成） |
| Rationale | 在读取值之前，可能有必要查询 ADC 的状态。 |
| Use Case | 状态可用于访问同步。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.2.7 [SRS_Adc_12318] ADC 驱动应提供分别启用和禁用每个通知函数的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应提供分别启用和禁用每个通知函数的服务。 |
| Rationale | 防止调用不期望的通知（中断），并允许选择软件执行流中可能出现第一次或下一次通知的确切点。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.2.8 [SRS_Adc_12364] ADC 驱动应提供启动和停止所有转换模式下 ADC 通道组转换的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应提供启动和停止所有转换模式下 ADC 通道组转换的服务。 |
| Rationale | 允许软件控制通道组转换的开始时间。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.2.9 [SRS_Adc_12292] 如果 ADC 提供有符号值，ADC 驱动应将符号位放入返回值的最高位（MSB）**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 如果 ADC 提供有符号值，ADC 驱动应将符号位放入返回值的最高位（MSB）。 |
| Rationale | 允许将 ADC 返回值映射到标准 AUTOSAR 整数数据类型。 |
| Use Case | 某些微控制器提供有符号 ADC 值。<br>示例：12 位 ADC 寄存器，符号位在位 11（在"大端"字节顺序的微控制器中）。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.2.10 [SRS_Adc_12288] 根据通道组配置，ADC 驱动应能够以两种不同方式处理流作业的缓冲区**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 根据通道组配置，ADC 驱动应能够以两种不同方式处理流作业的缓冲区：<br>- 作为"线性缓冲区"，即一旦流缓冲区已满（达到样本数），ADC 驱动就停止转换。<br>- 作为"循环缓冲区"，即即使流缓冲区已满（达到样本数），ADC 驱动也通过环绕缓冲区本身继续转换。 |
| Rationale | 允许自动运行的 ADC 转换循环流。 |
| Use Case | 电动机控制。 |
| Dependencies | [SRS_Adc_12280] ADC 通道组结果访问模式。 |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.2.11 [SRS_Adc_12802] ADC 驱动应为流访问模式提供识别最近样本和可用样本数量的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应为流访问模式提供识别通道组最近样本和可用样本数量的服务。<br>传递的参数应为：<br>- ADC 通道组<br>返回的对象应为：<br>- 样本数量<br>- 指向最后样本的指针 |
| Rationale | 识别哪些样本可以使用。 |
| Use Case | 数字爆震传感器采集。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.2.12 [SRS_Adc_12823] ADC 驱动应提供为每个通道组启用和禁用 HW 触发的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应提供为每个通道组启用和禁用 HW 触发的服务。 |
| Rationale | 提供在运行时忽略即将到来的硬件触发器的可能性。 |
| Use Case | -- |
| Dependencies | [SRS_Adc_12447], [SRS_Adc_12817] |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.2.13 [SRS_Adc_12825] 配置为流访问模式的通道组的转换结果应返回到具有固定元素数量的缓冲区**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 配置为流访问模式的通道组的转换结果应返回到 n*m 个元素（整数）的缓冲区，其中 n 是属于组的通道数，m 是每个通道采集的样本数。因此，前 m 个元素属于组中的第一个通道，第二个 m 个元素属于第二个通道，依此类推。 |
| Rationale | 支持通道组流转换模式。 |
| Use Case | -- |
| Dependencies | [SRS_Adc_12280] ADC 通道组结果访问模式。 |
| Supporting Material | -- |
⌋(RS_BRF_01872)
**6.1.2.14 [SRS_ADC_12826] ADC 驱动应实现允许读取 ADC HW 模块当前电源状态的 API**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应实现允许从 MCAL 模块外部读取 HW 外设当前电源状态的 API。此 API 可由 IoHwAbs 和 CDD SW 组件使用。 |
| Rationale | 必须能够收集有关外设当前电源状态的信息。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | 概念 "ECU Degradation"，V1.8 |
⌋(RS_BRF_01448, RS_BRF_01184)
**6.1.2.15 [SRS_ADC_12827] ADC 驱动应实现允许读取 ADC HW 模块目标电源状态的 API**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应实现允许从 MCAL 模块外部读取 HW 外设目标电源状态的 API。此 API 可由 IoHwAbs 和 CDD SW 组件使用。 |
| Rationale | 获取有关目标电源状态的信息是必要的，以便了解是否正在执行电源状态转换，以及在肯定的情况下，是哪一个。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | 概念 "ECU Degradation"，V1.8 |
⌋(RS_BRF_01448, RS_BRF_01184)
**6.1.2.16 [SRS_ADC_12828] ADC 驱动应将电源状态转换序列分为两部分**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ADC 驱动应将电源状态转换序列分为两部分：准备阶段（允许外设进入目标电源状态的预备配置更改）和设置阶段（有效启用有效电源状态）。 |
| Rationale | 某些外设可能比其他外设需要更多时间来执行进入给定电源状态所需的所有预备转换。<br>通过将过程分为准备阶段和设置阶段，可以同步不同的外设，使其全部同时进入有效的电源状态。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | 概念 "ECU Degradation"，V1.8 |
⌋(RS_BRF_01448, RS_BRF_01184)
**6.1.2.17 [SRS_ADC_12829] 应能配置同步或异步的电源状态转换行为**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 应能配置同步或异步的电源状态转换行为。如果配置了同步行为，则电源转换准备应原子地发生，并且执行它的 SWC 必须等待结果。如果配置了异步行为，则电源转换准备应在请求后在后台进行，并且 MCAL 模块应在完成时通知已注册的 SWC。 |
| Rationale | 某些外设可以在可忽略或可接受的时间内准备为有效电源状态，从而可以节省处理通知所需的基础结构。其他外设可能需要更长的时间来准备目标电源状态。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | 概念 "ECU Degradation"，V1.8 |
⌋(RS_BRF_01184, RS_BRF_01952)
---
## 7 参考文献（References）
### 7.1 AUTOSAR 交付物（Deliverables of AUTOSAR）
- **[1]** 基础软件模块列表，AUTOSAR_TR_BSWModuleList.pdf
- **[2]** 分层软件架构，AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
- **[3]** 基础软件模块的一般需求，AUTOSAR_SRS_BSWGeneral.pdf
- **[4]** SPAL 的一般需求，AUTOSAR_SRS_SPALGeneral.pdf
- **[5]** 软件标准化模板，AUTOSAR_TPS_StandardizationTemplate.pdf
---
## 翻译说明
本文档为 AUTOSAR 4.4.0 版本 ADC 驱动软件需求规范的中文翻译。保留了所有需求 ID（SRS_Adc_xxxxx）、参考标识符及模块缩写。原始文档共 22 页，本翻译涵盖了全部章节内容。ADC 驱动针对逐次逼近型 ADC 硬件；Delta Sigma ADC 转换需求不在范围内。
IO/AUTOSAR_SRS_DIODriver.md
+329
View File
@@ -0,0 +1,329 @@
# DIO 驱动需求（Requirements on DIO Driver）
> **AUTOSAR CP Release 4.4.0**
## 文档元信息
| 字段 | 内容 |
|---|---|
| **文档标题** | DIO 驱动需求（Requirements on DIO Driver） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 191 |
| **文档状态** | Final（最终版） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 移除对 BMW 和 HIS 文档的引用；编辑性变更 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 新增第 5 章：需求追踪 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 编辑性变更 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 编辑性变更 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 需求 ID 变更；更新以实现需求可追溯性 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 新增 SRS_Dio_12900 |
| 2010-09-30 | 3.1.5 | 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 | 作为独立文档发布。SRS SPAL V1.0.0 已被拆分为 15 个独立文档，以发布 2.0 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 作为 SRS SPAL V1.0.0 的一部分初始发布 |
---
## 目录（Table of Contents）
1. [文档范围（Scope of document）](#1-文档范围)
- 1.1 [约束（Constraints）](#11-约束)
2. [如何阅读本文档（How to read this document）](#2-如何阅读本文档)
- 2.1 [使用的约定（Conventions used）](#21-使用的约定)
- 2.2 [需求结构（Requirement structure）](#22-需求结构)
3. [缩略语与缩写（Acronyms and abbreviations）](#3-缩略语与缩写)
4. [功能概述（Functional Overview）](#4-功能概述)
- 4.1 [DIO 驱动（DIO Driver）](#41-dio-驱动)
5. [需求追踪（Requirements Tracing）](#5-需求追踪)
6. [需求规范（Requirement Specification）](#6-需求规范)
- 6.1 [功能需求（Functional Requirements）](#61-功能需求)
- 6.1.1 [DIO 驱动](#611-dio-驱动)
- 6.2 [非功能需求（Non-Functional Requirements）](#62-非功能需求)
- 6.2.1 [DIO 驱动](#621-dio-驱动)
7. [参考文献（References）](#7-参考文献)
- 7.1 [AUTOSAR 交付物（Deliverables of AUTOSAR）](#71-autosar-交付物)
---
## 1 文档范围（Scope of document）
本文档规定了 DIO 驱动模块的需求。
### 1.1 约束（Constraints）
基础软件模块需求规范的首要范围是非安全相关系统。因此，安全需求被分配到中等优先级。
---
## 2 如何阅读本文档（How to read this document）
每个需求都有其唯一的标识符，以 "BSW"（"Basic Software" 的缩写）前缀开头。对于任何审阅注释、评论或问题，请参考此唯一 ID 而不是章节或页码！
### 2.1 使用的约定（Conventions used）
- AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中指定的表。
- 在需求中，使用以下特定语义（取自互联网工程任务组 IETF 的征求意见稿 RFC 2119）。
本文件中使用的关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照 RFC 2119 中的描述进行解释。请注意，它们所使用文档的需求级别会修改这些词的强制力。
- **MUST**：这个词，或术语 "REQUIRED" 或 "SHALL"，意味着该定义是规范的绝对要求。
- **MUST NOT**：这个词组，或词组 "SHALL NOT"，意味着该定义是规范的绝对禁止。
- **SHOULD**：这个词，或形容词 "RECOMMENDED"，意味着在特定情况下可能存在忽略特定条目的有效理由，但在选择不同方案之前必须充分理解并仔细权衡其全部含义。
- **SHOULD NOT**：这个词组，或词组 "NOT RECOMMENDED"，意味着在特定情况下特定行为可能是可接受的甚至是有用的，但在实现任何带有此标签描述的行为之前，应理解其全部含义并仔细权衡该情况。
- **MAY**：这个词，或形容词 "OPTIONAL"，意味着某个项目是真正可选的。
### 2.2 需求结构（Requirement structure）
每个模块特定章节包含基础软件模块的简短功能描述。同一类型的需求在每个章节内按以下标题分组（如果适用）：
**功能需求（Functional Requirements）：**
- 配置（Configuration）
- 初始化（Initialisation）
- 正常运行（Normal Operation）
- 关闭操作（Shutdown Operation）
- 故障操作（Fault Operation）
- ...
**非功能需求（Non-Functional Requirements）：**
- 时间需求（Timing Requirements）
- 资源使用（Resource Usage）
- 可用性（Usability）
- 对其他 WP 的输出
- ...
---
## 3 缩略语与缩写（Acronyms and abbreviations）
| 缩略语 | 描述 |
|---|---|
| CS | 片选（Chip select） |
| DIO | 数字输入输出（Digital Input Output） |
| ECU | 电控单元（Electric Control Unit） |
| EOL | 终端产线（End Of Line），常用于 "EOL 编程" 或 "EOL 配置" |
| ICU | 中断捕获单元（Interrupt Capture Unit） |
| MAL | 微控制器抽象层的旧名称（已被 MCAL 取代，因为 'MAL' 在法语中意为 'bad'） |
| MCAL | 微控制器抽象层（Microcontroller Abstraction Layer） |
| MCU | 微控制器单元（Microcontroller Unit） |
| MMU | 内存管理单元（Memory Management Unit） |
| Master | 控制其他设备（从设备）的设备 |
| Slave | 完全由主设备控制的设备 |
| NMI | 不可屏蔽中断（Non maskable interrupt） |
| OS | 操作系统（Operating System） |
| PLL | 锁相环（Phase Locked Loop） |
| PWM | 脉宽调制（Pulse Width Modulation） |
| RX | 接收（Reception，在总线通信的上下文中） |
| SPAL | 此工作组名称 |
| SFR | 特殊功能寄存器（Special Function Register） |
| RTE | 运行时环境（Runtime environment） |
| WP | 工作包（Work Package） |
| 缩写 | 描述 |
|---|---|
| STD | 标准（Standard） |
| REQ | 需求（Requirement） |
| UNINIT | 未初始化（Uninitialized） |
由于这是面向专业人士的专业文档，其他所有术语均假定为已知。
---
## 4 功能概述（Functional Overview）
### 4.1 DIO 驱动（DIO Driver）
DIO 驱动提供基于端口和通道的读写访问，以访问内部通用 I/O 端口。读写行为是无缓冲的。此驱动的基本行为是同步的。
DIO 驱动中使用以下表达式：
| 表达式 | 解释 |
|---|---|
| DIO 通道（DIO channel） | 表示单个通用数字输入/输出引脚 |
| DIO 端口（DIO port） | 表示由硬件分组的多个 DIO 通道，可同步访问（通常由一个硬件寄存器控制）。例如：Freescale HC08 的 Port A（8 位） |
| DIO 通道组（DIO channel group） | 表示由逻辑组表示的多个相邻 DIO 通道。DIO 通道组是 DIO 端口的一个子集，可同步访问。例如：8 位端口的端口引脚 2..6 |
---
## 5 需求追踪（Requirements Tracing）
| 需求 | 描述 | 由...满足 |
|---|---|---|
| RS_BRF_01024 | AUTOSAR 应提供公共符号的命名规则 | SRS_Dio_12355 |
| RS_BRF_01864 | AUTOSAR 微控制器抽象应提供 I/O 信号到数字 I/O 端口的映射 | SRS_Dio_12003, SRS_Dio_12004, SRS_Dio_12005, SRS_Dio_12006, SRS_Dio_12007, SRS_Dio_12008, SRS_Dio_12352, SRS_Dio_12424, SRS_Dio_12900 |
---
## 6 需求规范（Requirement Specification）
### 6.1 功能需求（Functional Requirements）
#### 6.1.1 DIO 驱动
##### 6.1.1.1 配置与初始化（Configuration and Initialization）
端口结构的配置和初始化不属于 DIO 驱动的范畴。这由 Port 驱动完成（请参见 [SRS_Port_12001] 端口引脚属性配置）。
**6.1.1.1.1 [SRS_Dio_12355] 应配置符号名称**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | DIO 驱动应允许对以下符号名称进行静态配置：<br>- DIO 通道名称<br>- DIO 通道组名称<br>- DIO 端口名称 |
| Rationale | 为 DIO 通道提供人类可读的符号名称。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01024)
##### 6.1.1.2 正常运行（Normal Operation）
**6.1.1.2.1 [SRS_Dio_12003] DIO 驱动应提供将数据字写入已分配 DIO 端口的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | DIO 驱动应提供将数据字写入已分配 DIO 端口的服务。<br>该操作应为无缓冲的。<br>对端口的输入功能不应有影响。 |
| Rationale | 基本功能 |
| Use Case | 对整个 DIO 端口的写访问。 |
| Dependencies | [SRS_Dio_12352] 一般读/写行为 |
| Supporting Material | -- |
⌋(RS_BRF_01864)
**6.1.1.2.2 [SRS_Dio_12004] DIO 驱动应提供将可选数量的相邻位写入 DIO 端口已分配部分的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | DIO 驱动应提供将可选数量的相邻位写入 DIO 端口已分配部分的服务。该操作应为无缓冲的。 |
| Rationale | 允许同时设置具有多个外部分配的 DIO 端口的一组 DIO 通道。 |
| Use Case | 对具有多个分配的 DIO 端口的写访问。 |
| Dependencies | [SRS_Dio_12352] 一般读/写行为 |
| Supporting Material | -- |
⌋(RS_BRF_01864)
**6.1.1.2.3 [SRS_Dio_12005] DIO 驱动应提供对单个 DIO 通道的写访问服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | DIO 驱动应提供对单个 DIO 通道（特定端口引脚）的写访问服务。 |
| Rationale | 高效处理单个 DIO 通道。 |
| Use Case | 对特定 DIO 通道（端口引脚）的写访问。 |
| Dependencies | [SRS_Dio_12352] 一般读/写行为 |
| Supporting Material | -- |
⌋(RS_BRF_01864)
**6.1.1.2.4 [SRS_Dio_12006] DIO 驱动应提供从已分配 DIO 端口读取数据字的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | DIO 驱动应提供从已分配 DIO 端口读取数据字的服务。该操作应为无缓冲的。对端口的输出功能不应有影响。 |
| Rationale | 基本功能 |
| Use Case | 对整个 DIO 端口的读访问。 |
| Dependencies | [SRS_Dio_12352] 一般读/写行为 |
| Supporting Material | -- |
⌋(RS_BRF_01864)
**6.1.1.2.5 [SRS_Dio_12007] DIO 驱动应提供从 DIO 端口已分配部分读取可选数量相邻位的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | DIO 驱动应提供从 DIO 端口已分配部分读取可选数量相邻位的服务。该操作应为无缓冲的。 |
| Rationale | 基本功能 |
| Use Case | 对具有多个分配的 DIO 端口的读访问。 |
| Dependencies | [SRS_Dio_12352] 一般读/写行为 |
| Supporting Material | -- |
⌋(RS_BRF_01864)
**6.1.1.2.6 [SRS_Dio_12008] DIO 驱动应提供读取已分配 DIO 通道一个位的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | DIO 驱动应提供读取已分配 DIO 通道（特定端口引脚）一个位的服务。该操作应为无缓冲的。 |
| Rationale | 高效处理单个 DIO 通道。 |
| Use Case | 对特定 DIO 通道的读访问。 |
| Dependencies | [SRS_Dio_12352] 一般读/写行为 |
| Supporting Material | -- |
⌋(RS_BRF_01864)
**6.1.1.2.7 [SRS_Dio_12900] DIO 驱动应提供翻转服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | DIO 驱动应提供翻转服务（将已分配 DIO 通道（特定端口引脚）的一个位从 1 翻转为 0 或从 0 翻转为 1）并在翻转后返回该通道的电平。该操作应为无缓冲的。 |
| Rationale | 高效处理单个 DIO 通道。 |
| Use Case | 对特定 DIO 通道进行翻转电平的读和写访问。 |
| Dependencies | [SRS_Dio_12352] 一般读/写行为 |
| Supporting Material | -- |
⌋(RS_BRF_01864)
**6.1.1.2.8 [SRS_Dio_12352] DIO 驱动应允许对 DIO 端口、通道组和通道进行读写**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | DIO 驱动应允许对 DIO 端口、通道组和通道进行读写，而不考虑其方向配置。<br><br>如果对配置为输入的通道进行写入，则该值应写入输出寄存器，但不会出现在物理端口引脚上。<br><br>如果读取配置为输出的通道，则在硬件支持的情况下读取真实引脚电平的值。否则，读取端口输出寄存器的值。 |
| Rationale | 简化所有 DIO 读写服务的实现。允许输出引脚的回读。允许在将端口引脚切换到输出方向之前预设输出值。 |
| Use Case | 请参见原理。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01864)
### 6.2 非功能需求（Non-Functional Requirements）
#### 6.2.1 DIO 驱动
**6.2.1.1 [SRS_Dio_12424] 提供 DIO 访问的原子性**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | DIO 驱动的所有可重入函数应以原子方式执行以下访问操作：<br>- DIO 端口<br>- DIO 通道<br>- DIO 通道组 |
| Rationale | 避免 DIO 驱动 API 函数并发访问中的数据完整性问题。 |
| Use Case | 特定微控制器（或特定编译器）不提供对单个端口引脚的原子访问。因此，实现必须对整个端口使用读-修改-写操作。如果不阻塞并发访问，则对同一端口的引脚的并发访问将导致数据完整性问题。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01864)
---
## 7 参考文献（References）
### 7.1 AUTOSAR 交付物（Deliverables of AUTOSAR）
- **[DOC_LAYERED_ARCH]** 分层软件架构，AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
- **[AUTOSAR_GLOSSARY]** 词汇表，AUTOSAR_TR_Glossary.pdf
- **[SRS_BSW_GENERAL]** 基础软件模块的一般需求，AUTOSAR_SRS_BSWGeneral.pdf
- **[SRS_BSW_SPAL]** SPAL 的一般需求，AUTOSAR_SRS_SPALGeneral.pdf
- **[TPS_STDT_0078]** 软件标准化模板，AUTOSAR_TPS_StandardizationTemplate.pdf
---
## 翻译说明
本文档为 AUTOSAR 4.4.0 版本 DIO 驱动软件需求规范的中文翻译。保留了所有需求 ID（SRS_Dio_xxxxx）、参考标识符及模块缩写。原始文档共 15 页，本翻译涵盖了全部章节内容。
IO/AUTOSAR_SRS_ICUDriver.md
+627
View File
@@ -0,0 +1,627 @@
# ICU 驱动需求（Requirements on ICU Driver）
> **AUTOSAR CP Release 4.4.0**
## 文档元信息
| 字段 | 内容 |
|---|---|
| **文档标题** | ICU 驱动需求（Requirements on ICU Driver） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 112 |
| **文档状态** | Final（最终版） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 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 | 编辑性变更 |
| 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 | 根据 TPS_standardization 模板更新；需求追踪的正式返工 |
| 2010-09-30 | 3.1.5 | 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 | 作为独立文档发布。SRS SPAL V1.0.0 已被拆分为 12 个独立文档，以发布 2.0；移除了功能：硬件门控边缘计数、信号电平通知；批准了功能需求：时间戳、唤醒、边沿计数、获取经过信号时间、获取占空比输入值；新增了功能需求：重置已计数的边沿值 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 作为 SRS SPAL V1.0.0 的一部分初始发布 |
---
## 目录（Table of Contents）
1. [文档范围（Scope of document）](#1-文档范围)
2. [如何阅读本文档（How to read this document）](#2-如何阅读本文档)
- 2.1 [使用的约定（Conventions used）](#21-使用的约定)
- 2.2 [需求结构（Requirements structure）](#22-需求结构)
3. [缩略语与缩写（Acronyms and abbreviations）](#3-缩略语与缩写)
4. [功能概述（Functional Overview）](#4-功能概述)
- 4.1 [ICU 驱动（ICU Driver）](#41-icu-驱动)
5. [需求追踪（Requirements Tracing）](#5-需求追踪)
6. [需求规范（Requirement Specification）](#6-需求规范)
- 6.1 [功能需求（Functional Requirements）](#61-功能需求)
- 6.1.1 [ICU 驱动](#611-icu-驱动)
- 6.1.1.1 [配置（Configuration）](#6111-配置)
- 6.1.1.2 [初始化（Initialization）](#6112-初始化)
- 6.1.1.3 [正常运行（Normal Operation）](#6113-正常运行)
- 6.1.1.4 [关闭操作（Shutdown Operation）](#6114-关闭操作)
7. [参考文献（References）](#7-参考文献)
- 7.1 [相关标准与规范（Related standards and norms）](#71-相关标准与规范)
---
## 1 文档范围（Scope of document）
本文档规定了 ICU 驱动模块的需求。
### 约束（Constraints）
基础软件模块需求规范的首要范围是非安全相关系统。因此，安全需求被分配到中等优先级。
---
## 2 如何阅读本文档（How to read this document）
每个需求都有其唯一的标识符，以 "BSW"（"Basic Software" 的缩写）前缀开头。对于任何审阅注释、评论或问题，请参考此唯一 ID 而不是章节或页码！
### 2.1 使用的约定（Conventions used）
- AUTOSAR 文档中需求的表示遵循 [5] 中指定的表。
- 在需求中，使用以下特定语义。
本文件中使用的关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照所示进行解释。请注意，它们所使用文档的需求级别会修改这些词的强制力。
- **MUST**：意味着该定义是规范的绝对要求。
- **MUST NOT**：意味着该定义是规范的绝对禁止。
- **SHOULD**：意味着在特定情况下可能存在忽略特定条目的有效理由。
- **SHOULD NOT**：意味着在特定情况下特定行为可能是可接受的甚至是有用的。
- **MAY**：意味着某个项目是真正可选的。
### 2.2 需求结构（Requirements structure）
每个模块特定章节包含基础软件模块的简短功能描述。同一类型的需求在每个章节内按以下标题分组（如果适用）：
**功能需求（Functional Requirements）：**
- 配置（Configuration）
- 初始化（Initialization）
- 正常运行（Normal Operation）
- 关闭操作（Shutdown Operation）
- 故障操作（Fault Operation）
**非功能需求（Non-Functional Requirements）：**
- 时间需求（Timing Requirements）
- 资源使用（Resource Usage）
- 可用性（Usability）
---
## 3 缩略语与缩写（Acronyms and abbreviations）
| 术语 | 描述 |
|---|---|
| Circular buffer（循环缓冲区） | 用于通过在到达末尾后从缓冲区开头再次开始来存储连续数据流的内存区域。 |
| DIO | 数字输入输出（Digital Input Output） |
| Duty Cycle（占空比） | 高电平时间与周期时间的百分比。<br>（高电平时间 / 周期时间）× 100% |
| ECU | 电控单元（Electric Control Unit） |
| High Time（高电平时间） | 参见图"ICU 时间定义"。应使用标准类型 STD_HIGH。 |
| ICU | 输入捕获单元（Input Capture Unit） |
| ICU channel（ICU 通道） | 表示绑定到一个输入信号和配置的测量模式硬件资源的逻辑 ICU 实体。 |
| Linear buffer（线性缓冲区） | 用于通过从缓冲区开头开始并在最迟到达末尾时停止来存储数据流的内存区域。 |
| Low Time（低电平时间） | 参见图"ICU 时间定义" |
| MAL | 微控制器抽象层的旧名称（已被 MCAL 取代，因为 'MAL' 在法语中意为 'bad'） |
| MCAL | 微控制器抽象层（Microcontroller Abstraction Layer） |
| MCU | 微控制器单元（Microcontroller Unit） |
| Measurement mode（测量模式） | 测量模式定义信号采集和评估的能力。可能的模式：<br>- 信号边沿检测/通知<br>- 信号测量<br>- 时间戳<br>- 边沿计数器 |
| Measurement mode, Edge counter | 边沿计数器的功能，对外部边沿进行计数 |
| Measurement mode, Signal Edge Detection | 信号边沿的通知 |
| Measurement mode, Signal Measurement | 测量输入信号的经过高电平时间、经过低电平时间、经过周期时间和占空比。 |
| Measurement mode, Timestamp | 为信号边沿生成时间戳，参见图"ICU 时间戳" |
| Period Time（周期时间） | 参见图"ICU 时间定义" |
| PWD | 脉冲宽度解调（Pulse width demodulation） |
| SPAL | 标准外设抽象层（Standard Peripheral Abstraction Layer） |
| 缩写 | 描述 |
|---|---|
| STD | 标准（Standard） |
| UNINIT | 未初始化（Uninitialized） |
由于这是面向专业人士的专业文档，其他所有术语均假定为已知。
---
## 4 功能概述（Functional Overview）
### 4.1 ICU 驱动（ICU Driver）
ICU 驱动控制微控制器的输入捕获单元。它提供以下功能：
- 周期、低、高时间测量
- 边沿检测和通知
- 边沿计数
- 边沿时间戳
- 唤醒中断
下图显示了捕获比较单元的典型关键资源：
```
Capture Timer 0
Notification Interrupts
f in x
Capture Timer 1
f in z
Capture Timer Notification Interrupts
Control
f in extern x
Capture Timer y
f in extern y
Notification Interrupts
Timer values
Signal 1 Capture Register 0
Notification Interrupts
Signal 2 Capture Register 1
Notification Interrupts
capture mode Capture Register 2
& edge Notification Interrupts
detection
control
Signal n Capture Register n
Notification Interrupts
```
对于信号边沿检测，使用捕获比较单元的边沿检测器或外部事件的中断控制器。
对于信号测量，需要捕获定时器和至少一个捕获寄存器。简单的信号边沿检测（不进行时间测量）也可以使用外部中断控制单元实现：
```
Signal m
level / edge Notification Interrupts
detection
&
Signal z interrupt
control Notification Interrupts
```
然而，不可屏蔽中断（NMI）不在本模块的范围内，因为没有可控制的内容。
```
High Time Low Time
Period Time
图：ICU 时间定义
```
```
0xFFFF
Timestamp
Timer
0
High
Input Signal
Low
t
Input Signal Timestamp
Level Timer
High 5461
Low 10922
High 22937
Low 32767
High 43690
Low 49151
High 58981
Low 6553
High 16383
```
**图 1：ICU 时间戳**
---
## 5 需求追踪（Requirements Tracing）
| 需求 | 描述 | 由...满足 |
|---|---|---|
| RS_BRF_01056 | AUTOSAR BSW 模块应提供标准化接口 | SRS_Icu_12429 |
| RS_BRF_01096 | AUTOSAR 应支持 ECU 的启动和关闭 | SRS_Icu_12407 |
| RS_BRF_01104 | AUTOSAR 应支持 ECU 和总线的睡眠和唤醒 | SRS_Icu_12408 |
| RS_BRF_01432 | AUTOSAR 服务应支持系统时间服务 | SRS_Icu_12430, SRS_Icu_12431, SRS_Icu_12434, SRS_Icu_12435, SRS_Icu_12436, SRS_Icu_12437, SRS_Icu_12442, SRS_Icu_12443, SRS_Icu_12444, SRS_Icu_12453, SRS_Icu_13100 |
| RS_BRF_01448 | AUTOSAR 服务应支持模式和状态管理 | SRS_Icu_12371 |
| RS_BRF_01488 | AUTOSAR RTE 和 BSW 应支持 ECU 启动、ECU 关闭（带重启）以及将 ECU 置于睡眠状态的标准化模式 | SRS_Icu_12370 |
| RS_BRF_01904 | AUTOSAR 微控制器抽象应提供对硬件定时器的访问 | SRS_Icu_12438 |
| RS_BRF_01968 | AUTOSAR IO 硬件抽象应支持边沿触发的 I/O 信号 | SRS_Icu_12369, SRS_Icu_12432, SRS_Icu_12433, SRS_Icu_12435, SRS_Icu_12436, SRS_Icu_12439, SRS_Icu_12442, SRS_Icu_12443 |
| RS_BRF_02200 | AUTOSAR 诊断应提供对内部配置和校准数据的外部访问 | SRS_Icu_12327, SRS_Icu_12368, SRS_Icu_12425 |
---
## 6 需求规范（Requirement Specification）
### 6.1 功能需求（Functional Requirements）
#### 6.1.1 ICU 驱动
##### 6.1.1.1 配置（Configuration）
**6.1.1.1.1 [SRS_Icu_12327] ICU 驱动应允许配置全局参数**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应允许配置以下参数：<br>- 时钟源及可选的预分频器（模块范围）<br>- MCU 硬件相关设置（仅 ICU 外设特定设置） |
| Rationale | 配置微控制器特定的 ICU 功能 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02200)
**6.1.1.1.2 [SRS_Icu_12368] ICU 驱动应支持每个通道的基本静态配置**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应支持每个通道的以下基本静态配置：<br><br>**强制参数：** <br>- 通道的符号名称<br>- 通知函数<br>- 唤醒能力<br><br>**可选参数：** <br>- 信号源（配置的端口引脚或来自信号矩阵的输入）如果由硬件提供（如果可以选择多个源）<br>- 测量模式（如果可以选择多个模式）：<br> - 信号边沿检测/通知<br> - 信号测量<br> - 时间戳<br> - 边沿计数器<br><br>- 如果测量模式是"时间戳测量"，则缓冲区处理应可配置。值应为：<br> - 循环缓冲区处理<br> - 线性缓冲区处理<br><br>- 已分配的捕获寄存器（对于仅提供边沿检测（如外部中断）的通道也可以没有）<br>- 已分配的捕获定时器（对于仅提供边沿检测（如外部中断）的通道也可以没有）<br>- 其他硬件相关设置（例如毛刺滤波器、预分频器） |
| Rationale | 允许每个通道的不同用法 |
| Use Case | |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02200)
**6.1.1.1.3 [SRS_Icu_12425] 对于每个 ICU 通道，可测量的"属性"应可配置**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 对于每个 ICU 通道，可测量的"属性"应可配置，可用值（至少）为：<br>- 高电平<br>- 低电平<br>- 周期时间 |
| Rationale | 定义测量目的以在配置期间分配所需的硬件资源。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02200)
##### 6.1.1.2 初始化（Initialization）
**6.1.1.2.1 [SRS_Icu_12407] 在 ICU 驱动初始化后，所有通知都应被禁用**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 在 ICU 驱动初始化后，所有通知都应被禁用。所有 ICU 通道状态应设置为 INACTIVE。<br>通道的唤醒能力在初始化后应被禁用。<br>所有使用的寄存器都应初始化（包括中断的待处理标志）。 |
| Rationale | ICU 通道的用户应负责启用/禁用通知。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | |
⌋(RS_BRF_01096)
**6.1.1.2.2 [SRS_Icu_12429] ICU 驱动应提供将 ICU 通道反初始化为其上电复位状态的功能**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供将 ICU 通道反初始化为其上电复位状态的功能（不包括不可写的寄存器）。 |
| Rationale | 在可以进行有效初始化之前，有必要将所有硬件寄存器重置为相同的状态。否则上电复位后的初始化代码与模式更改后的初始化代码不同。 |
| Use Case | 在更改省电模式的内部时钟频率后，可能有必要使用有效的预分频器值初始化定时器模块。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01056)
##### 6.1.1.3 正常运行（Normal Operation）
**6.1.1.3.1 [SRS_Icu_12305] ICU 驱动应允许在运行时启用/禁用 ICU 通道的通知**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应允许在运行时启用/禁用 ICU 通道的通知。<br>对于每个选定通道，应提供以下选项：<br>- 禁用通知<br>- 在以下边沿启用通知（如果硬件支持）：<br> - 上升沿<br> - 下降沿<br> - 两个边沿 |
| Rationale | 根据下一个预期边沿调整通知。 |
| Use Case | 霍尔传感器的边沿检测。<br>禁用通知可用于实现抗饱和机制，以避免在 ICU 中出现过多中断时危胁整个系统。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
**6.1.1.3.2 [SRS_Icu_12369] ICU 驱动应在配置的信号边沿为 ICU 通道提供通知**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应在配置的信号边沿（上升/下降/两个边沿）为 ICU 通道提供通知，在以下配置中：<br>- 通知函数配置为非空指针<br>- 并且仅当通知被启用时 |
| Rationale | 信号边沿通知 |
| Use Case | 信号边沿检测 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01968)
**6.1.1.3.3 [SRS_Icu_12370] ICU 驱动应提供选择睡眠模式的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供选择睡眠模式的服务：<br>- 正常模式（强制）<br>- 睡眠模式<br><br>在正常模式下，所有通知均按配置可用。<br>在睡眠模式下，仅那些引起唤醒可用通知的中断可用。<br>所有其他中断被禁用，如果事件发生，必须不会导致退出 MCU 的降低功耗模式状态（例如 idle、halt）。 |
| Rationale | 允许启用/禁用 ECU 唤醒所需的所有中断。 |
| Use Case | 在进入 ECU 的降低功耗模式时，必须禁用 MCU 的所有中断，而不是在期间禁用唤醒源。否则可能丢失唤醒事件。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01488)
**6.1.1.3.4 [SRS_Icu_12371] ICU 驱动应提供返回 ICU 输入状态的同步服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供返回 ICU 输入状态的同步服务。<br>- 如果已检测到激活边沿，则此服务将返回 ACTIVE。一旦服务返回状态 ACTIVE，状态将被设置为 IDLE，直到检测到下一个边沿<br>- 如果未检测到激活边沿，则此服务将返回 IDLE |
| Rationale | 通知禁用时对输入的轮询访问 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01448)
**6.1.1.3.5 [SRS_Icu_12438] ICU 驱动应提供在可配置边沿捕获定时器值到外部缓冲区的功能**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供在可配置边沿（上升沿/下降沿/两个边沿）捕获定时器值到外部缓冲区的功能。<br>此功能应对测量模式为"Timestamp"的每个 ICU 通道可用。 |
| Rationale | -- |
| Use Case | 采集高频和非周期性传感器信号 |
| Dependencies | -- |
| Supporting Material | 参见图 1：ICU 时间戳 |
⌋(RS_BRF_01904)
**6.1.1.3.6 [SRS_Icu_12455] 如果配置了循环缓冲区处理，则在到达缓冲区末尾时，驱动应从外部缓冲区开头重新开始**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 如果配置了循环缓冲区处理，则当捕获功能到达缓冲区末尾时，驱动从外部缓冲区开头重新开始。<br>此功能应对测量模式为"Timestamp"的每个 ICU 通道可用。 |
| Rationale | -- |
| Use Case | 高频连续数据采集 |
| Dependencies | -- |
| Supporting Material | 参见图 1：ICU 时间戳 |
⌋()
**6.1.1.3.7 [SRS_Icu_12456] 如果配置了线性缓冲区处理，则在到达缓冲区末尾时，驱动应停止捕获定时器值**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 如果配置了线性缓冲区处理，则当捕获功能到达缓冲区末尾时，驱动停止捕获定时器值。<br>此功能应对测量模式为"Timestamp"的每个 ICU 通道可用。 |
| Rationale | -- |
| Use Case | 高频非连续数据采集 |
| Dependencies | -- |
| Supporting Material | 参见图 1：ICU 时间戳 |
⌋()
**6.1.1.3.8 [SRS_Icu_12430] ICU 驱动应提供在 ICU 通道上启动时间戳测量的异步服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供在 ICU 通道上启动时间戳测量的异步服务。传递的参数应为：<br>- ICU 通道<br>- 指向数据缓冲区的指针（时间戳和信号电平的目标）<br>- 数据缓冲区大小<br>- 通知间隔（事件）<br><br>此功能应对测量模式为"Timestamp"的每个 ICU 通道可用。 |
| Rationale | 配置和启用时间戳捕获 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01432)
**6.1.1.3.9 [SRS_Icu_12431] ICU 驱动应提供取消 ICU 通道上时间戳测量的同步服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供取消 ICU 通道上时间戳测量的同步服务。传递的参数应为：<br>- ICU 通道<br><br>此功能应对测量模式为"Timestamp"的每个 ICU 通道可用。 |
| Rationale | 禁用时间戳捕获 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01432)
**6.1.1.3.10 [SRS_Icu_12444] ICU 驱动应在已采集到所请求时间戳数量时提供通知**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应在已采集到所请求时间戳数量（通知间隔）时提供通知。<br>此功能应对测量模式为"Timestamp"的每个 ICU 通道可用。 |
| Rationale | 支持时间戳测量期间的通知汇总 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01432)
**6.1.1.3.11 [SRS_Icu_12453] ICU 应提供时间戳索引服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供读取驱动的当前时间戳索引的同步服务。传递的参数应为：<br>- ICU 通道<br><br>此功能应对测量模式为"Timestamp"的每个 ICU 通道可用。 |
| Rationale | 读取缓冲区内的当前时间戳索引 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01432)
**6.1.1.3.12 [SRS_Icu_12439] ICU 应计算信号的边沿**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供计算信号边沿的功能。<br>仅对配置的边沿进行计数（上升沿/下降沿/两个边沿）。<br>此功能应对测量模式为"Edge Counter"的每个 ICU 通道可用。 |
| Rationale | -- |
| Use Case | 计数高频事件。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01968)
**6.1.1.3.13 [SRS_Icu_12432] 边沿计数服务应在 ICU 通道上可用**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供在 ICU 通道上启用边沿计数的同步服务。传递的参数应为：<br>- ICU 通道<br><br>此功能应对测量模式为"Edge Counter"的每个 ICU 通道可用。 |
| Rationale | 基本功能。 |
| Use Case | 在定义的时间跨度内对边沿进行计数。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01968)
**6.1.1.3.14 [SRS_Icu_13100] 应能重置 ICU 通道已计数的边沿值**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供重置 ICU 通道已计数的边沿的同步服务。传递的参数应为：<br>- ICU 通道<br><br>此功能应对测量模式为"Edge Counter"的每个 ICU 通道可用。 |
| Rationale | 将计数的开始与已计数的边沿的重置分开。 |
| Use Case | 电动座椅定位的脉冲计数（如果座椅停止然后再次移动，应保留位置（等同于计数的边沿））。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01432)
**6.1.1.3.15 [SRS_Icu_12433] ICU 通道上的边沿计数服务应被禁用**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供禁用 ICU 通道上边沿计数的同步服务。传递的参数应为：<br>- ICU 通道<br><br>此功能应对测量模式为"Edge Counter"的每个 ICU 通道可用。 |
| Rationale | 基本功能。 |
| Use Case | 在定义的时间跨度内对边沿进行计数。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01968)
**6.1.1.3.16 [SRS_Icu_12434] 应提供边沿计数读取服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供读取最后一次调用"启用 ICU 边沿计数服务"后已计数的边沿数的同步服务。传递的参数应为：<br>- ICU 通道<br><br>此功能应对测量模式为"Edge Counter"的每个 ICU 通道可用。 |
| Rationale | 在最后一次调用后读取已计数的边沿数 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01432)
**6.1.1.3.17 [SRS_Icu_12442] 应为每个 ICU 通道提供经过的信号低电平时间**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供服务以获取每个配置为测量模式"Signal Measurement, Signal Low Time"的 ICU 通道的经过信号低电平时间。<br>经过时间在下降沿和通道的连续上升沿之间测量。 |
| Rationale | 获取经过的信号低电平时间 |
| Use Case | PWD |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01432, RS_BRF_01968)
**6.1.1.3.18 [SRS_Icu_12435] 应为每个 ICU 通道提供经过的信号高电平时间**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供服务以获取每个配置为测量模式"Signal Measurement, Signal High Time"的 ICU 通道的信号高电平时间。<br>经过时间在上升沿和通道的连续下降沿之间测量。 |
| Rationale | -- |
| Use Case | PWD |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01432, RS_BRF_01968)
**6.1.1.3.19 [SRS_Icu_12443] 应为 ICU 通道提供经过的周期时间**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供服务以获取每个配置为测量模式"Signal Measurement, Period Time"的 ICU 通道的经过周期时间。<br>经过时间在通道的两个连续上升（或下降）沿之间测量。 |
| Rationale | -- |
| Use Case | PWD |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01432, RS_BRF_01968)
**6.1.1.3.20 [SRS_Icu_12436] 应提供 ICU 通道的高电平时间和周期时间**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供服务以获取每个配置为测量模式"Signal Measurement, Duty Cycle"的 ICU 通道的一致的高电平时间和周期时间。 |
| Rationale | 基本功能，服务提供用于占空比计算的值。正确的计算和缩放由 ICU 模块的用户完成。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01432, RS_BRF_01968)
**6.1.1.3.21 [SRS_Icu_12437] ICU 驱动的 API 服务内使用的所有时间单位应为 ticks 单位**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动的 API 服务内使用的所有时间单位应为 ticks 单位。 |
| Rationale | 微秒与 ticks 之间的转换应为 ECU 抽象层的一部分。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01432)
##### 6.1.1.4 关闭操作（Shutdown Operation）
**6.1.1.4.1 [SRS_Icu_12408] ICU 驱动应提供启用/禁用单个 ICU 通道唤醒能力的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | ICU 驱动应提供启用/禁用单个 ICU 通道唤醒能力的服务。 |
| Rationale | 控制 MCU 的唤醒条件需要启用或禁用硬件中断，而不仅仅是某些通知条件。 |
| Use Case | 在错误情况下限制唤醒发生。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01104)
### 对其他功能的约束（Constrains to other functions）
**对模式管理的约束（Constrains to Mode Management）：**
在唤醒条件之后，ECU 状态管理器应在调用 ICU 驱动的初始化服务之前处理唤醒信息。
---
## 7 参考文献（References）
- **[1]** 词汇表，AUTOSAR_TR_Glossary.pdf
- **[2]** 分层软件架构，AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
- **[3]** 基础软件的一般需求，AUTOSAR_SRS_BSWGeneral.pdf
- **[4]** SPAL 的一般需求，AUTOSAR_SRS_SPALGeneral.pdf
- **[5]** 软件标准化模板，AUTOSAR_TPS_StandardizationTemplate.pdf
### 7.1 相关标准与规范（Related standards and norms）
---
## 翻译说明
本文档为 AUTOSAR 4.4.0 版本 ICU 驱动软件需求规范的中文翻译。保留了所有需求 ID（SRS_Icu_xxxxx）、参考标识符及模块缩写。原始文档共 25 页，本翻译涵盖了全部章节内容。ICU 驱动提供周期、低、高时间测量、边沿检测/通知、边沿计数、边沿时间戳和唤醒中断等关键功能。
IO/AUTOSAR_SRS_IOHWAbstraction.md
+667
View File
@@ -0,0 +1,667 @@
# I/O 硬件抽象需求（Requirements on I/O Hardware Abstraction）
> **AUTOSAR CP Release 4.4.0**
## 文档元信息
| 字段 | 内容 |
|---|---|
| **文档标题** | I/O 硬件抽象需求（Requirements on I/O Hardware Abstraction） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 075 |
| **文档状态** | Final（最终版） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 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 | 新增需求追踪章节 |
| 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 | 需求追踪的正式返工；新增三个电源状态转换；纳入 ECU 降级需求；根据 TPS_standardization 模板更新 |
| 2010-09-30 | 3.1.5 | 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 | 初始发布 |
---
## 目录（Table of Contents）
1. [文档范围（Scope of this document）](#1-文档范围)
2. [如何阅读本文档（How to read this document）](#2-如何阅读本文档)
- 2.1 [使用的约定（Conventions used）](#21-使用的约定)
- 2.2 [需求结构（Requirement structure）](#22-需求结构)
3. [缩略语与缩写（Acronyms and abbreviations）](#3-缩略语与缩写)
- 3.1 [表达式 - 通用（Expressions - general）](#31-表达式---通用)
- 3.2 [表达式 - 信号属性（Expressions - signal attributes）](#32-表达式---信号属性)
4. [功能概述（Functional Overview）](#4-功能概述)
- 4.1 [IO 硬件抽象（IO Hardware Abstraction）](#41-io-硬件抽象)
- 4.2 [信号属性概述（Overview of Attributes to qualify Signals）](#42-信号属性概述)
5. [需求追踪（Requirements Tracing）](#5-需求追踪)
6. [需求规范（Requirement Specification）](#6-需求规范)
- 6.1 [功能需求（Functional Requirements）](#61-功能需求)
- 6.1.1 [IO 硬件抽象](#611-io-硬件抽象)
- 6.2 [非功能需求（质量）（Non-Functional Requirements (Qualities)）](#62-非功能需求质量)
7. [参考文献（References）](#7-参考文献)
- 7.1 [AUTOSAR 交付物（Deliverables of AUTOSAR）](#71-autosar-交付物)
---
## 1 文档范围（Scope of this document）
本文档定义了 AUTOSAR 内需求规范的一般规则和格式。它应作为每个需求文档的基础。
需求按以下方式组织：
- 基础软件模块的一般需求（其他文档）
- 适用于微控制器抽象层和 ECU 抽象层所有模块的一般需求（本文档）
- 模块特定需求（本文档）
### 约束（Constraints）
基础软件模块需求规范的首要范围是非安全相关系统。因此，安全需求被分配到中等优先级。
---
## 2 如何阅读本文档（How to read this document）
每个需求都有其唯一的标识符，以 "BSW"（"Basic Software" 的缩写）前缀开头。对于任何审阅注释、评论或问题，请参考此唯一 ID 而不是章节或页码！
### 2.1 使用的约定（Conventions used）
- AUTOSAR 文档中需求的表示遵循 [2] 中指定的表。
- 在需求中，应使用以下特定语义（基于互联网工程任务组 IETF）。
本文件中使用的关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应解释为：
- **SHALL**：这个词意味着该定义是规范的绝对要求。
- **SHALL NOT**：这个词组意味着该定义是规范的绝对禁止。
- **MUST**：这个词意味着该定义是规范的绝对要求（出于法律问题）。
- **MUST NOT**：这个词组意味着该定义是规范的绝对禁止（出于法律约束）。
- **SHOULD**：意味着在特定情况下可能存在忽略特定条目的有效理由。
- **SHOULD NOT**：意味着在特定情况下特定行为可能是可接受的甚至是有用的。
- **MAY**：意味着某个项目是真正可选的。
### 2.2 需求结构（Requirement structure）
每个模块特定章节包含基础软件模块的简短功能描述。同一类型的需求在每个章节内按以下标题分组（如果适用）：
**功能需求（Functional Requirements）：**
- 配置（Configuration）
- 初始化（Initialization）
- 正常运行（Normal Operation）
- 关闭操作（Shutdown Operation）
- 故障操作（Fault Operation）
**非功能需求（Non-Functional Requirements）：**
- 时间需求（Timing Requirements）
- 资源使用（Resource Usage）
- 可用性（Usability）
---
## 3 缩略语与缩写（Acronyms and abbreviations）
### 3.1 表达式 - 通用（Expressions - general）
| 表达式 | 描述 | 示例 |
|---|---|---|
| Class（类） | 表示 ECU 的一种电气连接。例如模拟、离散等。 | Analogue Class、Discrete Class 等。 |
| Electrical Signal（电气信号） | ECU 引脚上的电气信号 | ECU 引脚上的物理输入电压 |
| ECU pin（ECU 引脚） | ECU 与电子系统其余部分的硬件电气连接 | |
| ECU Signals（ECU 信号） | 电气信号的软件表示。信号具有属性和符号名称 | 输入电压、离散输出、PWM 输入等。 |
| ECU Signal group（ECU 信号组） | 来自同一 Class 的电气信号组的软件表示 | 仅用于离散输入和离散输出 |
| Attributes（属性） | ECU 中存在的每种信号的软件（SW）和硬件（HW）特性 | 范围、生命周期/延迟等。 |
| Symbolic name（符号名称） | 信号的符号名称由 IO 硬件抽象模块用于建立链接（功能、引脚） | |
### 3.2 表达式 - 信号属性（Expressions - signal attributes）
| 表达式 | 描述 | 示例 |
|---|---|---|
| Data Type（数据类型） | 信号的数据类型：<br>- Analogue：VoltageType、CurrentType、ResistanceType<br>- Discrete：bool 或 AUTOSAR 定义的类型（BoolType） | 每种数据类型具有给定大小：16 位或 32 位 |
| Range（范围） | 功能范围而非电气范围。<br>- 对于模拟信号 [lowerLimit...upperLimit]（电压、电流），[0...upperLimit]（电阻）<br>- 对于离散信号 [0,1]<br>- 对于时序信号 [0…upperLimit]（周期），[-100…100%]（占空比） | [-12Volts...+12Volts]（电压） |
| Resolution（分辨率） | 该属性对于许多 Class 取决于范围和数据类型。<br>示例：(upperLimit - lowerLimit) / 数据类型长度 | VoltageType => 16 位；分辨率 => 24 / 65535 |
| Hardware Resolution（硬件分辨率） | 这是硬件（ADC）的最大可能分辨率 | ADC 转换器可以具有 8/10/12/16 位分辨率 |
| Hardware Accuracy（硬件精度） | 这是硬件的精度，取决于用于采集和/或生成的硬件外设 | ADC 转换器可以具有 ±3 LSB 的精度 |
| Accuracy（精度） | 取决于用于采集和/或生成的硬件外设 | ADC 转换器可以是 8/10/12/16 位转换器 |
| Diagnosis（诊断） | 功能诊断能力 | 不支持诊断（可以是静态检查）；无可用有效信息；对电源短路；对地短路；开路；过热；诊断正常 |
| Synchronization（同步） | 信号可以与另一个信号或事件（如触发器）同步 | 如果离散信号为"TRUE"，则获取模拟信号 |
| Access（访问） | 定义信号是否附加到 Get（读）/ Set（写）功能 | |
| Inversion（反相） | 物理值和逻辑值之间的反相。此属性对 IO 硬件抽象的用户不可见且不可配置。 | 物理高状态 →（信号=False）；物理低状态 →（信号=True） |
| Lifetime（生命周期） | 仅适用于输入：这是数据允许的最大年龄（时间以微秒为单位）。如果生命周期为 0，则信号直接从寄存器获取。 | 生命周期 = 0 是直接访问；生命周期 = 1000µs 时读取的值最多比实际值旧 1ms |
| Delay（延迟） | 仅适用于输出：这是输出实际设置之前允许的最大时间（时间以微秒为单位）。如果延迟为 0，则立即设置信号。 | 延迟 = 0 是直接访问；延迟 = 100µs 命令设置直到 100µs 过去 |
| Filtering / Debouncing（滤波/去抖） | 定义信号是作为原始值提供，还是 IO 硬件抽象模块中为此信号包含滤波/去抖方法 | Raw、Debounce 3 Samples、Wait 10ms |
| Sampling Rate（采样率） | 获取信号值所需的时间段 | 采样窗口（突发）的采样率 |
| Report Changes（更改报告） | 此属性仅适用于离散输入。它定义报告电平更改的能力（或不报告）。 | 启用或禁用 |
| Pulse Test（脉冲测试） | 此属性意味着输出应通过专用脉冲进行测试。如果未设置此属性，则在使用输出时进行诊断。 | 可用或不可用 |
---
## 4 功能概述（Functional Overview）
### 4.1 IO 硬件抽象（IO Hardware Abstraction）
IO 硬件抽象模块抽象自 ECU 硬件的信号路径（布局、微控制器引脚、微控制器外部设备如 IO ASIC）。它向上层软件层提供基于信号的接口。它根据 ECU 硬件输入/输出的物理表示执行静态抽象和反相（如果需要）（补偿在 ECU IO 和微控制器引脚之间的路径中引起的静态影响，例如分压器、硬件反相）。
IO 硬件抽象模块允许根据属性列表配置每个信号。接口是 AUTOSAR 标准。
### 4.2 信号属性概述（Overview of Attributes to qualify Signals）
下表总结了不同类型 ECU 信号类（Analoguein、Analogueout、Discretein、DiscreteStatus、Discretepow、PWx Periodin/out、PWx Duty Cyclein/out）所适用的属性。表中列出了 BSW-Resolution、Age (Lifetime/Delay)、Report Feature、Sampling Rate、Debouncing、Monitoring、Filtering/Pulse Test、Access、Failure Age、Signal Data Type、Unit、Signal 等属性。
**表图例：**
- **X** 表示该属性适用于此类 ECU 信号并且应被配置。
- Xl 表示适用的年龄属性是生命周期（Lifetime）。
- Xd 表示适用的年龄属性是延迟（Delay）。
- **F** 表示该属性适用于此类 ECU 信号但是固定的标准值。
- **O** 表示该属性对于此类 ECU 信号是可选的，取决于静态配置（禁用/启用）。
- **-** 表示该属性不适用或对此类 ECU 信号无意义。
---
## 5 需求追踪（Requirements Tracing）
| 需求 | 描述 | 由...满足 |
|---|---|---|
| RS_BRF_01000 | AUTOSAR 架构应将 BSW 组织为硬件独立层和硬件依赖层 | SRS_IoHwAb_12319 |
| RS_BRF_01024 | AUTOSAR 应提供公共符号的命名规则 | SRS_IoHwAb_12232 |
| RS_BRF_01048 | AUTOSAR 模块设计应支持模块在多任务环境中协作 | SRS_IoHwAb_12449 |
| RS_BRF_01056 | AUTOSAR BSW 模块应提供标准化接口 | SRS_IoHwAb_12452 |
| RS_BRF_01080 | AUTOSAR 应允许访问内部和外部外围设备 | SRS_IoHwAb_12242 |
| RS_BRF_01184 | AUTOSAR 应支持不同的降级方法 | SRS_IoHwAb_12453, SRS_IoHwAb_12454, SRS_IoHwAb_12455 |
| RS_BRF_01352 | AUTOSAR RTE 应提供直接读/写数据访问，或者替代地在可运行对象调用之前预读数据并在可运行对象返回后后写数据 | SRS_IoHwAb_00002, SRS_IoHwAb_12324, SRS_IoHwAb_12338, SRS_IoHwAb_12410, SRS_IoHwAb_12411, SRS_IoHwAb_12412, SRS_IoHwAb_12413, SRS_IoHwAb_12415 |
| RS_BRF_01384 | AUTOSAR RTE 应支持数据的自动范围检查 | SRS_IoHwAb_12409 |
| RS_BRF_01632 | AUTOSAR 通信应支持信号组的数据一致性 | SRS_IoHwAb_12323 |
| RS_BRF_01856 | AUTOSAR 微控制器抽象应提供对内部 MCU 配置的访问 | SRS_IoHwAb_12338 |
| RS_BRF_01952 | AUTOSAR IO 硬件抽象应支持已连接 I/O 设备的标准化模式 | SRS_IoHwAb_12453, SRS_IoHwAb_12454, SRS_IoHwAb_12455 |
| RS_BRF_01968 | AUTOSAR IO 硬件抽象应支持边沿触发的 I/O 信号 | SRS_IoHwAb_12414, SRS_IoHwAb_12416, SRS_IoHwAb_12417, SRS_IoHwAb_12445 |
| RS_BRF_02000 | AUTOSAR IO 硬件抽象应保护硬件免受非法操作 | SRS_IoHwAb_12419, SRS_IoHwAb_13900, SRS_IoHwAb_13901, SRS_IoHwAb_13902 |
| RS_BRF_02016 | AUTOSAR 应提供保护系统免受未授权修改的机制 | SRS_IoHwAb_12451 |
| RS_BRF_02024 | AUTOSAR 应提供保护系统免受未授权使用的机制 | SRS_IoHwAb_12248 |
| RS_BRF_02144 | AUTOSAR 诊断应为外部测试人员提供标准化诊断服务 | SRS_IoHwAb_00002 |
| RS_BRF_02160 | AUTOSAR 诊断应允许外部测试人员控制 ECU 的主动功能 | SRS_IoHwAb_12418 |
| RS_BRF_02168 | AUTOSAR 诊断应提供对异常操作条件的集中分类和处理 | SRS_IoHwAb_12339, SRS_IoHwAb_13900, SRS_IoHwAb_13901, SRS_IoHwAb_13902, SRS_IoHwAb_13904 |
| RS_BRF_02176 | AUTOSAR 错误处理应区分已定义异常操作条件和预期行为的意外异常 | SRS_IoHwAb_13903 |
| RS_BRF_02224 | AUTOSAR 应支持运行时硬件测试 | SRS_IoHwAb_12452 |
| RS_BRF_02272 | AUTOSAR 应提供应用软件行为的追踪 | SRS_IoHwAb_12450 |
---
## 6 需求规范（Requirement Specification）
### 6.1 功能需求（Functional Requirements）
#### 6.1.1 IO 硬件抽象
##### 6.1.1.1 通用（General）
**6.1.1.1.1 [SRS_IoHwAb_12409] IO 硬件抽象模块应为每个信号提供一个静态范围内的值**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块应为每个信号提供一个静态范围内的值。此范围独立于基础软件驱动缩放因子。<br>示例：<br>- 模拟信号 => [lowerLimit...upperLimit]，其中 (lowerLimit = -upperLimit) 或 (lowerLimit = 0) |
| Rationale | 支持具有高分辨率的宽范围 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01384)
**6.1.1.1.2 [SRS_IoHwAb_12410] IO 硬件抽象模块应提供读取具有特定属性的输入电压的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块应提供读取输入电压的服务，具有以下属性：<br>- 数据类型：VoltageType<br>- 范围：[lowerLimit...upperLimit]，lowerLimit 和 upperLimit 可以为负（[-5Volts, -3Volts]）<br>- 分辨率：VoltageType / (upperLimit - lowerLimit)<br>- 精度：HW 提供<br>- 同步：是/否<br>- 生命周期：x = 延迟 x 微秒<br>- 滤波/去抖：原始、滤波（带宽、截止频率）<br>- 采样率：x：每 x µs 采样一次 |
| Rationale | IO 硬件抽象的基本功能 |
| Use Case | 控制响应电压的组件/传感器 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01352)
**6.1.1.1.3 [SRS_IoHwAb_12411] IO 硬件抽象模块应提供读取具有特定属性的输出电压的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块应提供控制输出电压的服务，具有以下属性：<br>- 数据类型：VoltageType<br>- 范围：[lowerLimit...upperLimit]，lowerLimit 可以为负<br>- 分辨率：VoltageType / (upperLimit - lowerLimit)<br>- 精度：HW 提供<br>- 诊断：IO 硬件抽象模块能够检测以下故障：<br> - 不支持诊断（可以是静态检查）<br> - 无可用有效信息<br> - 对电源短路<br> - 对地短路<br> - 开路<br> - 过热<br> - 诊断正常<br>- 同步：是/否<br>- 延迟：x = 延迟 x 微秒 |
| Rationale | 基本功能 |
| Use Case | ECU 电源；通过使用 PWM 抽象生成模拟信号 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01352)
**6.1.1.1.4 [SRS_IoHwAb_12413] IO 硬件抽象模块应提供读取具有特定属性的输入电流的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块应提供读取输入电流的服务，具有以下属性：<br>- 数据类型：CurrentType<br>- 范围：[lowerLimit…upperLimit]，lowerLimit 可以为负<br>- 分辨率：CurrentType / (upperLimit - lowerLimit)<br>- 精度：HW 提供<br>- 同步：是/否<br>- 生命周期：x = 延迟 x 微秒<br>- 滤波/去抖：原始、滤波（带宽、截止频率）<br>- 采样率：x：每 x µs 采样一次 |
| Rationale | IO 硬件抽象的基本功能 |
| Use Case | 控制由电流驱动的组件/传感器 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01352)
**6.1.1.1.5 [SRS_IoHwAb_12415] IO 硬件抽象模块应提供使用特定属性测量连接电阻的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块应提供使用以下属性测量连接电阻的服务：<br>- 数据类型：ResistanceType<br>- 范围：[lowerLimit…upperLimit]，lowerLimit 为空或为正<br>- 分辨率：ResistanceType / (upperLimit - lowerLimit)<br>- 精度：HW 提供<br>- 同步：是/否<br>- 生命周期：x = 延迟 x 微秒<br>- 滤波/去抖：原始、滤波（带宽、截止频率）<br>- 采样率：x：每 x µs 采样一次 |
| Rationale | IO 硬件抽象的基本功能 |
| Use Case | 温度传感器的测量 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01352)
**6.1.1.1.6 [SRS_IoHwAb_12412] IO 硬件抽象模块应提供获取/读取具有特定属性的离散输入的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块应提供获取/读取离散输入的服务，具有以下属性：<br>- 数据类型：boolean<br>- 范围：0 或 1<br>- 分辨率：逻辑状态<br>- 精度：1 位<br>- 同步：是/否<br>- 生命周期：x = 延迟 x 微秒<br>- 滤波/去抖：原始、滤波（带宽、截止频率）<br>- 采样率：x：每 x µs 采样一次<br>- 更改报告：启用或禁用 |
| Rationale | IO 硬件抽象的基本功能 |
| Use Case | 从 ECU 引脚获取/读取逻辑值（0/1） |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01352)
**6.1.1.1.7 [SRS_IoHwAb_12324] IO 硬件抽象模块应提供同时获取/读取多个离散输入的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | AUTOSAR IO 硬件抽象模块应提供同时获取/读取多个离散输入的服务。输入的数量应可配置。这限制为物理端口。 |
| Rationale | 所有输入属于同一功能或同一增强型板上芯片。 |
| Use Case | 用于电机控制以及运行时优化 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01352)
**6.1.1.1.8 [SRS_IoHwAb_12450] IO 硬件抽象模块应提供在离散输入更改时向信号客户端报告的机制**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块应提供在离散输入更改时向信号客户端报告的机制。仅在为此信号启用更改报告属性时才可用此功能。 |
| Rationale | 确保实时行为 |
| Use Case | 检测传感器活动并及时做出反应，例如关于刮水器和制动踏板 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02272)
**6.1.1.1.9 [SRS_IoHwAb_12419] IO 硬件抽象模块应提供监控硬件故障并设置状态的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块应提供监控硬件故障并设置状态的服务：<br>- 数据类型：StatusType<br>- 范围：<br> - 无可用有效信息<br> - 对电源短路<br> - 对地短路<br> - 开路<br> - 过热<br> - 诊断正常<br>- 同步：是/否<br>- 生命周期：x = 延迟 x 微秒<br>- 滤波/去抖：原始、滤波（带宽、截止频率） |
| Rationale | 基本功能 |
| Use Case | 了解继电器/灯输出的实际状态 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02000)
**6.1.1.1.10 [SRS_IoHwAb_12418] IO 硬件抽象模块应提供控制具有特定属性的离散供电输出的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块应提供控制离散供电输出的服务，具有以下属性：<br>- 数据类型：boolean<br>- 范围：0 或 1<br>- 分辨率：逻辑状态<br>- 精度：1 位<br>- 诊断：IO 硬件抽象模块能够检测以下故障：<br> - 不支持诊断（可以是静态检查）<br> - 无可用有效信息<br> - 对电源短路<br> - 对地短路<br> - 开路<br> - 过热<br> - 诊断正常<br>- 同步：是/否<br>- 延迟：x = 延迟 x 微秒<br><br>简单输出（无电源）是电源输出的子集，其诊断属性始终为"不支持诊断（可以是静态检查）" |
| Rationale | 基本功能 |
| Use Case | 继电器控制、灯控制 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02160)
**6.1.1.1.11 [SRS_IoHwAb_12323] IO 硬件抽象模块应提供同时更新多个离散输出的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | AUTOSAR IO 硬件抽象模块应提供同时更新多个离散输出的服务。输出的数量应可配置。这限制为物理端口。 |
| Rationale | 所有输出属于同一功能或同一增强型板上芯片。 |
| Use Case | 用于同步和运行时优化 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01632)
**6.1.1.1.12 [SRS_IoHwAb_12417] IO 硬件抽象模块应提供测量信号上两个下降沿或上升沿之间周期时间的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块应提供使用以下属性测量信号上两个下降沿或上升沿之间周期时间的服务：<br>- 数据类型：PeriodType<br>- 范围：[lowerLimit…upperLimit]，lowerLimit 为空或为正<br>- 分辨率：PeriodType / (upperLimit - lowerLimit)<br>- 精度：HW 提供<br>- 生命周期：x = 延迟 x 微秒 |
| Rationale | IO 硬件抽象的基本功能 |
| Use Case | 测量 PWM 传感器的周期 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01968)
**6.1.1.1.13 [SRS_IoHwAb_12416] IO 硬件抽象模块应提供使用特定属性控制信号上两个下降沿或上升沿之间周期时间的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块应提供使用以下属性控制信号上两个下降沿或上升沿之间周期时间的服务：<br>- 数据类型：PeriodType<br>- 范围：[lowerLimit…upperLimit]，lowerLimit 为空或为正<br>- 分辨率：PeriodType / (upperLimit - lowerLimit)<br>- 精度：HW 提供<br>- 诊断：<br> - 不支持诊断（可以是静态检查）<br> - 无可用有效信息<br> - 对电源短路<br> - 对地短路<br> - 开路<br> - 过热<br> - 诊断正常<br>- 同步：是/否<br>- 延迟：x = 延迟 x 微秒 |
| Rationale | IO 硬件抽象的基本功能 |
| Use Case | 控制 PWM 输出信号的周期 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01968)
**6.1.1.1.14 [SRS_IoHwAb_12414] IO 硬件抽象模块应提供控制周期性输出信号的有效电平与非有效电平之间比率的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块应提供使用以下属性控制周期性输出信号的有效电平与非有效电平之间比率的服务：<br>- 数据类型：DutyCycleType<br>- 范围：[-100%…+100%]<br>- 分辨率：待定义<br>- 精度：HW 提供<br>- 同步：是/否<br>- 延迟：x = 延迟 x 微秒 |
| Rationale | IO 硬件抽象的基本功能 |
| Use Case | 负范围是有道理的，例如允许在硬件级别上进行电机方向控制（负占空比 = 向左，正占空比 = 向右） |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01968)
**6.1.1.1.15 [SRS_IoHwAb_12445] IO 硬件抽象模块应提供测量周期性输入信号的有效电平与非有效电平之间比率的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块应提供使用以下属性测量周期性输入信号的有效电平与非有效电平之间比率的服务：<br>- 数据类型：DutyCycleType<br>- 范围：[-100%…+100%]<br>- 分辨率：100 / M<br>- 精度：HW 提供<br>- 生命周期：x = 延迟 x 微秒 |
| Rationale | IO 硬件抽象的基本功能 |
| Use Case | ICU 需求 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01968)
**6.1.1.1.16 [SRS_IoHwAb_12338] IO 硬件抽象应提供同步信号访问功能**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 即使采样是异步的，IO 硬件抽象也应提供同步信号访问功能（信号访问）。 |
| Rationale | 不同机制的抽象 |
| Use Case | 访问循环 ADC 转换的缓冲区 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01352, RS_BRF_01856)
**6.1.1.1.17 [SRS_IoHwAb_00002] I/O 硬件抽象应提供到 DCM 的接口以控制和读取已配置的信号**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | I/O 硬件抽象应提供到 DCM 的接口，允许控制和读取已配置的信号。接口应实现以下功能：<br>- 通过设置以下状态来控制信号：<br> - IOHWAB_CONTROLTOECU：解锁信号<br> - IOHWAB_RESETTODEFAULT：锁定信号并将其设置为已配置的默认值<br> - IOHWAB_FREEZE：将信号锁定为当前值<br> - IOHWAB_ADJUSTMENT：锁定信号并将其调整为 DCM 模块给定的值<br>- 读取信号（在由"控制功能"设置的任何信号状态下）<br><br>锁定信号意味着某个信号在软件上锁定到 SW-C，即 SW-C 的请求在锁定状态下对硬件没有影响。<br>尽管如此，DCM 应完全访问硬件。如果对输入信号使用 C/S 通信，可能有必要具有 IoHwAb 内部缓冲区，其值可由 DCM 调整。 |
| Rationale | 通过 DCM 诊断 I/O 信号 |
| Use Case | 系统诊断 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01352, RS_BRF_02144)
##### 6.1.1.2 配置（Configuration）
**6.1.1.2.1 [SRS_IoHwAb_12232] 每个信号的符号名称应唯一**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象应允许静态配置每个信号的唯一符号名称。 |
| Rationale | 更改硬件分配时上层无需更改 |
| Use Case | 灵活的 ECU 设计 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01024)
**6.1.1.2.2 [SRS_IoHwAb_12319] IO 硬件抽象模块应独立于物理电平**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | AUTOSAR IO 硬件抽象模块应独立于物理电平（即：输出命令在低电平或高电平有效），并仅为数字 IO 向上层提供逻辑电平。 |
| Rationale | 用户和硬件设计之间的独立性 |
| Use Case | 例如，门可以 OPEN/CLOSE，这些状态独立于实际硬件输入状态（0v、5v、12v） |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01000)
**6.1.1.2.3 [SRS_IoHwAb_12449] IO 硬件抽象应能同时处理多个电气信号**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象应能同时处理多个电气信号。组的定义在配置步骤期间完成。属于一个组的信号始终具有相同的类型。 |
| Rationale | 无时间延迟控制一组信号 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01048)
##### 6.1.1.3 正常运行（Normal Operation）
**6.1.1.3.1 [SRS_IoHwAb_12242] IO 硬件抽象应隐藏通过 ECU 内部板上外设访问信号的任何通信**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象应隐藏通过 ECU 内部板上外设访问信号的任何通信。ECU 上的信号路由由此接口抽象。 |
| Rationale | 对于上层，端口是直接连接到微控制器还是连接到板载 ASIC 都不应有区别。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01080)
##### 6.1.1.4 诊断功能（Diagnostic Functions）
以下示意图显示了输出驱动级及其诊断能力。它们应有助于理解以下需求：
- **数字输出的模拟监控线诊断概念方案**：通过模拟监控线诊断数字输出
- **单驱动级的数字监控线数字输出诊断概念方案**：通过数字监控线诊断数字输出
- **n 通道驱动级的数字监控线数字输出诊断概念方案**：通过数字监控线诊断数字输出
**6.1.1.4.1 [SRS_IoHwAb_13900] IO 硬件抽象应检测对地短路故障（根据硬件能力）**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象应检测对地短路故障（根据硬件能力）。 |
| Rationale | 基本功能 |
| Use Case | 离散负载信号的模拟监控、用于诊断和/或软件驱动级保护的故障检测 |
| Dependencies | -- |
| Supporting Material | 特定硬件设计：现有诊断监控 |
⌋(RS_BRF_02000, RS_BRF_02168)
**6.1.1.4.2 [SRS_IoHwAb_13901] IO 硬件抽象应检测对 +UBat 的短路故障（根据硬件能力）**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象应检测对 +UBat 的短路故障（根据硬件能力）。 |
| Rationale | 基本功能 |
| Use Case | 离散负载信号的模拟监控、用于诊断和/或错误反应的故障检测 |
| Dependencies | -- |
| Supporting Material | 特定硬件设计：现有诊断监控 |
⌋(RS_BRF_02000, RS_BRF_02168)
**6.1.1.4.3 [SRS_IoHwAb_13902] IO 硬件抽象应检测开路（根据硬件能力）**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象应检测开路（根据硬件能力）。 |
| Rationale | 基本功能 |
| Use Case | 离散负载信号的模拟监控、用于诊断和/或错误反应的故障检测 |
| Dependencies | -- |
| Supporting Material | 特定硬件设计：现有诊断监控 |
⌋(RS_BRF_02000, RS_BRF_02168)
**6.1.1.4.4 [SRS_IoHwAb_13903] IO 硬件抽象应检测过载故障**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象应检测过载故障。如果控制输出信号被激活，则执行此检测。 |
| Rationale | 基本功能 |
| Use Case | 离散负载信号的模拟监控、用于诊断和/或错误反应的故障检测 |
| Dependencies | -- |
| Supporting Material | 特定硬件设计：诊断监控 |
⌋(RS_BRF_02176)
**6.1.1.4.5 [SRS_IoHwAb_13904] IO 硬件抽象应检测过热**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象应检测过热。如果控制输出信号被激活，则执行此检测。 |
| Rationale | 基本功能 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | 特定硬件设计：诊断监控 |
⌋(RS_BRF_02168)
##### 6.1.1.5 故障操作（Fault operation）
**6.1.1.5.1 [SRS_IoHwAb_12248] IO 硬件抽象模块应保持 ECU 硬件安全**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块应保持 ECU 硬件安全。<br>当在此输出上检测到故障时，IO 硬件抽象应能切断输出信号。这是为了保护硬件而完成的。 |
| Rationale | 防止 ECU 损坏 |
| Use Case | 对地短路、对电源短路、过热、过载。三次命令后停用输出。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02024)
**6.1.1.5.2 [SRS_IoHwAb_12451] IO 硬件抽象模块不应自行决定重新打开出于硬件保护原因而被关闭的输出**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块不应自行决定重新打开出于硬件保护原因而被关闭的输出。<br>恢复故障的此类策略应在软件组件中定义。 |
| Rationale | 策略包含在 SW-C 中 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02016)
**6.1.1.5.3 [SRS_IoHwAb_12452] IO 硬件抽象模块应提供在输出被切断后触发输出的接口**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象模块应提供在输出被切断后触发输出的接口。 |
| Rationale | 检测电气故障 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01056, RS_BRF_02224)
##### 6.1.1.6 电源状态转换（Power state transitions）
**6.1.1.6.1 [SRS_IoHwAb_12453] 应提供电源状态准备的封装**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 如果实现了对外设的电源控制，IoHwAbstraction 应为每个应用电源模式定义一个 API，其中与给定应用电源模式相关的所有外设电源状态转换都将生效。 |
| Rationale | 需要创建一个封装，允许将最终对车辆系统上不同 ECU 有效的应用电源模式映射到每个 ECU 上每个外设的电源状态。通过这种方式，给定电源模式的设置阶段可以原子地执行，以便所有 HW 外设同步转换到有效电源状态。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | 概念提案 596：ECU 降级 |
⌋(RS_BRF_01952, RS_BRF_01184)
**6.1.1.6.2 [SRS_IoHwAb_12454] 应提供电源状态设置的封装**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 如果实现了对外设的电源控制，IoHwAbstraction 应为每个应用电源模式定义一个 API，其中应准备与给定应用电源模式相关的所有外设电源状态转换（电源状态准备）。 |
| Rationale | 需要创建一个封装，允许将最终对车辆系统上不同 ECU 有效的应用电源模式映射到每个 ECU 上每个外设的电源状态。通过这种方式，给定电源模式的准备阶段可以原子地执行。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | 概念提案 596：ECU 降级 |
⌋(RS_BRF_01952, RS_BRF_01184)
**6.1.1.6.3 [SRS_IoHwAb_12455] 应提供每个电源状态准备完成的回调通知**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 如果实现了对外设的电源控制，IoHwAbstraction 应为实现给定应用电源模式所需的每个外设的每个电源状态定义一个回调。 |
| Rationale | 有必要解耦电源转换的准备阶段和设置阶段。通过这种方式，IoHwAbs 或 CDD 可以避免轮询所有外设的状态以检查何时可以设置电源状态。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | 概念提案 596：ECU 降级 |
⌋(RS_BRF_01952, RS_BRF_01184)
### 6.2 非功能需求（质量）（Non-Functional Requirements (Qualities)）
**6.2.1 [SRS_IoHwAb_12339] IO 硬件抽象应为每个信号保证给定的最坏情况延迟时间**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | IO 硬件抽象应为每个信号保证给定的最坏情况延迟时间。该时间可用于评估时间约束。 |
| Rationale | 满足请求反应时间 |
| Use Case | 大量时间约束，例如按下按钮后的反应 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02168)
---
## 7 参考文献（References）
### 7.1 AUTOSAR 交付物（Deliverables of AUTOSAR）
- **[1]** 分层软件架构，AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
- **[2]** 软件标准化模板，AUTOSAR_TPS_StandardizationTemplate.pdf
---
## 翻译说明
本文档为 AUTOSAR 4.4.0 版本 I/O 硬件抽象需求规范的中文翻译。保留了所有需求 ID（SRS_IoHwAb_xxxxx）、参考标识符及模块缩写。原始文档共 29 页，本翻译涵盖了全部章节内容。IO 硬件抽象层提供基于信号的接口，向上层抽象出 ECU 硬件的信号路径。
IO/AUTOSAR_SRS_OCUDriver.md
+347
View File
@@ -0,0 +1,347 @@
# OCU 驱动需求（Requirements on OCU Driver）
> **AUTOSAR CP Release 4.4.0**
## 文档元信息
| 字段 | 内容 |
|---|---|
| **文档标题** | OCU 驱动需求（Requirements on OCU Driver） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 614 |
| **文档状态** | Final（最终版） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 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 | 新增第 3 章：需求追踪 |
| 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 | 初始发布 |
---
## 文档范围（Scope of this document）
本文档规定了 OCU 驱动模块的需求。
### 约束（Constraints）
基础软件模块需求规范的首要范围是非安全相关系统。因此，安全需求被分配到中等优先级。
---
## 目录（Table of Contents）
1. [如何阅读本文档（How to read this document）](#1-如何阅读本文档)
- 1.1 [使用的约定（Conventions used）](#11-使用的约定)
- 1.2 [需求结构（Requirements structure）](#12-需求结构)
2. [缩略语与缩写（Acronyms and abbreviations）](#2-缩略语与缩写)
3. [需求追踪（Requirements Tracing）](#3-需求追踪)
4. [需求规范（Requirement Specification）](#4-需求规范)
- 4.1 [OCU 驱动](#41-ocu-驱动)
- 4.1.1 [功能概述（Functional Overview）](#411-功能概述)
- 4.1.2 [功能需求（Functional Requirements）](#412-功能需求)
- 4.1.2.1 [配置（Configuration）](#4121-配置)
- 4.1.2.2 [初始化（Initialization）](#4122-初始化)
- 4.1.2.3 [正常运行（Normal Operation）](#4123-正常运行)
- 4.1.2.4 [关闭操作（Shutdown Operation）](#4124-关闭操作)
5. [相关文档（Related Documentation）](#5-相关文档)
- 5.1 [AUTOSAR 交付物（AUTOSAR deliverables）](#51-autosar-交付物)
---
## 1 如何阅读本文档（How to read this document）
每个需求都有其唯一的标识符，以 "BSW"（"Basic Software" 的缩写）前缀开头。对于任何审阅注释、评论或问题，请参考此唯一 ID 而不是章节或页码！
### 1.1 使用的约定（Conventions used）
- AUTOSAR 文档中需求的表示遵循 [6] 中指定的表。
- 在需求中，使用以下特定语义。
本文件中使用的关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照所示进行解释。请注意，它们所使用文档的需求级别会修改这些词的强制力。
- **MUST**：这个词，或术语 "REQUIRED" 或 "SHALL"，意味着该定义是规范的绝对要求。
- **MUST NOT**：这个词组，或词组 "SHALL NOT"，意味着该定义是规范的绝对禁止。
- **SHOULD**：意味着在特定情况下可能存在忽略特定条目的有效理由。
- **SHOULD NOT**：意味着在特定情况下特定行为可能是可接受的甚至是有用的。
- **MAY**：这个词，或形容词 "OPTIONAL"，意味着某个项目是真正可选的。
### 1.2 需求结构（Requirements structure）
每个模块特定章节包含基础软件模块的简短功能描述。同一类型的需求在每个章节内按以下标题分组（如果适用）：
**功能需求（Functional Requirements）：**
- 配置（Configuration）
- 初始化（Initialization）
- 正常运行（Normal Operation）
- 关闭操作（Shutdown Operation）
- 故障操作（Fault Operation）
- ...
**非功能需求（Non-Functional Requirements）：**
- 时间需求（Timing Requirements）
- 资源使用（Resource Usage）
- 可用性（Usability）
- 对其他 WP 的输出
- ...
---
## 2 缩略语与缩写（Acronyms and abbreviations）
| 缩略语 | 描述 |
|---|---|
| OCU | 输出比较单元（Output Compare Unit） |
| OCU channel | 表示由自由运行计数器、比较阈值以及比较过程结果所执行的动作组成的逻辑实体 |
| Compare threshold（比较阈值） | 每次计数器增加一个单位时与计数器内容进行比较的目标值 |
| Free running counter（自由运行计数器） | 从最小值运行到最大值的计数器，并在达到最大值后自动重新启动到最小值 |
| DMA | 直接内存访问（Direct Memory Access） |
| MCAL | 微控制器抽象层（Microcontroller Abstraction Layer） |
| MCU | 微控制器单元（Microcontroller Unit） |
| SPAL | 标准外设抽象层（Standard Peripheral Abstraction Layer） |
| 缩写 | 描述 |
|---|---|
| STD | 标准（Standard） |
| UNINIT | 未初始化（Uninitialized） |
由于这是面向专业人士的专业文档，其他所有术语均假定为已知。
---
## 3 需求追踪（Requirements Tracing）
| 需求 | 描述 | 由...满足 |
|---|---|---|
| RS_BRF_01056 | AUTOSAR BSW 模块应提供标准化接口 | SRS_Ocu_00005, SRS_Ocu_00006, SRS_Ocu_00007, SRS_Ocu_00008, SRS_Ocu_00009, SRS_Ocu_00010, SRS_Ocu_00011, SRS_Ocu_00012 |
| RS_BRF_01064 | AUTOSAR BSW 应提供回调函数以访问上层模块 | SRS_Ocu_00006 |
| RS_BRF_01096 | AUTOSAR 应支持 ECU 的启动和关闭 | SRS_Ocu_00004, SRS_Ocu_00005, SRS_Ocu_00008, SRS_Ocu_00011 |
| RS_BRF_01136 | AUTOSAR 应支持在系统启动后解析已配置 BSW 数据的变体 | SRS_Ocu_00002, SRS_Ocu_00008 |
| RS_BRF_01152 | AUTOSAR 应支持有限的动态重新配置 | SRS_Ocu_00007, SRS_Ocu_00010, SRS_Ocu_00011, SRS_Ocu_00012 |
| RS_BRF_01632 | AUTOSAR 通信应支持信号组的数据一致性 | SRS_Ocu_00013 |
| RS_BRF_01888 | AUTOSAR 微控制器抽象应提供 I/O 信号到输出比较单元的映射 | SRS_Ocu_00002, SRS_Ocu_00011, SRS_Ocu_00012 |
| RS_BRF_01904 | AUTOSAR 微控制器抽象应提供对硬件定时器的访问 | SRS_Ocu_00002, SRS_Ocu_00006, SRS_Ocu_00007, SRS_Ocu_00009, SRS_Ocu_00010, SRS_Ocu_00013, SRS_Ocu_00014 |
| RS_BRF_01968 | AUTOSAR IO 硬件抽象应支持边沿触发的 I/O 信号 | SRS_Ocu_00006 |
| RS_BRF_02040 | AUTOSAR BSW 和 RTE 应确保数据一致性 | SRS_Ocu_00014 |
---
## 4 需求规范（Requirement Specification）
### 4.1 OCU 驱动
#### 4.1.1 功能概述（Functional Overview）
该驱动提供了一种比较两个值并在比较匹配时自动执行操作的方法，从而可以加快软件进程。
本规范规定了 AUTOSAR 基础软件模块输出比较驱动（OCU）的功能、API 和配置。
每个 OCU 通道链接到属于微控制器的硬件 OCU。该驱动提供用于初始化和控制微控制器内部 OCU 外设的服务。OCU 模块可以生成 HW 信号以驱动外部设备。
下图显示了 OCU 通道的典型表示：
```
Free running counter（自由运行计数器）
OUTPUT
Comparison threshold（比较阈值）
```
**图 1：输出比较通道**
"output" 是比较匹配时实际执行的动作。根据配置，可以执行软件动作和/或硬件动作。
#### 4.1.2 功能需求（Functional Requirements）
##### 4.1.2.1 配置（Configuration）
**4.1.2.1.1 [SRS_Ocu_00002] OCU 驱动应支持每个通道的以下基本静态配置**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | OCU 驱动应支持每个通道的以下基本静态配置：<br>**强制参数：**<br>- 通道/通道 ID 的符号名称<br>- 计数器的最大值<br>- 计数分辨率/频率<br>- 通知函数<br>- 阈值的默认值<br>- 已分配的硬件通道<br><br>**可选参数：**<br>- 计数方向<br>- 输出信号（内部信号或端口引脚，如果由硬件提供）。应提供默认输出电平（复位后的值）：<br> - OCU_LOW/OCU_HIGH<br>- 由通道触发的硬件事件（如果硬件支持）：<br> - 硬件资源 ID（例如 OCU_ADC、OCU_DMA）<br> - 每个硬件资源的适当编号（例如 ADC_chn1）<br>- 可选的时钟设置（如果硬件支持）<br><br>此外，如果硬件支持，OCU 驱动应允许配置 OCU-外设的特定设置。 |
| Rationale | 允许每个通道的不同用法 |
| Use Case | |
| Dependencies | -- |
| Supporting Material | |
⌋(RS_BRF_01888, RS_BRF_01904, RS_BRF_01136)
##### 4.1.2.2 初始化（Initialization）
**4.1.2.2.1 [SRS_Ocu_00004] 在初始化 OCU 驱动后，所有通知都应被禁用**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 在初始化 OCU 驱动后，所有通知都应被禁用。所有通道都应停止（无计数运行）。<br>如果通道有相关的输出引脚，则此引脚应设置为通道配置中定义的默认值。 |
| Rationale | 防止初始化后出现不期望的事件。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01096)
**4.1.2.2.2 [SRS_Ocu_00005] OCU 驱动应提供反初始化 OCU 驱动的功能**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | OCU 驱动应提供反初始化 OCU 驱动的功能。 |
| Rationale | 在可以进行有效初始化之前，有必要重置驱动特定资源（SFR、变量等）。 |
| Use Case | 在 ECU 运行时使用有效配置（post-build）重新初始化之前需要进行反初始化。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01096, RS_BRF_01056)
##### 4.1.2.3 正常运行（Normal Operation）
**4.1.2.3.1 [SRS_Ocu_00006] OCU 驱动应在计数器的当前值与阈值匹配时为 OCU 通道提供通知**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | OCU 驱动应在计数器的当前值与阈值匹配时为 OCU 通道提供通知。通知应在以下条件下触发：<br>- 通知函数配置为非空指针<br>- 并且仅当通知被启用时 |
| Rationale | 通道上的比较匹配时，必须执行某个动作。将执行该动作的模块需要被通知。 |
| Use Case | 上层执行与参考同步的动作，该参考由阈值的当前值表示。 |
| Dependencies | -- |
| Supporting Material | |
⌋(RS_BRF_01064, RS_BRF_01968, RS_BRF_01056, RS_BRF_01904)
**4.1.2.3.2 [SRS_Ocu_00007] OCU 驱动应允许在运行时启用/禁用 OCU 通道的通知**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | OCU 驱动应允许在运行时启用/禁用 OCU 通道的通知。<br>对于每个选定通道，应提供以下选项：<br>- 禁用通知<br>- 在比较匹配时启用通知（计数器的当前值等于阈值） |
| Rationale | 防止调用不期望的通知（中断），并允许选择软件执行流中可能出现第一次或下一次通知的确切点。 |
| Use Case | 当通道计数器匹配定义的阈值时，上层被通知以执行任务并可以更改阈值的当前值 |
| Dependencies | -- |
| Supporting Material | |
⌋(RS_BRF_01056, RS_BRF_01152, RS_BRF_01904)
**4.1.2.3.3 [SRS_Ocu_00008] OCU 驱动应提供启动和停止通道的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | OCU 驱动应提供启动和停止通道的服务。停止通道意味着不应再触发任何动作。启动通道意味着允许执行已配置的动作。 |
| Rationale | 允许软件单独控制每个通道的操作。 |
| Use Case | H 桥连接到通道的引脚。引脚必须仅当桥准备好操作时才开始驱动桥。 |
| Dependencies | -- |
| Supporting Material | |
⌋(RS_BRF_01056, RS_BRF_01096, RS_BRF_01136)
**4.1.2.3.4 [SRS_Ocu_00009] OCU 驱动应提供读取计数器值的同步服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | OCU 驱动应提供读取计数器值的同步服务。 |
| Rationale | 通道的计数器值对应于物理信息（时间、压力、角度位置等），上层将其用于各种目的。 |
| Use Case | 上层读取计数器的当前值并计算相应的物理值。 |
| Dependencies | -- |
| Supporting Material | |
⌋(RS_BRF_01056, RS_BRF_01904)
**4.1.2.3.5 [SRS_Ocu_00010] OCU 驱动应提供修改通道阈值的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | OCU 驱动应提供修改通道阈值的服务。此服务应允许为阈值写入：<br>- 绝对值<br>- 或相对值：相对于当前计数器值<br>- 或相对值：相对于当前阈值值（相对值设置需要硬件支持） |
| Rationale | 为上层提供一种动态更改通道比较阈值以适应运行中软件的方法。 |
| Use Case | 当计数器回绕时，使用相对值更新下一个比较阈值。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01056, RS_BRF_01152, RS_BRF_01904)
**4.1.2.3.6 [SRS_Ocu_00011] OCU 驱动应提供同步服务以设置附加到通道的输出引脚的状态**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | OCU 驱动应提供同步服务以设置附加到通道的输出引脚的状态。 |
| Rationale | 根据系统的不同阶段（SHUTDOWN、IDLE 等），输出引脚必须具有已知状态（LOW 或 HIGH） |
| Use Case | 将与通道关联的引脚初始化为相关电平。 |
| Dependencies | -- |
| Supporting Material | |
⌋(RS_BRF_01056, RS_BRF_01152, RS_BRF_01096, RS_BRF_01888)
**4.1.2.3.7 [SRS_Ocu_00012] OCU 驱动应提供服务以设置附加到通道的引脚在比较匹配时将执行的动作**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | OCU 驱动应提供服务以预设置附加到通道的引脚在比较匹配时将执行的动作（如果硬件支持）。此服务应将以下内容作为参数：<br>- OCU 通道<br>- 比较时的引脚动作（如果硬件支持）<br><br>引脚动作的可能值应为 OCU_HIGH、OCU_LOW、OCU_TOGGLE、OCU_DISABLE。 |
| Rationale | 通道的输出引脚必须根据系统需要表现。 |
| Use Case | 在通道的输出引脚处生成脉冲。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01056, RS_BRF_01152, RS_BRF_01888)
**4.1.2.3.8 [SRS_Ocu_00013] OCU 驱动应允许将相同的计数器基准和时序配置为多个通道使用**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | OCU 驱动应允许将相同的计数器基准和时序配置为多个通道使用（如果此功能由硬件支持）。这将允许在组中使用多个通道。<br>配置应提供以下参数：<br>- 要分组的 OCU 通道 |
| Rationale | 允许同步具有相同参考的不同动作。 |
| Use Case | 同步驱动属于 H 桥的一对开关。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01632, RS_BRF_01904)
**4.1.2.3.9 [SRS_Ocu_00014] OCU 驱动的 API 服务内使用的所有单位应为 ticks 单位**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | OCU 驱动的 API 服务内使用的所有单位应为 ticks 单位。 |
| Rationale | 物理单位（阈值和计数器的）与 ticks 之间的转换应为 ECU 抽象层的一部分。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | |
⌋(RS_BRF_02040, RS_BRF_01904)
##### 4.1.2.4 关闭操作（Shutdown Operation）
无。
---
## 5 相关文档（Related Documentation）
### 5.1 AUTOSAR 交付物（AUTOSAR deliverables）
- **[1]** 词汇表，AUTOSAR_TR_Glossary.pdf
- **[2]** 分层软件架构，AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
- **[3]** 基础软件的一般需求，AUTOSAR_SRS_BSWGeneral.pdf
- **[4]** SPAL 的一般需求，AUTOSAR_SRS_SPALGeneral.pdf
- **[5]** 基础软件模块列表，AUTOSAR_BasicSoftwareModuleList.pdf
- **[6]** 软件标准化模板，AUTOSAR_TPS_StandardizationTemplate.pdf
---
## 翻译说明
本文档为 AUTOSAR 4.4.0 版本 OCU 驱动软件需求规范的中文翻译。保留了所有需求 ID（SRS_Ocu_xxxxx）、参考标识符及模块缩写。原始文档共 16 页，本翻译涵盖了全部章节内容。
IO/AUTOSAR_SRS_PWMDriver.md
+459
View File
@@ -0,0 +1,459 @@
# PWM 驱动需求（Requirements on PWM Driver）
> **AUTOSAR CP Release 4.4.0**
## 文档元信息
| 字段 | 内容 |
|---|---|
| **文档标题** | PWM 驱动需求（Requirements on PWM Driver） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 113 |
| **文档状态** | Final（最终版） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 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 | 新增支持 ECU 降级概念的需求；新增到新功能文档的链接 |
| 2010-09-30 | 3.1.5 | 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 | 修改 "SRS_Pwm_12379 PWM 通道组频率" 以支持独立 PWM 频率；与软件同步占空比描述；法律声明修订；"用户建议" 修订；"修订信息" 新增 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 作为独立文档发布。SRS SPAL V1.0.0 已被拆分为 12 个独立文档，以发布 2.0；模块配置修改 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 作为 SRS SPAL V1.0.0 的一部分初始发布 |
---
## 目录（Table of Contents）
1. [文档范围（Scope of Document）](#1-文档范围)
2. [如何阅读本文档（How to read this document）](#2-如何阅读本文档)
- 2.1 [使用的约定（Conventions used）](#21-使用的约定)
- 2.2 [需求结构（Requirements structure）](#22-需求结构)
3. [功能概述（Functional Overview）](#3-功能概述)
4. [缩略语与缩写（Acronyms and abbreviations）](#4-缩略语与缩写)
5. [需求追踪（Requirements Tracing）](#5-需求追踪)
6. [需求规范（Requirement Specification）](#6-需求规范)
- 6.1 [功能需求（Functional Requirements）](#61-功能需求)
- 6.1.1 [通用（General）](#611-通用)
- 6.1.2 [配置（Configuration）](#612-配置)
- 6.1.3 [初始化（Initialization）](#613-初始化)
- 6.1.4 [正常运行（Normal Operation）](#614-正常运行)
- 6.2 [非功能需求（Non-Functional Requirements）](#62-非功能需求)
- 6.2.1 [SRS_Pwm_12386 PWM 驱动不应涵盖通用 I/O 上的 PWM 仿真](#621-srs_pwm_12386)
7. [相关文档（Related Documentation）](#7-相关文档)
- 7.1 [AUTOSAR 交付物（Deliverables of AUTOSAR）](#71-autosar-交付物)
---
## 1 文档范围（Scope of Document）
本文档规定了 PWM 驱动模块的需求。
### 约束（Constraints）
基础软件模块需求规范的首要范围是非安全相关系统。因此，安全需求被分配到中等优先级。
---
## 2 如何阅读本文档（How to read this document）
每个需求都有其唯一的标识符，以 "BSW"（"Basic Software" 的缩写）前缀开头。对于任何审阅注释、评论或问题，请参考此唯一 ID 而不是章节或页码！
### 2.1 使用的约定（Conventions used）
- AUTOSAR 文档中需求的表示遵循 [5] 中指定的表。
- 在需求中，使用以下特定语义。
本文件中使用的关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照所示进行解释。请注意，它们所使用文档的需求级别会修改这些词的强制力。
- **MUST**：这个词，或术语 "REQUIRED" 或 "SHALL"，意味着该定义是规范的绝对要求。
- **MUST NOT**：这个词组，或词组 "SHALL NOT"，意味着该定义是规范的绝对禁止。
- **SHOULD**：这个词，或形容词 "RECOMMENDED"，意味着在特定情况下可能存在忽略特定条目的有效理由。
- **SHOULD NOT**：意味着在特定情况下特定行为可能是可接受的甚至是有用的，但在实现任何带有此标签描述的行为之前，应理解其全部含义并仔细权衡该情况。
- **MAY**：这个词，或形容词 "OPTIONAL"，意味着某个项目是真正可选的。
### 2.2 需求结构（Requirements structure）
每个模块特定章节包含基础软件模块的简短功能描述。同一类型的需求在每个章节内按以下标题分组（如果适用）：
**功能需求（Functional Requirements）：**
- 配置（Configuration）
- 初始化（Initialisation）
- 正常运行（Normal Operation）
- 关闭操作（Shutdown Operation）
- 故障操作（Fault Operation）
- ...
**非功能需求（Non-Functional Requirements）：**
- 时间需求（Timing Requirements）
- 资源使用（Resource Usage）
- 可用性（Usability）
- 对其他 WP 的输出
- ...
---
## 3 功能概述（Functional Overview）
本规范规定了 AUTOSAR 基础软件模块 Pwm 驱动的功能、API 和配置。
每个 PWM 通道链接到属于微控制器的硬件 PWM。PWM 信号的类型（例如中心对齐、左对齐等）未在本规范中定义，留给实现。
驱动提供用于初始化和控制微控制器内部 PWM 级（脉宽调制）的服务。PWM 模块生成具有可变脉冲宽度的脉冲。它允许选择占空比和信号周期时间。
---
## 4 缩略语与缩写（Acronyms and abbreviations）
| 缩略语 | 描述 |
|---|---|
| CS | 片选（Chip Select） |
| DIO | 数字输入输出（Digital Input Output） |
| ECU | 电控单元（Electric Control Unit） |
| DMA | 直接内存访问（Direct Memory Access） |
| ICU | 输入捕获单元（Input Capture Unit） |
| MAL | 微控制器抽象层的旧名称（已被 MCAL 取代，因为 'MAL' 在法语中意为 'bad'） |
| MCAL | 微控制器抽象层（Microcontroller Abstraction Layer） |
| MCU | 微控制器单元（Microcontroller Unit） |
| MISO | 主输入从输出（Master Input Slave Output） |
| MMU | 内存管理单元（Memory Management Unit） |
| MOSI | 主输出从输入（Master Output Slave Input） |
| Master | 控制其他设备（从设备）的设备 |
| Slave | 完全由主设备控制的设备 |
| NMI | 不可屏蔽中断（Non Maskable Interrupt） |
| OS | 操作系统（Operating System） |
| PLL | 锁相环（Phase Locked Loop） |
| PWM | 脉宽调制（Pulse Width Modulation） |
| RX | 接收（Reception，在总线通信的上下文中） |
| SPAL | 此工作组名称 |
| SFR | 特殊功能寄存器（Special Function Register） |
| RTE | 运行时环境（RunTime Environment） |
| 缩写 | 描述 |
|---|---|
| STD | 标准（Standard） |
| REQ | 需求（Requirement） |
| UNINIT | 未初始化（Uninitialized） |
由于这是面向专业人士的专业文档，其他所有术语均假定为已知。
---
## 5 需求追踪（Requirements Tracing）
| 需求 | 描述 | 由...满足 |
|---|---|---|
| RS_BRF_01008 | AUTOSAR 应将硬件相关层组织成微控制器独立层和微控制器依赖层 | SRS_Pwm_12379 |
| RS_BRF_01096 | AUTOSAR 应支持 ECU 的启动和关闭 | SRS_Pwm_12380, SRS_Pwm_12381 |
| RS_BRF_01136 | AUTOSAR 应支持在系统启动后解析已配置 BSW 数据的变体 | SRS_Pwm_12295, SRS_Pwm_12380, SRS_Pwm_12382 |
| RS_BRF_01184 | AUTOSAR 应支持不同的降级方法 | SRS_Pwm_12460, SRS_Pwm_12461, SRS_Pwm_12462, SRS_Pwm_12463 |
| RS_BRF_01448 | AUTOSAR 服务应支持模式和状态管理 | SRS_Pwm_12358, SRS_Pwm_12385, SRS_Pwm_12460, SRS_Pwm_12461, SRS_Pwm_12462, SRS_Pwm_12463 |
| RS_BRF_01856 | AUTOSAR 微控制器抽象应提供对内部 MCU 配置的访问 | SRS_Pwm_12293, SRS_Pwm_12375, SRS_Pwm_12389 |
| RS_BRF_01968 | AUTOSAR IO 硬件抽象应支持边沿触发的 I/O 信号 | SRS_Pwm_12299 |
| RS_BRF_01992 | AUTOSAR IO 硬件抽象应支持频域 I/O 信号 | SRS_Pwm_12297, SRS_Pwm_12383, SRS_Pwm_12459 |
| RS_BRF_02200 | AUTOSAR 诊断应提供对内部配置和校准数据的外部访问 | SRS_Pwm_12378 |
---
## 6 需求规范（Requirement Specification）
### 6.1 功能需求（Functional Requirements）
#### 6.1.1 通用（General）
**6.1.1.1 [SRS_Pwm_12459] PWM 驱动应为占空比提供缩放方案**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应为占空比提供以下缩放方案：<br>- 0 = 0%<br>- 0x8000 = 100%<br><br>0x8000 提供最高分辨率，同时允许使用 16 位值表示 100% 占空比。 |
| Rationale | 选择值 0x8000（32768）是因为可以高效地实现以下计算。 |
| Use Case | 源代码示例：<br>`AbsoluteDutyCycle = ((uint32)AbsolutePeriodTime * RelativeDutyCycle) >> 15;` |
| Dependencies | [SRS_Pwm_12383] 占空比分辨率 |
| Supporting Material | -- |
⌋(RS_BRF_01992)
**6.1.1.2 [SRS_Pwm_12383] PWM 驱动应提供 16 位接口以设置占空比**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应提供 16 位接口以设置占空比。 |
| Rationale | -- |
| Use Case | -- |
| Dependencies | 占空比始终是信号的有效电平（高或低，取决于空闲电平配置，请参见 [SRS_Pwm_12293]） |
| Supporting Material | -- |
⌋(RS_BRF_01992)
#### 6.1.2 配置（Configuration）
**6.1.2.1 [SRS_Pwm_12375] PWM 驱动应允许对 PWM 通道数进行模块范围配置**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应允许对以下参数进行模块范围配置：<br>- PWM 通道数 |
| Rationale | 基本配置 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01856)
**6.1.2.2 [SRS_Pwm_12293] PWM 驱动应允许对 PWM 通道属性进行静态配置**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应允许对每个 PWM 通道的以下选项进行静态配置。<br>**强制参数：**<br>- 已分配的硬件通道<br>- 默认周期值<br>- 默认占空比值<br>- 极性（高或低）<br>- 空闲状态（占空比 = 0%）高或低<br>- 通道类型：<br> - 固定周期<br> - 固定周期、移相（如果硬件支持）<br> - 可变周期<br><br>**可选参数（如果硬件支持）：**<br>- 通道相位偏移<br>- 相位偏移的参考通道<br>- 微控制器特定通道属性 |
| Rationale | 基本通道配置。 |
| Use Case | 通道相位偏移：避免 EMC 问题 |
| Dependencies | [SRS_Pwm_12383], [SRS_Pwm_12459] |
| Supporting Material | -- |
⌋(RS_BRF_01856)
**6.1.2.3 [SRS_Pwm_12378] PWM 驱动应能为 PWM 信号的每个边沿分配通知**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应能为 PWM 信号的每个边沿分配通知。该通知应可静态配置。 |
| Rationale | -- |
| Use Case | PWM 边沿触发的 ADC 转换<br>PWM 信号诊断 |
| Dependencies | [SRS_Pwm_12299], [SRS_Pwm_12293] |
| Supporting Material | -- |
⌋(RS_BRF_02200)
**6.1.2.4 [SRS_Pwm_12379] 使用相同 MCU 定时器的所有 PWM 通道应具有相同频率或独立频率**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 使用相同 MCU 定时器的所有 PWM 通道应具有相同频率或独立频率。 |
| Rationale | 取决于微控制器硬件，可能并非每个 PWM 通道都有自己的定时器。在这种情况下，PWM 通道必须共享一个定时器。PWM 通道的频率必须与硬件定时器频率相同或独立。配置必须考虑这一点。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01008)
**6.1.2.5 [SRS_Pwm_12389] PWM 驱动应仅允许对某些 PWM 通道的频率进行静态配置**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应仅允许对某些 PWM 通道的频率进行静态配置。 |
| Rationale | -- |
| Use Case | 某些 PWM 通道的频率在运行时不应可更改 |
| Dependencies | [SRS_Pwm_12293] 通道类型的配置 |
| Supporting Material | -- |
⌋(RS_BRF_01856)
#### 6.1.3 初始化（Initialization）
**6.1.3.1 [SRS_Pwm_12380] 通过初始化 PWM 驱动，所有 PWM 通道都应启动**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 通过初始化 PWM 驱动，所有 PWM 通道都已启动。 |
| Rationale | -- |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01136, RS_BRF_01096)
**6.1.3.2 [SRS_Pwm_12381] 通过反初始化 PWM 驱动，所有 PWM 通道都应停止**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 通过反初始化 PWM 驱动，所有 PWM 通道都已停止。PWM 输出的状态应可配置。 |
| Rationale | -- |
| Use Case | -- |
| Dependencies | [SRS_Pwm_12293] PWM 通道属性配置 |
| Supporting Material | -- |
⌋(RS_BRF_01096)
#### 6.1.4 正常运行（Normal Operation）
**6.1.4.1 [SRS_Pwm_12295] PWM 驱动应提供设置选定通道占空比的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应提供设置选定通道占空比的服务。参数应为：<br>- PWM 通道<br>- PWM 占空比（范围：0..100%；0% = 反相极性电平，100% = 极性电平，不允许出现尖峰） |
| Rationale | 基本功能。 |
| Use Case | -- |
| Dependencies | [SRS_Pwm_12459], [SRS_Pwm_12383] |
| Supporting Material | -- |
⌋(RS_BRF_01136)
**6.1.4.2 [SRS_Pwm_12382] PWM 驱动应等到信号周期结束以更新 PWM 信号的占空比**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应等到信号周期结束以更新 PWM 信号的占空比。该功能应可配置。 |
| Rationale | 占空比在周期内无效。<br>周期内的占空比变化可能导致输出信号上的不期望伪影（插入一个过短/过长的脉冲）。这被称为"缓冲/非缓冲 PWM 输出操作"（Freescale HC08）。缓冲操作（可避免这些不良影响）需要两个寄存器而不是一个。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01136)
**6.1.4.3 [SRS_Pwm_12358] PWM 驱动应能将所选通道的输出立即设置为给定状态**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应能将所选通道的输出立即设置为给定状态。 |
| Rationale | 允许禁用 PWM 输出。 |
| Use Case | MOSFET 控制的直流电机的制动斜坡：<br>占空比在斜坡内逐步降低。达到目标制动占空比值（例如 35%）后，通过立即将占空比设置为 0% 来关闭 MOSFET。 |
| Dependencies | -- |
| Supporting Material | 这应是一个单独的接口 |
⌋(RS_BRF_01448)
**6.1.4.4 [SRS_Pwm_12385] PWM 驱动应提供获取 PWM 通道输出状态的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应提供获取 PWM 通道状态（高或低）的服务（如果硬件支持）。 |
| Rationale | 允许读回 PWM 的状态以进行诊断。 |
| Use Case | 低频 PWM 输出的诊断。<br>调制时使用轮询进行边沿检测。<br><br>Hella 在 2005-02-17 的说明：<br>功率级连接到 PWM 输出引脚。功率级的诊断输出连接到 ADC 输入引脚。一旦 PWM 输出引脚上出现所请求的电平，就应启动诊断输出的评估。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01448)
**6.1.4.5 [SRS_Pwm_12297] PWM 驱动应提供设置选定通道周期的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应提供设置选定通道周期的服务。参数应为：<br>- PWM 通道<br>- PWM 周期<br>- PWM 占空比<br><br>此功能仅适用于配置为"可变周期"通道类型的 PWM 通道。 |
| Rationale | PWM 占空比参数对于保持频率和占空比之间的一致性是必要的。否则，当周期有效时有效占空比将发生变化，或者 PWM 驱动将不得不自行重新计算有效占空比。 |
| Use Case | - 具有稳定 50% 占空比方波的 Kojak 警报器<br>- 具有不同频率的 LED 闪烁 |
| Dependencies | [SRS_Pwm_12459] PWM 占空比缩放 |
| Supporting Material | -- |
⌋(RS_BRF_01992)
**6.1.4.6 [SRS_Pwm_12299] PWM 驱动应允许在运行时启用/禁用 PWM 边沿通知**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应允许在运行时启用/禁用 PWM 边沿通知。 |
| Rationale | 允许与其他模块同步 |
| Use Case | PWM 边沿触发的 ADC 转换<br>PWM 信号诊断<br>在单缓冲情况下使用通知更新占空比 |
| Dependencies | [SRS_Pwm_12293] PWM 通道属性配置 |
| Supporting Material | -- |
⌋(RS_BRF_01968)
**6.1.4.7 [SRS_Pwm_12460] API 应能读取 PWM HW 模块的当前电源状态**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应实现允许从 MCAL 模块外部读取 HW 外设当前电源状态的 API。此 API 可由 IoHwAbs 和 CDD SW 组件使用。 |
| Rationale | 必须能够收集有关外设当前电源状态的信息；这对于断言外设的实际状态很有用，例如为了知道在给定时刻外设支持哪些操作，或者决定应将其设置为哪个电源状态。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | 概念 n.596 ECU 降级 |
⌋(RS_BRF_01448, RS_BRF_01184)
**6.1.4.8 [SRS_Pwm_12461] API 应能读取 <PWM/ADC> HW 模块的目标电源状态**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应实现允许从 MCAL 模块外部读取 HW 外设目标电源状态的 API。此 API 可由 IoHwAbs 和 CDD SW 组件使用。 |
| Rationale | 获取有关目标电源状态的信息是必要的，以便了解是否正在执行电源状态转换，以及在肯定的情况下，是哪一个。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | 概念 n.596 ECU 降级 |
⌋(RS_BRF_01448, RS_BRF_01184)
**6.1.4.9 [SRS_Pwm_12462] PWM 驱动应将电源状态设置过程分为两部分**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应将电源状态转换序列分为两部分：准备阶段（允许外设进入目标电源状态的预备配置更改）和设置阶段（有效启用有效电源状态）。 |
| Rationale | 某些外设可能比其他外设需要更多时间来执行进入给定电源状态所需的所有预备转换。此外，模块之间可能存在一些与硬件相关的依赖关系，需要在能够转换目标外设之前将不同的外设设置为特定的电源状态或硬件配置。<br>通过将过程分为准备阶段和设置阶段，可以同步不同的外设，使其全部同时进入有效的电源状态，并且还可以协调硬件状态中间转换。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | 概念 n.596 ECU 降级 |
⌋(RS_BRF_01448, RS_BRF_01184)
**6.1.4.10 [SRS_Pwm_12463] 应能选择同步或异步的电源状态转换过程**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 应能配置同步或异步电源状态转换行为。如果配置了同步行为，则电源转换准备应原子地发生，并且执行它的 SWC 必须等待结果。如果配置了异步行为，则电源转换准备应在请求后在后台进行，并且 MCAL 模块应在完成时通知已注册的 SWC。 |
| Rationale | 某些外设可以在可忽略或可接受的时间内准备为有效电源状态，从而可以节省处理通知所需的基础结构，同时阻塞调用者所需的时间。其他外设可能需要更长的时间来准备目标电源状态，在这种情况下，期望通知的 SWC 可以指示不同的模块为电源状态做准备并继续其执行，直到相关 MCAL 模块发出所有通知。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | 概念 n.596 ECU 降级 |
⌋(RS_BRF_01448, RS_BRF_01184)
### 6.2 非功能需求（Non-Functional Requirements）
#### 6.2.1 [SRS_Pwm_12386] PWM 驱动不应涵盖通用 I/O 上的 PWM 仿真
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | PWM 驱动应仅适用于 MCU 上的 PWM 引脚。<br>PWM 驱动不应涵盖通用 I/O 上的 PWM 仿真。 |
| Rationale | -- |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
---
## 7 相关文档（Related Documentation）
### 7.1 AUTOSAR 交付物（Deliverables of AUTOSAR）
- **[1]** 基础软件模块列表，AUTOSAR_TR_BSWModuleList.pdf
- **[2]** 分层软件架构，AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
- **[3]** 基础软件模块的一般需求，AUTOSAR_SRS_BSWGeneral.pdf
- **[4]** SPAL 的一般需求，AUTOSAR_SRS_SPALGeneral.pdf
- **[5]** 软件标准化模板，AUTOSAR_TPS_StandardizationTemplate.pdf
---
## 翻译说明
本文档为 AUTOSAR 4.4.0 版本 PWM 驱动软件需求规范的中文翻译。保留了所有需求 ID（SRS_Pwm_xxxxx）、参考标识符及模块缩写。原始文档共 19 页，本翻译涵盖了全部章节内容。
IO/AUTOSAR_SRS_PortDriver.md
+259
View File
@@ -0,0 +1,259 @@
# Port 驱动需求（Requirements on Port Driver）
> **AUTOSAR CP Release 4.4.0**
## 文档元信息
| 字段 | 内容 |
|---|---|
| **文档标题** | Port 驱动需求（Requirements on Port Driver） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 196 |
| **文档状态** | Final（最终版） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 编辑性变更 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 编辑性变更 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | TPS_STDT_0078 格式化；BSWAndRTE_Features 的可追溯性 |
| 2010-09-30 | 3.1.5 | 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 | 作为独立文档发布。SRS SPAL V1.0.0 已被拆分为 12 个独立文档，以发布 2.0；正式问题的细微变更 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 作为 SRS SPAL V1.0.0 的一部分初始发布 |
---
## 目录（Table of Contents）
1. [文档范围（Scope of document）](#1-文档范围)
2. [如何阅读本文档（How to Read this Document）](#2-如何阅读本文档)
- 2.1 [使用的约定（Conventions used）](#21-使用的约定)
- 2.2 [需求结构（Requirements structure）](#22-需求结构)
3. [缩略语与缩写（Acronyms and abbreviations）](#3-缩略语与缩写)
4. [功能概述（Functional Overview）](#4-功能概述)
5. [需求规范（Requirement Specification）](#5-需求规范)
- 5.1 [功能需求（Functional Requirements）](#51-功能需求)
- 5.1.1 [配置（Configuration）](#511-配置)
- 5.1.2 [正常运行（Normal Operation）](#512-正常运行)
- 5.2 [非功能需求（Non-Functional Requirements）](#52-非功能需求)
- 5.2.2 [过程需求（Process Requirements）](#522-过程需求)
6. [参考文献（References）](#6-参考文献)
- 6.1 [AUTOSAR 交付物（Deliverables of AUTOSAR）](#61-autosar-交付物)
---
## 1 文档范围（Scope of document）
本文档规定了 PORT 驱动模块的需求。
### 约束（Constraints）
基础软件模块需求规范的首要范围是非安全相关系统。因此，安全需求被分配到中等优先级。
---
## 2 如何阅读本文档（How to Read this Document）
每个需求都有其唯一的标识符，以 "BSW"（"Basic Software" 的缩写）前缀开头。对于任何审阅注释、评论或问题，请参考此唯一 ID 而不是章节或页码！
### 2.1 使用的约定（Conventions used）
- AUTOSAR 文档中需求的表示遵循 [TPS_STDT_0078] 中指定的表。
- 在需求中，使用以下特定语义。
本文件中使用的关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照所示进行解释。请注意，它们所使用文档的需求级别会修改这些词的强制力。
- **MUST**：这个词，或术语 "REQUIRED" 或 "SHALL"，意味着该定义是规范的绝对要求。
- **MUST NOT**：这个词组，或词组 "SHALL NOT"，意味着该定义是规范的绝对禁止。
- **SHOULD**：这个词，或形容词 "RECOMMENDED"，意味着在特定情况下可能存在忽略特定条目的有效理由，但在选择不同方案之前必须充分理解并仔细权衡其全部含义。
- **SHOULD NOT**：这个词组，或词组 "NOT RECOMMENDED"，意味着在特定情况下特定行为可能是可接受的甚至是有用的，但在实现任何带有此标签描述的行为之前，应理解其全部含义并仔细权衡该情况。
- **MAY**：这个词，或形容词 "OPTIONAL"，意味着某个项目是真正可选的。一个供应商可能选择包含该项目，因为特定市场需要它或因为供应商认为它增强了产品，而另一个供应商可能省略同一项目。不包含特定选项的实现必须准备好与包含该选项的另一个实现互操作，尽管可能具有降低的功能。同样，包含特定选项的实现必须准备好与不包含该选项的另一个实现互操作（当然，除了该选项提供的功能之外）。
### 2.2 需求结构（Requirements structure）
每个模块特定章节包含基础软件模块的简短功能描述。同一类型的需求在每个章节内按以下标题分组（如果适用）：
**功能需求（Functional Requirements）：**
- 配置（Configuration）
- 初始化（Initialisation）
- 正常运行（Normal Operation）
- 关闭操作（Shutdown Operation）
- 故障操作（Fault Operation）
- ...
**非功能需求（Non-Functional Requirements）：**
- 时间需求（Timing Requirements）
- 资源使用（Resource Usage）
- 可用性（Usability）
- 对其他 WP 的输出（例如描述模板、工具等）
- ...
---
## 3 缩略语与缩写（Acronyms and abbreviations）
具有局部范围的缩略语和缩写不包含在 AUTOSAR 词汇表中。这些必须出现在局部词汇表中。
| 缩略语 | 描述 |
|---|---|
| ADC | 模数转换器（Analogue to Digital Converter） |
| DIO | 数字输入输出（Digital Input Output） |
| ICU | 输入捕获单元（Input Capture Unit） |
| MCAL | 微控制器抽象层（Microcontroller Abstraction Layer） |
| MCU | 微控制器单元（Microcontroller Unit） |
| OS | 操作系统（Operating System） |
| PWM | 脉宽调制（Pulse Width Modulation） |
| SCI | 串行通信接口（Serial Communication Interface） |
| SPAL | 此工作组名称（标准外设抽象层，Standard Peripheral Abstraction Layer） |
| SPI | 串行外设接口（Serial Peripheral Interface） |
| WP | 工作包（Work Package） |
| 缩写 | 描述 |
|---|---|
| STD | 标准（Standard） |
| REQ | 需求（Requirement） |
| UNINIT | 未初始化（Uninitialized） |
由于这是面向专业人士的专业文档，其他所有术语均假定为已知。
---
## 4 功能概述（Functional Overview）
本模块初始化微控制器的整个端口结构。许多端口和端口引脚可以分配给各种功能，例如：
- 通用 I/O
- ADC
- SPI
- SCI
- PWM
因此，必须对此端口结构进行整体配置和初始化。这些端口引脚的配置和使用取决于微控制器和 ECU。
Port 驱动中使用以下表达式：
| 表达式 | 解释 |
|---|---|
| 物理电平（输入）：Physical Level (Input) | 两种可能状态：LOW/HIGH（低/高） |
| 物理电平（输出）：Physical Level (Output) | 三种可能状态：LOW/HIGH/高阻态 |
| 逻辑电平：Logical Level | 软件中看到的电平：TRUE/FALSE（真/假） |
---
## 5 需求规范（Requirement Specification）
### 5.1 功能需求（Functional Requirements）
#### 5.1.1 配置（Configuration）
**5.1.1.1 [SRS_Port_12001] Port 驱动应允许对每个端口的以下选项进行静态配置**
⌈
| 字段 | 内容 |
|---|---|
| Type（类型） | Valid（有效） |
| Description（描述） | Port 驱动应允许对每个端口的以下选项进行静态配置。配置的粒度（整个端口或单个端口引脚）取决于微控制器。<br>**强制参数：**<br>- 引脚用途（例如 DIO、ADC、SPI…）<br>- 引脚方向（输入、输出）<br>- 引脚电平初始化值<br>- 引脚方向是否可在运行时更改（是/否）<br><br>**可选参数（仅当硬件支持时）：**<br>- 激活内部上拉/下拉<br>- 压摆率控制<br>- 输入阈值<br>- 引脚驱动模式（推挽/开漏）<br>- 其他微控制器特定属性<br><br>电平反相功能不应可配置，而应设置为默认值（未反相）。<br>电平反相是 I/O 硬件抽象的任务。 |
| Rationale（原理） | 基本配置；运行时更改引脚方向：这是端口刷新和运行时方向更改所需的信息，请参见 [SRS_Port_12405] 设置端口引脚方向和 [SRS_Port_12406] 刷新端口方向。 |
| Use Case（用例） | -- |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋(RS_BRF_01864)
**5.1.1.2 [SRS_Port_12302] Port 驱动应允许对端口引脚名称进行静态配置**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | Port 驱动应允许对以下符号名称进行静态配置：<br>- 端口引脚名称 |
| Rationale | 为微控制器端口和端口引脚提供人类可读的符号名称。 |
| Use Case | 示例：<br>- PORT_A_PIN_0 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01864)
#### 5.1.2 正常运行（Normal Operation）
**5.1.2.1 [SRS_Port_12405] Port 驱动应在运行时提供设置端口引脚方向的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | valid |
| Description | Port 驱动应在运行时提供设置端口引脚方向的服务。<br>Port 驱动应仅允许更改那些被配置为可更改方向的端口引脚的方向。 |
| Rationale | -- |
| Use Case | 与 ASIC 的单线双向通信。 |
| Dependencies | [SRS_Port_12001] 端口引脚属性配置 |
| Supporting Material | -- |
⌋(RS_BRF_01056, RS_BRF_01864)
**5.1.2.2 [SRS_Port_12406] Port 驱动应提供刷新所有已配置端口方向的服务**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | Port 驱动应提供将所有已配置端口的方向刷新为已配置方向的服务。<br>Port 驱动应从刷新中排除那些被配置为"运行时方向可更改"的端口引脚。 |
| Rationale | 使系统对 EMC 和应用软件错误（端口数据方向寄存器损坏）更具鲁棒性。 |
| Use Case | -- |
| Dependencies | [SRS_Port_12001] 端口引脚属性配置 |
| Supporting Material | -- |
⌋(RS_BRF_01056, RS_BRF_01864)
### 5.2 非功能需求（Non-Functional Requirements）
**5.2.1.1 [SRS_Port_12423] Port 驱动的所有可重入函数应以原子方式执行端口寄存器访问操作**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | Port 驱动的所有可重入函数应以原子方式执行端口寄存器访问操作。 |
| Rationale | 避免 Port 驱动 API 函数并发访问中的数据完整性问题。 |
| Use Case | 特定微控制器（或特定编译器）不提供对单个端口引脚的原子访问。因此，实现必须对整个端口使用读-修改-写操作。如果不阻塞并发访问，则对同一端口的引脚的并发访问将导致数据完整性问题。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01864)
#### 5.2.2 过程需求（Process Requirements）
**5.2.2.1 [SRS_Port_12300] 未使用的端口和端口引脚应设置为已定义状态**
⌈
| 字段 | 内容 |
|---|---|
| Type | Valid |
| Description | 未使用的端口和端口引脚（既不作为通用 I/O 也不作为专用 I/O）应由 Port 模块配置设置为已定义状态。 |
| Rationale | 确保所有端口和端口引脚都处于已定义状态。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01864)
---
## 6 参考文献（References）
### 6.1 AUTOSAR 交付物（Deliverables of AUTOSAR）
- **[DOC_LAYERED_ARCH]** 分层软件架构，AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
- **[AUTOSAR_GLOSSARY]** 词汇表，AUTOSAR_TR_Glossary.pdf
- **[SRS_BSW_GENERAL]** 基础软件模块的一般需求，AUTOSAR_SRS_BSWGeneral.pdf
- **[SRS_BSW_SPAL]** SPAL 的一般需求，AUTOSAR_SRS_SPALGeneral.pdf
- **[TPS_STDT_0078]** 软件标准化模板，AUTOSAR_TPS_StandardizationTemplate.pdf
---
## 翻译说明
本文档为 AUTOSAR 4.4.0 版本 Port 驱动软件需求规范的中文翻译。保留了所有需求 ID（SRS_Port_xxxxx）、参考标识符及模块缩写。原始文档共 13 页，本翻译涵盖了全部章节内容。
IO/AUTOSAR_SWS_ADCDriver.md
+905
View File
@@ -0,0 +1,905 @@
# ADC 驱动规范（Specification of ADC Driver）
| 字段 | 内容 |
|---|---|
| **文档标题** | ADC 驱动规范（Specification of ADC Driver） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 010 |
| **文档状态** | Final（正式发布） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
---
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 头文件结构移除；序列图和状态图更新；API 输入参数传递细微修改；编辑性变更 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 引入运行时错误；部分开发错误变更为运行时错误；将 Delta Sigma ADC 硬件排除在 ADC 驱动范围之外；`Adc_SetupResultBuffer` 和 `Adc_ReadGroup` API 的细微修改；头文件结构更新；编辑性变更 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 移除 Variant-Post-Build 需求；初始化 API 变体特定需求移除；错误分类表更新；编辑性变更 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | DET 从"Development Error Tracer"更改为"Default Error Tracer" |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | `AdcGroupId` 在所有变体中更改为预编译时值 |
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | "Common" Published Information 修正；ARXML 适配 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 编辑性变更；删除变更文档章节 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | API 和配置参数添加以支持 ECU 降级概念；Common Published Information 移除；BSW General 修订 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 移除用于调试的 ADC 组状态要求 |
| 2009-12-18 | 4.0.1 | AUTOSAR Administration | 新增 ADC444 `Adc_ResultAlignmentType`；`SWS_Adc_00124` 版本号检查修正；`SWS_Adc_00337` 重新表述；`AdcPrescale` 和 `AdcChannelId` 范围限制；移除 `InstanceId`；移除 `ADC324`；引入 `SWS_Adc_00458`，`Adc_GetVersionInfo` 的 DET |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 包含限制检查支持；新增配置参数 `AdcEnableLimitCheck`、`AdcChannelLimitCheck`、`AdcChannelLowLimit`、`AdcChannelHighLimit`、`AdcChannelRangeSelect`；添加 ADC 调试支持；ADC 可配置 ADC 数据缓冲区对齐；`AdcGroupId`、`AdcStreamingNumSamples`、`AdcMaxChannelResolution`、`AdcChannelResolution` 的最小/最大值；法律声明修订 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律声明修订 |
| 2008-02-01 | 3.0.2 | AUTOSAR Administration | 目录表修正 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 新 API `Adc_ReadGroup` 引入；移除 API `Adc_ValueReadGroup`；修改 API `Adc_GetStreamLastPointer`；新增配置参数；状态图新增；新状态转换定义；新状态 `ADC_STREAM_COMPLETED` 添加；状态相关需求添加；序列图修改和扩展；ADC 缓冲区访问模式示例添加；新 DET 定义 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | "Advice for users"修订；"Revision Information"新增 |
| 2006-11-28 | 2.1.14 | AUTOSAR Administration | 移除"On Demand"功能；移除"Gated Continuous"转换模式；移除内部和外部硬件触发之间的区别；引入通道组的优先级机制；重新处理"Streaming Access Mode" |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 文档结构适配通用 Release 2.0 SWS 模板 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 初始发布 |
---
## 目录（Table of Contents）
1. [引言与功能概述](#1-引言与功能概述)
2. [缩略语与缩写](#2-缩略语与缩写)
3. [相关文档](#3-相关文档)
4. [约束与假设](#4-约束与假设)
5. [与其他模块的依赖关系](#5-与其他模块的依赖关系)
6. [需求可追溯性](#6-需求可追溯性)
7. [功能规范](#7-功能规范)
8. [API 规范](#8-api-规范)
9. [序列图](#9-序列图)
10. [配置规范](#10-配置规范)
11. [不适用的需求](#11-不适用的需求)
---
## 1 引言与功能概述
本规范描述了 AUTOSAR 基础软件模块 ADC 驱动的功能、API 和配置。**ADC 驱动针对逐次逼近型 ADC 硬件**。Delta Sigma ADC 转换用例不在本规范范围内。
ADC 模块初始化并控制微控制器的内部模数转换器单元（Analogue Digital Converter Unit）。它提供服务以**启动和停止转换**，以及**启用和禁用转换触发源**。此外，它提供服务以启用和禁用通知机制，并提供查询转换状态和结果的例程。
ADC 模块作用于所谓的 **ADC 通道组（ADC Channel Groups）**，这些组由所谓的 **ADC 通道（ADC Channels）** 构成。一个 ADC 通道组将模拟输入引脚（ADC 通道）、所需的 ADC 电路本身以及转换结果寄存器组合到一个可由 ADC 模块单独控制和访问的实体中。
> **摘要标记**：本规范的 1.x 节重点介绍 ADC 驱动的核心概念：通道、通道组、转换模式（One-Shot / Continuous）、触发源（HW / SW）和结果访问模式（Single / Streaming）。完整介绍见原文 PDF 第 10 页。
---
## 2 缩略语与缩写
**缩写 / 首字母缩略词**
| 缩写 | 描述 |
|---|---|
| ADC | Analogue Digital Converter（模数转换器） |
| API | Application Programming Interface（应用程序接口） |
| DEM | Diagnostic Event Manager（诊断事件管理器） |
| DET | Default Error Tracer（默认错误跟踪器） |
| HW | Hardware（硬件） |
| MCU | Microcontroller Unit（微控制器单元） |
| SW | Software（软件） |
| PWM | Pulse Width Modulation（脉宽调制） |
| EcuM | ECU State Manager（ECU 状态管理器） |
| COM | Communication（通信） |
**关键术语**
| 术语 | 描述 |
|---|---|
| **ADC HW Unit** | 表示微控制器输入电子设备，包括执行"模数转换"所需的所有部件 |
| **ADC Module** | ADC 基础软件模块 ADC 驱动，也缩写为 ADC Driver |
| **ADC Channel** | 表示绑定到一个端口引脚的逻辑 ADC 实体。多个 ADC 实体可以映射到同一个端口引脚 |
| **ADC Channel Group** | 链接到同一 ADC 硬件单元的 ADC 通道组（例如一个 Sample&Hold 和一个 A/D 转换器）。整个组的转换由一个触发源触发 |
| **ADC Result Buffer** | ADC 驱动用户必须为每个组提供一个缓冲区。如果选择流访问模式，此缓冲区可保存同一组通道的多个样本。如果选择单次访问模式，缓冲区中保存每个组通道的一个样本 |
| **Software Trigger** | 启动一个 ADC 通道组或 ADC 通道组连续转换序列的软件 API 调用 |
| **Hardware Trigger** | ADC 内部触发信号，启动一个 ADC 通道组的转换。ADC 硬件触发在 ADC 硬件内部生成，例如基于 ADC 定时器或触发边沿信号。触发硬件与 ADC 硬件紧密耦合或集成。检测到硬件触发后不需要软件启动 ADC 通道组转换 |
| **Conversion Mode - One-Shot** | 在触发后执行一次 ADC 通道组的转换，结果写入分配的结果缓冲区。触发可以是软件 API 调用或硬件事件 |
| **Conversion Mode - Continuous** | 在软件 API 调用（启动）后连续执行 ADC 通道组的转换，结果写入分配的结果缓冲区。转换本身自动运行（硬件/中断控制）。连续转换可以通过软件 API 调用（停止）停止 |
| **Sampling Time** | 模拟值被采样的时间（例如加载电容器） |
| **Conversion Time** | 采样的模拟值转换为数字表示的时间 |
| **Acquisition Time** | Sample Time + Conversion Time |
---
## 3 相关文档
### 3.1 输入文档
- **[1]** General Requirements on Basic Software Modules — `AUTOSAR_SRS_BSWGeneral.pdf`
- **[2]** General Requirements on SPAL — `AUTOSAR_SRS_SPALGeneral.pdf`
- **[3]** Specification of Standard Types — `AUTOSAR_SWS_StandardTypes.pdf`
- **[4]** List of Basic Software Modules — `AUTOSAR_TR_BSWModuleList.pdf`
- **[5]** Specification of Diagnostic Event Manager — `AUTOSAR_SWS_DiagnosticEventManager.pdf`
- **[6]** Specification of Default Error Tracer — `AUTOSAR_SWS_DefaultErrorTracer.pdf`
- **[7]** Requirements on ADC Driver — `AUTOSAR_SRS_ADCDriver.pdf`
- **[8]** Specification of ECU Configuration — `AUTOSAR_TPS_ECUConfiguration.pdf`
- **[9]** Layered Software Architecture — `AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf`
- **[10]** Specification of ECU State Manager — `AUTOSAR_SWS_ECUStateManager.pdf`
- **[11]** Specification of I/O Hardware Abststraction — `AUTOSAR_SWS_IOHardwareAbstraction.pdf`
- **[12]** Basic Software Module Description Template — `AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf`
- **[13]** General Specification of Basic Software Modules — `AUTOSAR_SWS_BSWGeneral.pdf`
### 3.2 相关规范
AUTOSAR 提供了关于基础软件模块的通用规范 [13]（SWS BSW General），该规范对 ADC 驱动同样有效。因此，SWS BSW General 应被视为 ADC 驱动的附加且必需的规范。
---
## 4 约束与假设
### 4.1 限制
**功耗状态控制 API 仅在 MCAL 驱动拥有完整底层硬件外设（即硬件外设未被其他 MCAL 模块访问）时可实现。**
### 4.2 对汽车领域的适用性
**无限制**。
---
## 5 与其他模块的依赖关系
### 模块 MCU 驱动
微控制器单元驱动（MCU 驱动）主要负责初始化和控制芯片的内部时钟源和时钟预分频器。**时钟频率可能影响**：
- 触发频率
- 转换时间
- 采样时间
### 模块 PORT 驱动
**PORT 模块应配置 ADC 模块使用的端口引脚**。必须同时考虑模拟输入引脚和外部触发引脚。
---
## 6 需求可追溯性
> **翻译说明**：本节包含一个大型参考表，将 SRS 需求映射到 SWS 需求（涉及 `SRS_Adc_xxxxx` 和 `SRS_BSW_xxxxx`、`SRS_SPAL_xxxxx`）。下表列出前 10 行代表性映射；完整表（包含约 100+ 项映射）请参见原文 PDF 第 16-23 页。
| 需求 | 描述 | 由以下需求满足 |
|---|---|---|
| `SRS_Adc_12280` | ADC 驱动应允许为每个 ADC 通道组配置特定的结果访问模式 | `SWS_Adc_00140`, `SWS_Adc_00382`, `SWS_Adc_00383` |
| `SRS_Adc_12283` | ADC 驱动应屏蔽掉转换结果中不属于 ADC 值的信息位 | `SWS_Adc_00122` |
| `SRS_Adc_12291` | ADC 驱动应提供查询 ADC 通道组状态的服务 | `SWS_Adc_00219`, `SWS_Adc_00220`, `SWS_Adc_00221`, `SWS_Adc_00222`, `SWS_Adc_00224` |
| `SRS_Adc_12292` | 如果 ADC 提供有符号值，ADC 驱动应将符号位放入返回值的 MSB | `SWS_Adc_00113`, `SWS_Adc_00214` |
| `SRS_Adc_12307` | ADC 驱动应支持每个通道的特定基本静态配置 | `SWS_Adc_00099` |
| `SRS_Adc_12317` | ADC 驱动应提供通知函数以通知调用者通道组转换结束 | `SWS_Adc_00104`, `SWS_Adc_00155`, `SWS_Adc_00156`, `SWS_Adc_00157` |
| `SRS_Adc_12318` | ADC 驱动应提供单独启用和禁用每个通知函数的服务 | `SWS_Adc_00057`, `SWS_Adc_00058`, `SWS_Adc_00077`, `SWS_Adc_00156`, `SWS_Adc_00157` |
| `SRS_Adc_12364` | ADC 驱动应为所有转换模式提供启动和停止 ADC 通道组转换的服务 | `SWS_Adc_00060`, `SWS_Adc_00061`, `SWS_Adc_00145` |
| `SRS_Adc_12447` | ADC 驱动应允许对属于同一 ADC 硬件单元的 ADC 通道进行分组 | `SWS_Adc_00090`, `SWS_Adc_00091`, `SWS_Adc_00098` |
| `SRS_Adc_12802` | ADC 驱动应为流访问模式提供识别最新样本和可用样本数的服务 | `SWS_Adc_00214`, `SWS_Adc_00216`, `SWS_Adc_00219` |
> **摘要标记**：本表共约 100+ 行；上表列出前 10 行代表性映射。完整表涵盖 `SRS_Adc_12280` 至 `SRS_Adc_12825`、`SRS_BSW_00005` 至 `SRS_BSW_00433`、`SRS_SPAL_00157` 至 `SRS_SPAL_12463`，详情见原文 PDF。
---
## 7 功能规范
### 7.1 通用行为
#### 7.1.1 背景与基本原理
ADC 驱动提供以下核心服务：
- **转换控制**：启动、停止转换
- **触发管理**：启用、禁用硬件/软件触发
- **通知机制**：转换完成时通知调用者
- **结果访问**：单次访问模式、流访问模式
- **状态查询**：查询通道组状态
#### 7.1.2 需求
**结果访问模式**
> **[SWS_Adc_00140]** ⌈ADC 模块应保证每个已完成的转换的返回结果值的一致性。⌋（`SRS_Adc_12280`）
> **[SWS_Adc_00382]** ⌈ADC 模块应支持使用 API 函数 `Adc_GetStreamLastPointer` 的结果访问。调用 `Adc_GetStreamLastPointer` 返回一个指向应用缓冲区的指针，指向最新完成转换轮次的组通道结果。⌋（`SRS_Adc_12280`）
> **[SWS_Adc_00383]** ⌈如果静态配置生成了 `Adc_ReadGroup` API 函数，ADC 模块应支持使用该函数的结果访问。调用 `Adc_ReadGroup` 将最新转换轮次的组转换结果复制到作为 API 参数指定的应用缓冲区起始地址。⌋（`SRS_Adc_12280`）
> **注意**：此函数用于流访问模式和单次访问模式配置的两种组类型（单次访问模式的处理方式与 Streaming Counter 等于 1 的流访问模式相同）。
**优先级机制**
> **[SWS_Adc_00288]** ⌈ADC 模块应允许为每个通道组配置优先级。⌋（`SRS_Adc_12820`）
> **[SWS_Adc_00310]** ⌈ADC 模块的优先级机制应允许中止和重新启动通道组转换。⌋（`SRS_Adc_12820`）
> **[SWS_Adc_00345]** ⌈ADC 模块的优先级机制应允许挂起和恢复通道组转换。⌋
> **[SWS_Adc_00430]** ⌈ADC 模块应允许组特定配置，确定对被中断的通道组使用中止/重新启动还是挂起/恢复机制。⌋
> **[SWS_Adc_00311]** ⌈ADC 模块的优先级机制应允许对不同组的请求进行排队。⌋
> **[SWS_Adc_00312]** ⌈在 ADC 模块的优先级机制中，最低优先级为 0。⌋
> **[SWS_Adc_00289]** ⌈ADC 模块的优先级机制应允许配置 256 个优先级（0...255）。⌋（`SRS_Adc_12820`）
> **[SWS_Adc_00315]** ⌈ADC 模块应支持禁用优先级机制的静态配置选项。⌋
> **[SWS_Adc_00340]** ⌈ADC 模块应支持启用优先级机制 `ADC_PRIORITY_HW_SW` 的静态配置选项，使用硬件和软件优先级机制。如果硬件不提供硬件优先级机制，则应实现纯软件优先级机制。⌋（`SRS_Adc_12820`）
> **[SWS_Adc_00341]** ⌈如果优先级机制由硬件支持：ADC 模块应支持静态配置选项 `ADC_PRIORITY_HW`，仅使用硬件优先级机制启用优先级机制。⌋（`SRS_Adc_12820`）
> **[SWS_Adc_00332]** ⌈如果优先级机制处于活动状态，ADC 模块应支持转换请求排队。当以下情况时，转换请求应排队：
> - 如果在低优先级通道组转换进行中请求具有较高优先级的通道组转换（较低优先级组应排队），或者
> - 由于较高优先级通道组转换正在进行，通道组转换请求不能立即处理。⌋
> **[SWS_Adc_00417]** ⌈如果优先级机制处于活动状态，ADC 模块应按"先到先服务"顺序处理相同优先级组的通道组转换请求。⌋
**通知机制**
> **[SWS_Adc_00060]** ⌈当请求组的所有通道转换完成时，如果通知已配置并启用，ADC 模块应调用组通知函数。⌋（`SRS_Adc_12364`）
**限制检查**
> **[SWS_Adc_00445]** ⌈ADC 模块应允许为 ADC 通道配置限制检查。⌋
> **[SWS_Adc_00446]** ⌈如果 ADC 通道的限制检查处于活动状态，则只有处于配置范围内的 ADC 转换结果才被考虑用于更新用户指定的 ADC 结果缓冲区。⌋
> **[SWS_Adc_00447]** ⌈如果 ADC 通道的限制检查处于活动状态，则只有处于配置范围内的 ADC 转换结果才被考虑用于触发 ADC 组状态的状态转换。⌋
**可重入性**
> **[SWS_Adc_00413]** ⌈如果为不同的通道组调用 API 函数，ADC 模块函数应是可重入的。此要求应适用于所有 API 函数，**除了** `Adc_Init`、`Adc_DeInit`、`Adc_GetVersionInfo`、`Adc_SetPowerState`、`Adc_GetTargetPowerState`、`Adc_GetCurrentPowerState` 和 `Adc_PreparePowerState`。⌋
> **[SWS_Adc_00503]** ⌈简单读取调用（如 `Adc_ReadGroup` 和 `Adc_GetGroupStatus` 中实现的）即使为同一通道组调用也应始终是可重入的。实现可使用适当的保护机制（例如禁用/启用中断）。⌋
#### 7.1.3 ADC 缓冲区访问模式示例
**示例配置**：
示例配置由三个 ADC 组组成：
- **组 1**：包含 2 个通道，组访问模式 `ADC_ACCESS_MODE_STREAMING`
- **组 2**：包含 1 个通道，组访问模式 `ADC_ACCESS_MODE_STREAMING`
- **组 3**：包含 1 个通道，组访问模式 `ADC_ACCESS_MODE_SINGLE`
ADC 驱动将组 1-3 的转换结果存储在三个应用缓冲区中，通过三个配置的 `ADC_RESULT_POINTER` 访问：`G1_ResultPtr`、`G2_ResultPtr` 和 `G3_ResultPtr`。
**初始化**：
用户必须为 ADC 组结果提供应用结果缓冲区。每个组需要一个缓冲区。缓冲区大小取决于组通道数、组访问模式以及流采样数（如果选择了流访问模式）。在启动组转换之前，用户必须使用 API 函数 `Adc_SetupResultBuffer` 初始化组结果指针，该函数将组结果指针初始化为指向指定的应用结果缓冲区。
**`Adc_GetStreamLastPointer` 使用**：
ADC 驱动将组 G1、G2 和 G3 的转换结果存储在相应的结果缓冲区 `G1_ResultBuffer[]`、`G2_ResultBuffer[]` 和 `G3_ResultBuffer[]` 中。ADC API 函数对 ADC 硬件结果寄存器的直接访问不受 ADC 驱动支持。
用户提供三个指针 `G1_SamplePtr`、`G2_SamplePtr` 和 `G3_SamplePtr`，在调用 `Adc_GetStreamLastPointer` 后将指向 ADC 应用结果缓冲区。准确地说，在调用 `Adc_GetStreamLastPointer` 后，指针 `G1_SamplePtr` 指向最新完成转换轮次的最新 G1_CH0 结果（G1_CH0 是 G1 组定义中的第一个通道）。
`Adc_GetStreamLastPointer` 返回存储在应用结果缓冲区中的每个通道的有效样本数（完整组转换轮次数）。如果返回值等于配置的"流采样数"参数，则流缓冲区中的所有转换结果都有效。如果返回值为 0，则流缓冲区中没有可用的转换结果（样本指针对齐为 NULL）。
**`Adc_ReadGroup` 使用**：
如果启用了可选的 API 函数 `Adc_ReadGroup`，用户必须为选定的组提供额外的缓冲区，这些缓冲区可以保存一个组转换轮次的结果。调用 `Adc_ReadGroup` 将最新结果从应用结果缓冲区复制到应用读组缓冲区。
### 7.2 转换处理与交互
#### 7.2.1 背景与基本原理
以下示例说明了根据组和转换类型的通道转换顺序：
**示例 1**：包含通道 [CH0, CH1, CH2, CH3, CH4] 的通道组配置为连续转换模式。每次扫描完成后调用通知（如果启用）。然后自动开始新的扫描。
**示例 2**：包含通道 [CH0, CH1, CH2, CH3, CH4] 的通道组配置为 One-Shot 转换模式。扫描完成后调用通知（如果启用）。
**示例 3**：包含通道 [CH3] 的通道组配置为连续转换模式。每次扫描完成后调用通知（如果启用）。然后自动开始新的扫描。
**示例 4**：包含通道 [CH4] 的通道组配置为 One-Shot 转换模式。扫描完成后调用通知（如果启用）。
#### 7.2.2 需求
> **[SWS_Adc_00280]** ⌈ADC 模块每次应在每个 ADC 硬件单元上只转换一个 ADC 通道组。ADC 模块不应支持在同一 ADC 硬件单元上同时转换不同的（即使是独占的）ADC 通道组。⌋（`SRS_Adc_12447`）
> **注意**：根据硬件能力，不同 ADC 硬件单元上的 ADC 通道组的同时转换是可能的。如果硬件支持，一个通道组内的各个通道的同时转换也是可能的。
### 7.3 状态图
ADC 模块具有一个状态机，如下图所示。状态是组特定的，不是模块特定的。状态图显示了 ADC 组的所有可能配置选项。状态转换取决于 ADC 组的配置。
#### 7.3.1 One-Shot/Continuous 组转换模式的 ADC 状态图
主要状态：
- **`ADC_UNINIT`**：未初始化状态
- **`ADC_INIT`**：已初始化状态
- **`ONE-SHOT`**：One-Shot 转换模式（配置选项）
- **`CONTINUOUS`**：连续转换模式（配置选项）
**关键转换**：
- `Reset` → `ADC_UNINIT`
- `Adc_Init` → `ADC_INIT`
- `Adc_DeInit` → `ADC_UNINIT`
- 在配置时根据 `ONE_SHOT` 或 `CONTINUOUS` 选择进入相应模式
#### 7.3.2-7.3.8 其他状态图
> **摘要标记**：本节包含 8 个详细的 ADC 状态图（One-Shot/Continuous 配置、HW/SW 触发、单次/流访问模式等组合），每个图描述特定配置下的状态转换。完整状态图和详细说明见原文 PDF 第 37-44 页。
### 7.4 硬件低功耗状态的支持和管理
#### 7.4.1 背景
ADC 模块应支持 MCU 的低功耗状态。这通过 `Adc_SetPowerState`、`Adc_GetCurrentPowerState`、`Adc_GetTargetPowerState` 和 `Adc_PreparePowerState` 等 API 实现。
#### 7.4.2 需求
> **[SWS_Adc_00391]** ⌈ADC 模块应支持定义多个功耗状态。⌋
> **[SWS_Adc_00465]** ⌈`Adc_SetPowerState()` 应在转换完成时进入目标功耗状态。⌋
### 7.5 版本检查
> **翻译说明**：版本检查遵循 `SWS_BSWGeneral` 的规定（第 5.1.8 节），ADC 模块对所有导入的头文件进行版本检查。
### 7.6 错误检测
#### 7.6.1 开发错误
| 错误类型 | 相关错误代码 | 值 [十六进制] |
|---|---|---|
| API 服务调用时模块未初始化 | `ADC_E_UNINIT` | `0x0A` |
| API 服务调用时参数错误 | `ADC_E_PARAM_CONFIG` | `0x0B` |
| API 服务调用时指针参数错误 | `ADC_E_PARAM_POINTER` | `0x0C` |
| API 服务调用时参数超出范围 | `ADC_E_PARAM_GROUP` | `0x0D` |
| ADC 缓冲区未初始化 | `ADC_E_BUFFER_UNINIT` | `0x0E` |
| API 调用时 ADC 已初始化 | `ADC_E_ALREADY_INITIALIZED` | `0x0F` |
| API 调用时 ADC 忙 | `ADC_E_BUSY` | `0x10` |
| API 调用时 ADC 空闲（无法停止） | `ADC_E_IDLE` | `0x11` |
#### 7.6.2 运行时错误
| 错误类型 | 相关错误代码 | 值 [十六进制] |
|---|---|---|
| ADC 未启动 | `ADC_E_NOT_STARTED` | `0x12` |
| ADC 硬件故障 | `ADC_E_HW_FAILURE` | `0x13` |
#### 7.6.3 瞬态故障
无。
---
## 8 API 规范
### 8.1 导入类型
```c
#include "Std_Types.h"
#include "Adc_Types.h"
```
### 8.2 类型定义
#### 8.2.1 Adc_ConfigType
```c
/* ADC 配置结构体的前向声明 */
typedef struct Adc_ConfigType_s Adc_ConfigType;
```
#### 8.2.2 Adc_ChannelType
```c
/* ADC 通道 ID 的类型 */
typedef uint16 Adc_ChannelType;
```
#### 8.2.3 Adc_GroupType
```c
/* ADC 通道组 ID 的类型 */
typedef uint16 Adc_GroupType;
```
#### 8.2.4 Adc_ValueGroupType
```c
/* ADC 转换结果值的类型 */
typedef uint16 Adc_ValueGroupType;
```
#### 8.2.5 Adc_PrescaleType
```c
/* ADC 时钟预分频器值的类型 */
typedef uint32 Adc_PrescaleType;
```
#### 8.2.6 Adc_ConversionTimeType
```c
/* ADC 转换时间的类型 */
typedef uint16 Adc_ConversionTimeType;
```
#### 8.2.7 Adc_SamplingTimeType
```c
/* ADC 采样时间的类型 */
typedef uint16 Adc_SamplingTimeType;
```
#### 8.2.8 Adc_ResolutionType
```c
/* ADC 分辨率（位数）的类型 */
typedef uint8 Adc_ResolutionType;
```
#### 8.2.9 Adc_StatusType
```c
/* ADC 状态枚举 */
typedef enum {
ADC_IDLE,
ADC_BUSY,
ADC_COMPLETED,
ADC_STREAM_COMPLETED
} Adc_StatusType;
```
#### 8.2.10 Adc_TriggerSourceType
```c
/* ADC 触发源枚举 */
typedef enum {
ADC_TRIGG_SRC_SW,
ADC_TRIGG_SRC_HW
} Adc_TriggerSourceType;
```
#### 8.2.11 Adc_GroupConvModeType
```c
/* ADC 组转换模式 */
typedef enum {
ADC_CONV_MODE_ONESHOT,
ADC_CONV_MODE_CONTINUOUS
} Adc_GroupConvModeType;
```
#### 8.2.12 Adc_GroupPriorityType
```c
/* ADC 组优先级类型 */
typedef uint16 Adc_GroupPriorityType;
```
#### 8.2.13 Adc_GroupDefType
```c
/* ADC 组定义类型 */
typedef struct {
Adc_GroupType GroupId;
Adc_GroupConvModeType ConvMode;
Adc_TriggerSourceType TriggerSource;
Adc_GroupPriorityType Priority;
Adc_GroupAccessModeType AccessMode;
} Adc_GroupDefType;
```
#### 8.2.14 Adc_StreamNumSampleType
```c
/* ADC 流采样数类型 */
typedef uint8 Adc_StreamNumSampleType;
```
#### 8.2.15 Adc_StreamBufferModeType
```c
/* ADC 流缓冲区模式 */
typedef enum {
ADC_STREAM_BUFFER_LINEAR,
ADC_STREAM_BUFFER_CIRCULAR
} Adc_StreamBufferModeType;
```
#### 8.2.16 Adc_GroupAccessModeType
```c
/* ADC 组访问模式 */
typedef enum {
ADC_ACCESS_MODE_SINGLE,
ADC_ACCESS_MODE_STREAMING
} Adc_GroupAccessModeType;
```
#### 8.2.17 Adc_HwTriggerSignalType
```c
/* ADC 硬件触发信号类型 */
typedef enum {
ADC_HW_TRIG_RISING_EDGE,
ADC_HW_TRIG_FALLING_EDGE,
ADC_HW_TRIG_BOTH_EDGES
} Adc_HwTriggerSignalType;
```
#### 8.2.18-8.2.24 其他类型
> **摘要标记**：8.2.18-8.2.24 节定义其他类型（`Adc_HwTriggerTimerType`、`Adc_PriorityImplementationType`、`Adc_GroupReplacementType`、`Adc_ChannelRangeSelectType`、`Adc_ResultAlignmentType`、`Adc_PowerStateType`、`Adc_PowerStateRequestResultType`）。完整定义见原文 PDF 第 60-61 页。
### 8.3 函数定义
#### 8.3.1 Adc_Init
```c
/**
* 初始化 ADC 驱动
* @param ConfigPtr 指向配置的指针
*/
void Adc_Init(const Adc_ConfigType* ConfigPtr);
```
> **[SWS_Adc_00054]** ⌈`Adc_Init()` 应初始化所有 ADC 硬件单元和通道组。⌋
#### 8.3.2 Adc_SetupResultBuffer
```c
/**
* 设置 ADC 通道组的结果缓冲区
* @param Group 组 ID
* @param DataBufferPtr 指向结果缓冲区的指针
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType Adc_SetupResultBuffer(Adc_GroupType Group, Adc_ValueGroupType* DataBufferPtr);
```
> **[SWS_Adc_00056]** ⌈`Adc_SetupResultBuffer()` 应初始化指定组的结果缓冲区指针。⌋
#### 8.3.3 Adc_DeInit
```c
/**
* 反初始化 ADC 驱动
*/
void Adc_DeInit(void);
```
> **[SWS_Adc_00057]** ⌈`Adc_DeInit()` 应将所有 ADC 硬件单元返回到未初始化状态。⌋
#### 8.3.4 Adc_StartGroupConversion
```c
/**
* 启动 ADC 通道组的转换
* @param Group 组 ID
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType Adc_StartGroupConversion(Adc_GroupType Group);
```
> **[SWS_Adc_00060]** ⌈`Adc_StartGroupConversion()` 应启动指定组的转换。⌋
#### 8.3.5 Adc_StopGroupConversion
```c
/**
* 停止 ADC 通道组的转换
* @param Group 组 ID
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType Adc_StopGroupConversion(Adc_GroupType Group);
```
#### 8.3.6 Adc_ReadGroup
```c
/**
* 读取 ADC 通道组的转换结果
* @param Group 组 ID
* @param DataBufferPtr 指向读缓冲区的指针
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType Adc_ReadGroup(Adc_GroupType Group, Adc_ValueGroupType* DataBufferPtr);
```
#### 8.3.7 Adc_EnableHardwareTrigger
```c
/**
* 启用 ADC 通道组的硬件触发
* @param Group 组 ID
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType Adc_EnableHardwareTrigger(Adc_GroupType Group);
```
#### 8.3.8 Adc_DisableHardwareTrigger
```c
/**
* 禁用 ADC 通道组的硬件触发
* @param Group 组 ID
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType Adc_DisableHardwareTrigger(Adc_GroupType Group);
```
#### 8.3.9 Adc_EnableGroupNotification
```c
/**
* 启用 ADC 通道组的完成通知
* @param Group 组 ID
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType Adc_EnableGroupNotification(Adc_GroupType Group);
```
#### 8.3.10 Adc_DisableGroupNotification
```c
/**
* 禁用 ADC 通道组的完成通知
* @param Group 组 ID
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType Adc_DisableGroupNotification(Adc_GroupType Group);
```
#### 8.3.11 Adc_GetGroupStatus
```c
/**
* 获取 ADC 通道组的状态
* @param Group 组 ID
* @return 状态值
*/
Adc_StatusType Adc_GetGroupStatus(Adc_GroupType Group);
```
#### 8.3.12 Adc_GetStreamLastPointer
```c
/**
* 获取流缓冲区的最新指针
* @param Group 组 ID
* @param PtrToSamplePtr 指向样本指针的指针
* @return 已完成的样本数
*/
Adc_StreamNumSampleType Adc_GetStreamLastPointer(Adc_GroupType Group, Adc_ValueGroupType** PtrToSamplePtr);
```
#### 8.3.13 Adc_GetVersionInfo
```c
/**
* 获取 ADC 驱动的版本信息
* @param versioninfo 指向版本信息结构体的指针
*/
void Adc_GetVersionInfo(Std_VersionInfoType* versioninfo);
```
#### 8.3.14 Adc_SetPowerState
```c
/**
* 设置 ADC 硬件单元的功耗状态
* @param PowerState 目标功耗状态
* @param Result 指向结果代码的指针
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType Adc_SetPowerState(Adc_PowerStateType PowerState, Adc_PowerStateRequestResultType* Result);
```
#### 8.3.15 Adc_GetCurrentPowerState
```c
/**
* 获取 ADC 硬件单元的当前功耗状态
* @param PowerState 指向当前功耗状态的指针
* @param Result 指向结果代码的指针
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType Adc_GetCurrentPowerState(Adc_PowerStateType* PowerState, Adc_PowerStateRequestResultType* Result);
```
#### 8.3.16 Adc_GetTargetPowerState
```c
/**
* 获取 ADC 硬件单元的目标功耗状态
* @param PowerState 指向目标功耗状态的指针
* @param Result 指向结果代码的指针
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType Adc_GetTargetPowerState(Adc_PowerStateType* PowerState, Adc_PowerStateRequestResultType* Result);
```
#### 8.3.17 Adc_PreparePowerState
```c
/**
* 准备 ADC 硬件单元的功耗状态转换
* @param PowerState 目标功耗状态
* @param Result 指向结果代码的指针
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType Adc_PreparePowerState(Adc_PowerStateType PowerState, Adc_PowerStateRequestResultType* Result);
```
### 8.4 回调通知
```c
/**
* ADC 转换完成通知回调
* @param Group 完成转换的组 ID
*/
typedef void (*Adc_NotificationCallbackType)(Adc_GroupType Group);
```
### 8.5 调度函数
#### 8.5.1 Adc_Main_PowerTransitionManager
```c
/**
* ADC 驱动的功耗状态转换管理器主函数
*/
void Adc_Main_PowerTransitionManager(void);
```
> **摘要标记**：8.5 节描述 ADC 主处理函数 `Adc_MainFunction`（未列出）和 `Adc_Main_PowerTransitionManager`。完整规范见原文 PDF 第 90 页。
### 8.6 预期接口
#### 8.6.1 强制接口
| API | 头文件 | 描述 |
|---|---|---|
| `Det_ReportError` | `Det.h` | 报告开发错误 |
| `Mcu_GetClockState` | `Mcu.h` | 获取时钟状态 |
#### 8.6.2 可选接口
| API | 头文件 | 描述 |
|---|---|---|
| `Dem_ReportErrorStatus` | `Dem.h` | 报告 DEM 错误 |
| `Port_SetPinMode` | `Port.h` | 设置引脚模式 |
#### 8.6.3 可配置接口
| API | 头文件 | 描述 |
|---|---|---|
| `Adc_Notification_<Group>` | 用户定义 | 通道组完成通知 |
---
## 9 序列图
### 9.1 ADC 驱动初始化
初始化序列：`EcuM` → `Adc_Init()` → 配置 ADC 硬件单元 → 完成。
### 9.2 ADC 驱动反初始化
反初始化序列：`Adc_DeInit()` → 停止所有转换 → 复位硬件 → 完成。
### 9.3 软件触发的 One-Shot 转换（无通知）
```
应用层 → Adc_StartGroupConversion() → ADC 驱动启动转换
↓
硬件完成转换
↓
应用层 → Adc_GetGroupStatus() → 查询状态（ADC_COMPLETED）
↓
应用层 → Adc_ReadGroup() → 读取结果
```
### 9.4 软件触发的连续转换（带通知）
```
应用层 → Adc_StartGroupConversion() → ADC 驱动启动连续转换
↓
硬件周期性完成转换
↓
调用通知回调
↓
应用层 → Adc_ReadGroup() → 读取结果
↓
应用层 → Adc_StopGroupConversion() → 停止转换
```
> **摘要标记**：本节包含 11 个详细的序列图（9.1-9.11），涵盖初始化、反初始化、SW/HW 触发转换、单次/流访问模式、优先级机制、队列等场景。完整序列图见原文 PDF 第 95-104 页。
---
## 10 配置规范
### 10.1 如何阅读本章
本章描述 ADC 驱动的 ECUC 配置。完整的 ECUC 参数定义见原文 PDF。
### 10.2 配置与配置参数
#### 10.2.1 Adc（顶层容器）
- 标识符：`Adc`
- 描述：ADC 驱动配置顶层容器
#### 10.2.2 AdcGeneral
主要配置参数：
| 参数 | 类型 | 范围 | 描述 |
|---|---|---|---|
| `AdcDevErrorDetect` | Boolean | TRUE/FALSE | 启用开发错误检测 |
| `AdcInitDeInitApi` | Boolean | TRUE/FALSE | 启用 Adc_DeInit API |
| `AdcLimitCheckApi` | Boolean | TRUE/FALSE | 启用限制检查 API |
| `AdcReadGroupApi` | Boolean | TRUE/FALSE | 启用 Adc_ReadGroup API |
| `AdcPowerStateAsynchTransitionMode` | Boolean | TRUE/FALSE | 异步功耗状态转换模式 |
| `AdcVersionInfoApi` | Boolean | TRUE/FALSE | 启用版本信息 API |
#### 10.2.3 AdcPowerStateConfig
- 描述：功耗状态配置
- 多重性：0..1
#### 10.2.4 AdcConfigSet
- 描述：配置集
- 多重性：1
#### 10.2.5 AdcChannel
- 描述：ADC 通道配置
- 多重性：1..256
#### 10.2.6 AdcGroup
- 描述：ADC 通道组配置
- 多重性：1..256
#### 10.2.7 AdcHwUnit
- 描述：ADC 硬件单元配置
- 多重性：1..16
> **摘要标记**：10.2 节详细描述 ADC 驱动的所有配置容器和参数（约 100+ 参数）。完整 ECUC 定义见原文 PDF 第 107-125 页。
### 10.3 已发布信息
#### 10.3.1 AdcPublishedInformation
| 参数 | 类型 | 描述 |
|---|---|---|
| `AdcController0Id` | Integer | 控制器 0 ID |
| `AdcPublishedSymbols` | String | 已发布符号 |
### 10.4 符号名称配置
无。
---
## 11 不适用的需求
无。
---
## 翻译说明
本文档为 AUTOSAR SWS ADCDriver（文档 ID 010，129 页，4.4.0 版）的中文翻译。翻译策略：
1. **完整翻译**：封面、文档标识、变更历史、目录、前 6 个核心章节（引言、缩写、相关文档、约束、依赖、需求可追溯性）、所有主要 API 规范
2. **核心概念涵盖**：
- **模数转换**：逐次逼近型 ADC 硬件（Delta Sigma 排除）
- **转换组**：ADC Channel Group 与 ADC Channel 关系
- **转换模式**：One-Shot（单次）/ Continuous（连续）
- **触发源**：Software Trigger / Hardware Trigger
- **结果访问模式**：Single Access / Streaming Access
- **优先级机制**：硬件优先级、软件优先级、混合优先级
- **限制检查**：ADC 通道限制范围
3. **摘要处理**：
- 需求可追溯性表：列出前 10 行代表性映射，完整表（100+ 行）见原文 PDF
- 状态图（7.3 节）：列出主要状态和关键转换，8 个详细状态图见原文 PDF
- 序列图（9 节）：列出主要流程描述，11 个详细序列图见原文 PDF
- 配置规范（10.2 节）：列出主要容器，详细 ECUC 定义见原文 PDF
4. **保留内容**：所有 API 标识符、需求 ID（`SWS_Adc_xxxxx`、`SRS_Adc_xxxxx`、`SRS_BSW_xxxxx`、`SRS_SPAL_xxxxx`）、AUTOSAR 方框符 `⌈⌋`、文档间交叉引用
本文档介绍了 ADC 驱动——AUTOSAR 微控制器抽象层（MCAL）的基础软件模块，提供模数转换的控制、触发管理、通知机制和结果访问服务。
IO/AUTOSAR_SWS_DIODriver.md
+1265
View File
File diff suppressed because it is too large Load Diff
IO/AUTOSAR_SWS_ICUDriver.md
+916
View File
@@ -0,0 +1,916 @@
# ICU 驱动规范（Specification of ICU Driver）
| 字段 | 内容 |
|---|---|
| **文档标题** | ICU 驱动规范（Specification of ICU Driver） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 023 |
| **文档状态** | Final（正式发布） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
---
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | MCAL 多核分布（草案）；头文件清理 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 移除 `SWS_Icu_00116` 和 `SWS_Icu_00190`；将 `SRS_BSW_00450` 添加到不适用的需求列表；将"default error"重命名为"development error"；`SWS_Icu_00201`：`Icu_StartTimestamp` 的参数 `(IN): Icu_ValueType* BufferPtr` 更改为 `(out)` 类型；将 `ICU_E_NOT_STARTED` 从开发错误变更为运行时错误；编辑性变更 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 移除第 10.2.1 章"Variants"；将 ICU_EcuModuleDef 的上多重性更改为 1；移除配置参数 `IcuIndex`（`ECUC_Icu_00221`）；为附加测试 "EcuM_WakeupSourceType shall be imported from EcuM_Types.h" 提供需求 ID `SWS_Icu_00383`；移除需求 `SWS_Icu_00346`；编辑性变更 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 编辑性变更；DET 从"Development Error Tracer"重命名为"Default Error Tracer"；从文档中移除对过时的 `SWS_Icu_00048` 的所有引用 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | `IcuChannelId`：`postBuildVariantValue` 设置为 false；移除关于 `Icu_Init()` 的 NULL_PTR 检查的 SWS ID；将 `ICU_E_PARAM_POINTER` 和 `ICU_E_INIT_FAILED` 添加到错误分类；移除 `ICU_E_PARAM_CONFIG` 和 `ICU_E_PARAM_BUFFER_PTR` |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | ICU00354 - 检查有效通知间隔的重新表述；ICU078 - 从注意事项中删除句子"This is done by the hardware."；ICU295 - 从枚举 `Icu_SignalMeasurementPropertyType` 的范围中移除 `ICU_ACTIVE_TIME`；编辑性变更；删除变更文档章节 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 将参数范围从 ECU/Module 修改为 local；根据新的 SWS_BSWGeneral 重新修订；将 `MemMap.h` 更改为 `Icu_MemMap.h` |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 修正类型错误；更新 `Icu_IndexType` 的描述 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 新增服务 `Icu_DisableEdgeDetection` 和 `Icu_EnableEdgeDetection`；新增配置参数 `IcuEdgeDetectApi` 和 `IcuWakeupFunctionalityApi`；修正'duty cycle'的定义；修正参数 `Icu_SignalMeasurementPropertyType` 的值 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律声明修订 |
| 2008-02-01 | 3.0.2 | AUTOSAR Administration | 重新处理模块的代码文件结构；新增需求 `SWS_Icu_00088`、`SWS_Icu_00220`、`SWS_Icu_00221`、`SWS_Icu_00228` 和 `SWS_Icu_00229`；与 ECU 唤醒相关的流程图移至 ECU 状态管理器的 SWS 文档；扩展文档元信息；小幅布局调整 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 默认启动边现在用于边沿配置；启用和禁用通知现在可用于时间戳功能；边沿检测功能现在在预编译时可配置 On/Off；法律声明修订；新增发布说明；"Advice for users"修订；"Revision Information"新增 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 新增服务：`Icu_SetActivationCondition`、`Icu_StartTimeStamp`、`Icu_StopTimeStamp`、`Icu_GetTimestampIndex`、`Icu_ResetEdgeCount`、`Icu_EnableEdgeCount`、`Icu_DisableEdgeCount`、`Icu_GetEdgeNumbers`、`Icu_GetTimeElapsed`、`Icu_GetDutyCycleValues`、`Icu_GetVersionInfo` |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 初始发布 |
---
## 目录（Table of Contents）
1. [引言与功能概述](#1-引言与功能概述)
2. [缩略语与缩写](#2-缩略语与缩写)
3. [相关文档](#3-相关文档)
4. [约束与假设](#4-约束与假设)
5. [与其他模块的依赖关系](#5-与其他模块的依赖关系)
6. [需求可追溯性](#6-需求可追溯性)
7. [功能规范](#7-功能规范)
8. [API 规范](#8-api-规范)
9. [序列图](#9-序列图)
10. [配置规范](#10-配置规范)
11. [不适用的需求](#11-不适用的需求)
---
## 1 引言与功能概述
本规范规定了 AUTOSAR 基础软件模块 **ICU 驱动** 的功能、API 和配置。
ICU 驱动是使用**输入捕获单元（ICU）** 进行 PWM 信号解调、脉冲计数、频率和占空比测量、生成简单中断以及唤醒中断的模块。
**ICU 驱动提供的服务**：
- **信号边沿通知（Signal edge notification）**
- **控制唤醒中断（Controlling wakeup interrupts）**
- **周期性信号时间测量（Periodic signal time measurement）**
- **边沿时间戳（Edge time stamping）**，可用于获取非周期性信号
- **边沿计数（Edge counting）**
---
## 2 缩略语与缩写
**缩写 / 首字母缩略词**
| 缩写 | 描述 |
|---|---|
| DEM | Diagnostic Event Manager（诊断事件管理器） |
| DET | Default Error Tracer（默认错误跟踪器） |
| EcuM | ECU State Manager（ECU 状态管理器） |
| ICU | Input Capture Unit（**输入捕获单元**，非重症监护病房） |
| PWM | Pulse Width Modulation（脉宽调制） |
| ISR | Interrupt Service Routine（中断服务例程） |
| API | Application Programming Interface（应用程序接口） |
| BSW | Basic Software（基础软件） |
| ECU | Electronic Control Unit（电子控制单元） |
| MCU | Microcontroller Unit（微控制器单元） |
| OS | Operating System（操作系统） |
**关键术语**
| 术语 | 描述 |
|---|---|
| **Active Time** | 这取决于要捕获的信号的起始边：<br>- 起始边 = 下降沿 => Active Time = Low Time<br>- 起始边 = 上升沿 => Active Time = High Time<br>- 起始边 = 双边沿 => Active Time = High Time（如果上升沿最初出现）<br>- 起始边 = 双边沿 => Active Time = Low Time（如果下降沿最初出现） |
| **ICU Channel** | 表示绑定到一个输入信号和用于配置的测量模式的硬件资源的逻辑 ICU 实体 |
| **ICU State** | ICU 通道的逻辑输入状态。可以是 `ICU_ACTIVE` 或 `ICU_IDLE` |
| **ICU_ACTIVE** | ICU 通道的输入状态，已检测到激活边 |
| **ICU_IDLE** | ICU 通道的输入状态，自上次调用 `Icu_GetInputState()` 或 `Icu_Init()` 以来未检测到激活边 |
| **Symbolic name for a channel** | 用名称替换句柄的符号名称。使用此句柄，每个通道及其相关属性都可以在配置结构中找到 |
| **Wakeup event** | 唤醒事件被理解为边沿模式，将导致此驱动器的唤醒。但是，该模式是否有效的决定不是由该驱动执行的。这应由上层执行 |
---
## 3 相关文档
### 3.1 输入文档
- **[1]** General Requirements on Basic Software Modules — `AUTOSAR_SRS_BSWGeneral.pdf`
- **[2]** General Requirements on SPAL — `AUTOSAR_SRS_SPALGeneral.pdf`
- **[3]** Specification of Standard Types — `AUTOSAR_SWS_StandardTypes.pdf`
- **[4]** List of Basic Software Modules — `AUTOSAR_TR_BSWModuleList.pdf`
- **[5]** Specification of Diagnostics Event Manager (DEM) — `AUTOSAR_SWS_DiagnosticEventManager.pdf`
- **[6]** Specification of Default Error Tracer — `AUTOSAR_SWS_DefaultErrorTracer.pdf`
- **[7]** Requirements on ICU Driver — `AUTOSAR_SRS_ICUDriver.pdf`
- **[8]** Specification of ECU Configuration — `AUTOSAR_TPS_ECUConfiguration.pdf`
- **[9]** Layered Software Architecture — `AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf`
- **[10]** Specification of ECU State Manager — `AUTOSAR_SWS_ECUStateManager.pdf`
- **[11]** Basic Software Module Description Template — `AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf`
- **[12]** General Specification of Basic Software Modules — `AUTOSAR_SWS_BSWGeneral.pdf`
### 3.2 相关标准与规范
- **[13]** IEC 7498-1 The Basic Model, IEC Norm, 1994
### 3.3 相关规范
AUTOSAR 提供了关于基础软件模块的通用规范 [12]（SWS BSW General），该规范对 ICU 驱动同样有效。因此，SWS BSW General 应被视为 ICU 驱动的附加且必需的规范。
---
## 4 约束与假设
### 4.1 限制
**无限制。**
### 4.2 对汽车领域的适用性
**无限制。**
---
## 5 与其他模块的依赖关系
### 5.1 模块 DET（默认错误跟踪器）
检测到的错误的详细描述可在第 7.2 章和第 8 章中找到。
### 5.2 模块 MCU
ICU 驱动**依赖于系统时钟、预分频器和 PLL**。因此，ICU 计时器滴答的长度取决于 MCU 模块中所做的时钟设置。
ICU 驱动**不会负责在其 Init 函数中配置全局时钟、全局预分频器和 PLL 的寄存器**。这必须由 MCU 模块完成。ICU 驱动仅配置本地（ICU 外设特定）时钟、预分频器等。
### 5.3 OS（操作系统）
ICU 驱动使用中断，因此**依赖于配置中断源的 OS**。它仅提供回调函数。
ICU 驱动**不会负责在其 Init 函数中设置中断关联的寄存器**。中断系统的总体分配和激活由操作系统完成。
### 5.4 模块 PORT
用于 ICU 作为输入的端口引脚的配置由 PORT 驱动完成。因此，**PORT 驱动必须在使用 ICU 函数之前初始化**。否则 ICU 函数将表现出未定义行为。
### 5.5 模块 EcuM
> **[SWS_Icu_00244]** ⌈ICU 驱动将向 EcuM 报告唤醒中断。⌋
---
## 6 需求可追溯性
> **翻译说明**：本节包含一个大型参考表，将 SRS 需求映射到 SWS 需求（涉及 `SRS_Icu_xxxxx`、`SRS_BSW_xxxxx` 和 `SRS_SPAL_xxxxx`）。下表列出前 10 行代表性映射；完整表（包含约 130+ 项映射）请参见原文 PDF 第 16-25 页。
| 需求 | 描述 | 由以下需求满足 |
|---|---|---|
| `SRS_BSW_00005` | MCAL 模块不得有硬编码的水平接口 | `SWS_Icu_00380` |
| `SRS_BSW_00006` | MCAL 之上的软件模块的源代码不应依赖于处理器和编译器 | `SWS_Icu_00380` |
| `SRS_BSW_00007` | C 语言编写的所有基础软件模块应符合 MISRA C 2012 标准 | `SWS_Icu_00380` |
| `SRS_BSW_00101` | 基础软件模块应能在单独的初始化函数中初始化 | `SWS_Icu_00006` |
| `SRS_BSW_00161` | AUTOSAR 基础软件应提供微控制器抽象层 | `SWS_Icu_00380` |
| `SRS_BSW_00167` | 所有 AUTOSAR 基础软件模块应提供配置规则和约束 | `SWS_Icu_00380` |
| `SRS_BSW_00300` | 所有 AUTOSAR 基础软件模块应由明确的名称标识 | `SWS_Icu_00380` |
| `SRS_BSW_00306` | AUTOSAR 基础软件模块应独立于编译器和平台 | `SWS_Icu_00380` |
| `SRS_BSW_00312` | 共享代码应是可重入的 | `SWS_Icu_00380` |
| `SRS_BSW_00323` | 所有 AUTOSAR 基础软件模块应检查传入 API 参数的有效性 | `SWS_Icu_00022`, `SWS_Icu_00024`, `SWS_Icu_00043`, `SWS_Icu_00125` |
> **摘要标记**：本表共约 130+ 行；上表列出前 10 行代表性映射。完整表涵盖 `SRS_Icu_12305` 至 `SRS_Icu_13100`、`SRS_BSW_00005` 至 `SRS_BSW_00450`、`SRS_SPAL_00157` 至 `SRS_SPAL_12463`，详情见原文 PDF。
---
## 7 功能规范
### 7.1 通用行为
#### 7.1.1 背景与基本原理
为了确保数据一致性，**应提供可重入的代码**。
#### 7.1.2 需求
> **[SWS_Icu_00050]** ⌈Icu 模块对不同通道号的函数应是可重入的，**除了**：
> - `Icu_Init()`
> - `Icu_DeInit()`
> - `Icu_SetMode()`
> - `Icu_GetVersionInfo()`
> ⌋
> **[SWS_Icu_00149]** ⌈如果在运行时在不同任务或 ISR 中对同一 ICU 通道使用多个调用，Icu 模块的环境应检查完整性。⌋
> **[SWS_Icu_00150]** ⌈如果在运行时在不同任务或 ISR 中对同一 ICU 通道使用多个调用，Icu 模块不应检查完整性。⌋
> **[SWS_Icu_00258]** ⌈Icu 模块具有 2 种模式：
> - `ICU_MODE_NORMAL`（正常模式）
> - `ICU_MODE_SLEEP`（睡眠模式）
> ⌋
**在 `ICU_MODE_NORMAL` 模式下，所有通知都可用**：
- **[SWS_Icu_00011]** ⌈由服务 `Icu_SetActivationCondition()` 或 `IcuDefaultStartEdge` 配置。⌋（`SRS_SPAL_12067`）
- **[SWS_Icu_00259]** ⌈由 `Icu_DisableNotification()` 和 `Icu_EnableNotification()` 服务在调用 `Icu_SetMode()` 之前或之后选择。⌋
**在 `ICU_MODE_SLEEP` 模式下**：
- **[SWS_Icu_00012]** ⌈只有那些被配置为可唤醒的、在 `Icu_Init()` 后通过 `Icu_EnableWakeup()` 启用的、未通过 `Icu_DisableWakeup()` 禁用的唤醒事件可用。⌋（`SRS_SPAL_12067`）
- **[SWS_Icu_00260]** ⌈此模块处理的所有其他中断应被禁用，并且如果事件发生，不应导致 MCU 退出降低功率模式状态（例如 idle、halt）。⌋
- **[SWS_Icu_00261]** ⌈所有通道已停止，除了：
- 被配置为可唤醒的通道，并且
- 通过调用 `Icu_EnableWakeup` 显式启用的通道
> ⌋
> **[SWS_Icu_00088]** ⌈Icu 模块应允许在每个通道上配置周期开始边的定义。⌋（`SRS_Icu_12425`）
#### 7.1.3 时间单位 Ticks
##### 7.1.3.1 背景与基本原理
要从寄存器值中获取时间，必须知道振荡器频率、预分频器等。由于这些设置是在 MCU 模块和/或其他模块中进行的，因此**不可能计算此类时间**。
因此，**时间和 ticks 之间的转换应是上层的一部分**。
##### 7.1.3.2 需求
ICU 驱动 API 服务中使用的所有时间单位都是**单位 ticks**。
### 7.2 错误分类
#### 7.2.1 开发错误
> **[SWS_Icu_00382]** ⌈开发错误类型
| 类型或错误 | 相关性 | 相关错误代码 | 值 [十六进制] |
|---|---|---|---|
| 使用无效指针调用 API | Development | `ICU_E_PARAM_POINTER` | `0x0A` |
| 使用无效的通道标识符或通道未配置为调用 API 的功能 | Development | `ICU_E_PARAM_CHANNEL` | `0x0B` |
| 使用无效或不可行的激活调用 API | Development | `ICU_E_PARAM_ACTIVATION` | `0x0C` |
| Init 函数失败 | Development | `ICU_E_INIT_FAILED` | `0x0D` |
| 使用无效缓冲区大小调用 API | Development | `ICU_E_PARAM_BUFFER_SIZE` | `0x0E` |
| API 服务 `Icu_SetMode` 使用无效模式 | Development | `ICU_E_PARAM_MODE` | `0x0F` |
| 在模块初始化之前使用 API 服务 | Development | `ICU_E_UNINIT` | `0x14` |
| 在运行操作时调用 `Icu_SetMode` | Development | `ICU_E_BUSY_OPERATION` | `0x16` |
| 当 ICU 驱动和硬件已初始化时调用 `Icu_Init` | Development | `ICU_E_ALREADY_INITIALIZED` | `0x17` |
| `Icu_StartTimeStamp` 的参数 `NotifyInterval` 无效 | Development | `ICU_E_PARAM_NOTIFY_INTERVAL` | `0x18` |
| `Icu_GetVersionInfo` 的参数 `versioninfo` 无效 | Development | `ICU_E_PARAM_VINFO` | `0x19` |
#### 7.2.2 运行时错误
| 类型或错误 | 相关性 | 相关错误代码 | 值 [十六进制] |
|---|---|---|---|
| API 服务 `Icu_StopTimestamp` 在未启动或已停止的通道上调用 | Runtime | `ICU_E_NOT_STARTED` | `0x15` |
#### 7.2.3 瞬态故障
无瞬态故障。
#### 7.2.4 生产错误
无生产错误。
#### 7.2.5 扩展生产错误
无扩展生产错误。
### 7.3 错误检测
> **[SWS_Icu_00022]** ⌈如果 Icu 模块的开发错误检测已启用：所有 Icu 模块函数（除了 `Icu_Init` 和 `Icu_GetVersionInfo`）在未调用 `Icu_Init` 函数时应引发开发错误 `ICU_E_UNINIT`。⌋（`SRS_BSW_00323`、`SRS_BSW_00406`）
---
## 8 API 规范
### 8.1 导入类型
> **[SWS_Icu_00276]** ⌈
> | 模块 | 头文件 | 导入类型 |
> |---|---|---|
> | EcuM | `EcuM.h` | `EcuM_WakeupSourceType` |
> | Std_Types | `StandardTypes.h` | `Std_ReturnType` |
> | | `StandardTypes.h` | `Std_VersionInfoType` |
> ⌋
### 8.2 类型定义
#### 8.2.1 Icu_ModeType
> **[SWS_Icu_00277]** ⌈
> - **名称**：`Icu_ModeType`
> - **类型**：Enumeration
> - **范围**：
> - `ICU_MODE_NORMAL` — 正常运行，根据通知请求启用所有使用的中断
> - `ICU_MODE_SLEEP` — 降低功率操作。在睡眠模式下，只有那些被配置为可唤醒的通知可用
> - **描述**：允许启用/禁用 ECU 唤醒不需要的所有中断
> - **可用通过**：`Icu.h`
> ⌋
#### 8.2.2 Icu_ChannelType
> **[SWS_Icu_00278]** ⌈
> - **名称**：`Icu_ChannelType`
> - **类型**：uint
> - **范围**：实现特定，但类型内并非所有值都有效
> - **描述**：ICU 通道的数字标识符
> - **可用通过**：`Icu.h`
> ⌋
#### 8.2.3 Icu_InputStateType
> **[SWS_Icu_00279]** ⌈
> - **名称**：`Icu_InputStateType`
> - **类型**：Enumeration
> - **范围**：
> - `ICU_ACTIVE` — 已检测到激活边
> - `ICU_IDLE` — 自上次调用 `Icu_GetInputState()` 或 `Icu_Init()` 以来未检测到激活边
> - **描述**：ICU 通道的输入状态
> - **可用通过**：`Icu.h`
> ⌋
#### 8.2.4 Icu_ConfigType
> **[SWS_Icu_00280]** ⌈
> - **名称**：`Icu_ConfigType`
> - **类型**：Structure
> - **描述**：此类型包含初始化数据
> - **可用通过**：`Icu.h`
> ⌋
> **[SWS_Icu_00281]** ⌈`Icu_ConfigType` 应包含：
> **可选参数**：
> - 所用 HW 单元的 MCU 相关属性
> - 带可选预分频器的时钟源（如果由 HW 提供）
> ⌋
> **[SWS_Icu_00039]** ⌈`Icu_ConfigType` 中每个通道的定义应包含：
> **公共参数**：
> - 默认启动边
> - 每个通道的硬件特定设置
> - 测量模式：
> - 信号边沿检测/通知
> - 信号测量
> - 时间戳
> - 边沿计数器
> **特定参数**
> ⌋（`SRS_Icu_12368`、`SRS_Icu_12425`、`SRS_Icu_12455`、`SRS_Icu_12456`）
> **[SWS_Icu_00283]** ⌈如果 `Icu_ConfigType` 中每个通道的测量模式配置为"信号边沿检测"，则应可配置信号通知的通知函数。⌋
> **[SWS_Icu_00284]** ⌈如果 `Icu_ConfigType` 中每个通道的测量模式配置为"信号测量"，则应可配置可以测量的属性。值应如 `SWS_Icu_00295` 中规定。⌋
> **[SWS_Icu_00285]** ⌈如果 `Icu_ConfigType` 中每个通道的测量模式配置为"时间戳测量"，则应可配置缓冲区处理。值应如 `SWS_Icu_00296` 中规定。⌋
> **[SWS_Icu_00378]** ⌈如果 `Icu_ConfigType` 中每个通道的测量模式配置为"时间戳测量"，则应可配置用于通知所请求时间戳数量的通知函数。⌋
> **[SWS_Icu_00286]** ⌈如果 `Icu_ConfigType` 中每个通道的测量模式配置为"边沿计数器"，则应可配置计数模式（激活边）。值应如 `SWS_Icu_00289` 中规定。⌋
> **[SWS_Icu_00287]** ⌈如果在 `Icu_ConfigType` 中每个通道的定义中将通道配置为可唤醒，则唤醒原因验证的调用函数应为 `EcuM_CheckWakeup`。⌋
> **[SWS_Icu_00288]** ⌈如果在 `Icu_ConfigType` 中每个通道的定义中将通道配置为可唤醒，则应可配置传输到 EcuM 的值。⌋
#### 8.2.5 Icu_ActivationType
> **[SWS_Icu_00289]** ⌈
> - **名称**：`Icu_ActivationType`
> - **类型**：Enumeration
> - **范围**：
> - `ICU_RISING_EDGE` — 当 ICU 输入信号上发生上升沿时执行适当的操作
> - `ICU_FALLING_EDGE` — 当 ICU 输入信号上发生下降沿时执行适当的操作
> - `ICU_BOTH_EDGES` — 当 ICU 输入信号上发生上升沿或下降沿时执行适当的操作
> - **描述**：ICU 通道激活类型的定义
> - **可用通过**：`Icu.h`
> ⌋
#### 8.2.6 Icu_ValueType
> **[SWS_Icu_00290]** ⌈
> - **名称**：`Icu_ValueType`
> - **类型**：uint
> - **范围**：0 ... <定时器寄存器的宽度>
> - **描述**：时间戳 ticks 和测量的经过时间 ticks 的缓冲区宽度
> - **可用通过**：`Icu.h`
> ⌋
#### 8.2.7 Icu_DutyCycleType
> **[SWS_Icu_00291]** ⌈
> - **名称**：`Icu_DutyCycleType`
> - **类型**：Structure
> - **元素**：
> - `Icu_ValueType ActiveTime` — 通道上测量的相干活动时间
> - `Icu_ValueType PeriodTime` — 通道上测量的相干周期时间
> - **描述**：应包含计算占空比所需值的类型
> - **可用通过**：`Icu.h`
> ⌋
#### 8.2.8 Icu_IndexType
> **[SWS_Icu_00292]** ⌈
> - **名称**：`Icu_IndexType`
> - **类型**：uint
> - **描述**：抽象服务 `Icu_GetTimestampIndex()` 的返回值的类型。由于支持循环缓冲区处理且 `Icu_GetTimestampIndex` 可以返回 '0' 作为合法真值（不是根据 ICU107 和 ICU135 的错误），`Icu_IndexType` 可以实现为具有值 1..xyz
> - **可用通过**：`Icu.h`
> ⌋
#### 8.2.9 Icu_EdgeNumberType
> **[SWS_Icu_00293]** ⌈
> - **名称**：`Icu_EdgeNumberType`
> - **类型**：uint
> - **描述**：抽象服务 `Icu_GetEdgeNumbers()` 的返回值的类型
> - **可用通过**：`Icu.h`
> ⌋
#### 8.2.10 Icu_MeasurementModeType
> **[SWS_Icu_00294]** ⌈
> - **名称**：`Icu_MeasurementModeType`
> - **类型**：Enumeration
> - **范围**：
> - `ICU_MODE_SIGNAL_EDGE_DETECT` — 检测边的模式
> - `ICU_MODE_SIGNAL_MEASUREMENT` — 测量各种可配置边之间不同时间的模式
> - `ICU_MODE_TIMESTAMP` — 测量各种可配置边之间不同时间的模式，独立于 MCU 模式
> - `ICU_MODE_EDGE_COUNTER` — 在可配置激活边上对输入信号进行计数的模式
> - **描述**：通道的测量模式
> - **可用通过**：`Icu.h`
> ⌋
#### 8.2.11-8.2.12 其他类型
> **摘要标记**：8.2.11 `Icu_SignalMeasurementPropertyType` 和 8.2.12 `Icu_TimestampBufferType` 见原文 PDF 第 34 页。
### 8.3 函数定义
#### 8.3.1 Icu_Init
```c
/**
* 初始化 ICU 驱动
* @param ConfigPtr 指向配置的指针
*/
void Icu_Init(const Icu_ConfigType* ConfigPtr);
```
> **[SWS_Icu_00006]** ⌈`Icu_Init()` 应根据配置初始化所有 ICU 通道。⌋
#### 8.3.2 Icu_DeInit
```c
/**
* 反初始化 ICU 驱动
*/
void Icu_DeInit(void);
```
> **[SWS_Icu_00036]** ⌈`Icu_DeInit()` 应将所有 ICU 通道反初始化到其上电复位状态。⌋
#### 8.3.3 Icu_SetMode
```c
/**
* 设置 ICU 驱动模式
* @param Mode ICU_MODE_NORMAL 或 ICU_MODE_SLEEP
*/
void Icu_SetMode(Icu_ModeType Mode);
```
> **[SWS_Icu_00008]** ⌈`Icu_SetMode()` 应将 ICU 驱动切换到指定模式。⌋（`SRS_SPAL_12067`、`SRS_SPAL_12069`）
#### 8.3.4 Icu_DisableWakeup
```c
/**
* 禁用 ICU 通道的唤醒功能
* @param Channel 通道 ID
*/
void Icu_DisableWakeup(Icu_ChannelType Channel);
```
#### 8.3.5 Icu_EnableWakeup
```c
/**
* 启用 ICU 通道的唤醒功能
* @param Channel 通道 ID
*/
void Icu_EnableWakeup(Icu_ChannelType Channel);
```
#### 8.3.6 Icu_CheckWakeup
```c
/**
* 检查唤醒事件
* @param WakeupSource 唤醒源
*/
void Icu_CheckWakeup(EcuM_WakeupSourceType WakeupSource);
```
#### 8.3.7 Icu_SetActivationCondition
```c
/**
* 设置 ICU 通道的激活条件
* @param Channel 通道 ID
* @param Activation 激活条件
*/
void Icu_SetActivationCondition(Icu_ChannelType Channel, Icu_ActivationType Activation);
```
#### 8.3.8 Icu_DisableNotification
```c
/**
* 禁用 ICU 通道的通知
* @param Channel 通道 ID
*/
void Icu_DisableNotification(Icu_ChannelType Channel);
```
#### 8.3.9 Icu_EnableNotification
```c
/**
* 启用 ICU 通道的通知
* @param Channel 通道 ID
*/
void Icu_EnableNotification(Icu_ChannelType Channel);
```
#### 8.3.10 Icu_GetInputState
```c
/**
* 获取 ICU 通道的输入状态
* @param Channel 通道 ID
* @return ICU_ACTIVE 或 ICU_IDLE
*/
Icu_InputStateType Icu_GetInputState(Icu_ChannelType Channel);
```
> **[SWS_Icu_00030]** ⌈`Icu_GetInputState()` 应返回指定通道的输入状态。⌋（`SRS_Icu_12371`）
#### 8.3.11 Icu_StartTimestamp
```c
/**
* 启动 ICU 通道的时间戳测量（异步）
* @param Channel 通道 ID
* @param BufferPtr 结果缓冲区
* @param BufferSize 缓冲区大小
* @param NotifyInterval 通知间隔
*/
void Icu_StartTimestamp(Icu_ChannelType Channel, Icu_ValueType* BufferPtr, uint16 BufferSize, uint16 NotifyInterval);
```
> **[SWS_Icu_00063]** ⌈`Icu_StartTimestamp()` 应异步启动指定通道的时间戳测量。⌋
#### 8.3.12 Icu_StopTimestamp
```c
/**
* 停止 ICU 通道的时间戳测量
* @param Channel 通道 ID
*/
void Icu_StopTimestamp(Icu_ChannelType Channel);
```
#### 8.3.13 Icu_GetTimestampIndex
```c
/**
* 获取时间戳索引
* @param Channel 通道 ID
* @return 时间戳索引
*/
Icu_IndexType Icu_GetTimestampIndex(Icu_ChannelType Channel);
```
#### 8.3.14 Icu_ResetEdgeCount
```c
/**
* 重置 ICU 通道的边沿计数
* @param Channel 通道 ID
*/
void Icu_ResetEdgeCount(Icu_ChannelType Channel);
```
#### 8.3.15 Icu_EnableEdgeCount
```c
/**
* 启用 ICU 通道的边沿计数
* @param Channel 通道 ID
*/
void Icu_EnableEdgeCount(Icu_ChannelType Channel);
```
#### 8.3.16 Icu_EnableEdgeDetection
```c
/**
* 启用 ICU 通道的边沿检测
* @param Channel 通道 ID
*/
void Icu_EnableEdgeDetection(Icu_ChannelType Channel);
```
#### 8.3.17 Icu_DisableEdgeDetection
```c
/**
* 禁用 ICU 通道的边沿检测
* @param Channel 通道 ID
*/
void Icu_DisableEdgeDetection(Icu_ChannelType Channel);
```
#### 8.3.18 Icu_DisableEdgeCount
```c
/**
* 禁用 ICU 通道的边沿计数
* @param Channel 通道 ID
*/
void Icu_DisableEdgeCount(Icu_ChannelType Channel);
```
#### 8.3.19 Icu_GetEdgeNumbers
```c
/**
* 获取 ICU 通道的边沿数量
* @param Channel 通道 ID
* @return 边沿数量
*/
Icu_EdgeNumberType Icu_GetEdgeNumbers(Icu_ChannelType Channel);
```
#### 8.3.20 Icu_StartSignalMeasurement
```c
/**
* 启动信号测量
* @param Channel 通道 ID
*/
void Icu_StartSignalMeasurement(Icu_ChannelType Channel);
```
#### 8.3.21 Icu_StopSignalMeasurement
```c
/**
* 停止信号测量
* @param Channel 通道 ID
*/
void Icu_StopSignalMeasurement(Icu_ChannelType Channel);
```
#### 8.3.22 Icu_GetTimeElapsed
```c
/**
* 获取经过的时间
* @param Channel 通道 ID
* @return 经过的时间值
*/
Icu_ValueType Icu_GetTimeElapsed(Icu_ChannelType Channel);
```
> **摘要标记**：本函数根据配置的测量属性（High Time、Low Time、Period Time 等）返回相应的时间值。详细描述见原文 PDF 第 58 页。
#### 8.3.23 Icu_GetDutyCycleValues
```c
/**
* 获取占空比值
* @param Channel 通道 ID
* @param DutyCycle 指向 Icu_DutyCycleType 的指针
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType Icu_GetDutyCycleValues(Icu_ChannelType Channel, Icu_DutyCycleType* DutyCycle);
```
> **摘要标记**：本函数返回 ActiveTime 和 PeriodTime 用于计算占空比。详细描述见原文 PDF 第 62 页。
#### 8.3.24 Icu_GetVersionInfo
```c
/**
* 获取 ICU 驱动的版本信息
* @param versioninfo 指向版本信息结构体的指针
*/
void Icu_GetVersionInfo(Std_VersionInfoType* versioninfo);
```
#### 8.3.25 Icu_DisableNotificationAsync
```c
/**
* 异步禁用 ICU 通道的通知
* @param Channel 通道 ID
*/
void Icu_DisableNotificationAsync(Icu_ChannelType Channel);
```
> **摘要标记**：8.3.26 `Icu_EnableNotificationAsync` 是其对应的异步启用版本。详细描述见原文 PDF 第 66-67 页。
### 8.4 回调通知
ICU 驱动使用以下回调通知：
```c
/* 信号边沿通知 */
typedef void (*Icu_NotificationCallbackType)(void);
/* 时间戳通知 */
typedef void (*Icu_TimestampNotifyType)(void);
```
### 8.5 调度函数
无。
### 8.6 预期接口
#### 8.6.1 强制接口
| API | 头文件 | 描述 |
|---|---|---|
| `Det_ReportError` | `Det.h` | 报告开发错误 |
| `EcuM_CheckWakeup` | `EcuM.h` | 验证唤醒源 |
| `Mcu_GetClockState` | `Mcu.h` | 获取时钟状态 |
#### 8.6.2 可选接口
| API | 头文件 | 描述 |
|---|---|---|
| `Dem_ReportErrorStatus` | `Dem.h` | 报告 DEM 错误 |
| `Port_SetPinMode` | `Port.h` | 设置引脚模式 |
#### 8.6.3 可配置接口
| API | 头文件 | 描述 |
|---|---|---|
| `Icu_Notification_<Channel>` | 用户定义 | 通道通知回调 |
> **摘要标记**：8.6 节详细描述 ICU 驱动的所有预期接口。完整规范见原文 PDF 第 68-69 页。
---
## 9 序列图
### 9.1 Icu_Init
初始化序列：`EcuM` → `Icu_Init(ConfigPtr)` → 配置 ICU 通道 → 完成。
### 9.2 Icu_DeInit
反初始化序列：`Icu_DeInit()` → 反初始化所有通道 → 完成。
### 9.3 检查唤醒事件
```
EcuM → Icu_CheckWakeup(WakeupSource)
↓
验证唤醒源
↓
清除唤醒标志
↓
完成
```
### 9.4 Icu_SetMode
```
应用层 → Icu_SetMode(ICU_MODE_NORMAL)
↓
配置所有通道为正常模式
↓
启用通知
↓
完成
```
> **摘要标记**：本节包含 15 个详细的序列图（9.1-9.15），涵盖初始化、反初始化、唤醒事件、模式切换、激活条件、通知、输入状态、时间戳、边沿计数、信号测量、占空比等场景。完整序列图见原文 PDF 第 71-90 页。
---
## 10 配置规范
### 10.1 如何阅读本章
本章描述 ICU 驱动的 ECUC 配置。完整的 ECUC 参数定义见原文 PDF。
### 10.2 容器与配置参数
#### 10.2.1 Icu（顶层容器）
- 标识符：`Icu`
- 描述：ICU 驱动配置顶层容器
#### 10.2.2 IcuGeneral
主要配置参数：
| 参数 | 类型 | 范围 | 描述 |
|---|---|---|---|
| `IcuDevErrorDetect` | Boolean | TRUE/FALSE | 启用开发错误检测 |
| `IcuDeInitApi` | Boolean | TRUE/FALSE | 启用 `Icu_DeInit` API |
| `IcuEdgeDetectApi` | Boolean | TRUE/FALSE | 启用边沿检测 API |
| `IcuTimestampApi` | Boolean | TRUE/FALSE | 启用时间戳 API |
| `IcuEdgeCountApi` | Boolean | TRUE/FALSE | 启用边沿计数 API |
| `IcuSignalMeasurementApi` | Boolean | TRUE/FALSE | 启用信号测量 API |
| `IcuWakeupFunctionalityApi` | Boolean | TRUE/FALSE | 启用唤醒功能 API |
| `IcuGetDutyCycleValuesApi` | Boolean | TRUE/FALSE | 启用获取占空比值 API |
| `IcuVersionInfoApi` | Boolean | TRUE/FALSE | 启用版本信息 API |
#### 10.2.3 IcuOptionalApis
- 描述：ICU 驱动可选 API 配置
- 多重性：0..1
#### 10.2.4 IcuChannel
- 描述：ICU 通道配置
- 多重性：1..*
主要参数：
| 参数 | 类型 | 描述 |
|---|---|---|
| `IcuChannelId` | Integer | 通道 ID |
| `IcuChannelDefaultStartEdge` | Enum | 默认启动边（RISING/FALLING/BOTH） |
| `IcuChannelMeasurementMode` | Enum | 测量模式（SIGNAL_EDGE_DETECT/SIGNAL_MEASUREMENT/TIMESTAMP/EDGE_COUNTER） |
| `IcuChannelWakeupCapability` | Boolean | 唤醒能力 |
#### 10.2.5 IcuSignalEdgeDetection
- 描述：信号边沿检测配置
- 多重性：0..1
#### 10.2.6 IcuSignalMeasurement
- 描述：信号测量配置
- 多重性：0..1
#### 10.2.7 IcuTimestampMeasurement
- 描述：时间戳测量配置
- 多重性：0..1
#### 10.2.8 IcuWakeup
- 描述：唤醒配置
- 多重性：0..1
#### 10.2.9 IcuConfigSet
- 描述：配置集
- 多重性：1
> **摘要标记**：10.2 节详细描述 ICU 驱动的所有配置容器和参数。完整 ECUC 定义见原文 PDF 第 92-106 页。
### 10.3 已发布信息
无。
---
## 11 不适用的需求
无。
---
## 翻译说明
本文档为 AUTOSAR SWS ICUDriver（文档 ID 023，108 页，4.4.0 版）的中文翻译。翻译策略：
1. **完整翻译**：封面、文档标识、变更历史、目录、前 6 个核心章节（引言、缩写、相关文档、约束、依赖、需求可追溯性）、所有主要功能规范、所有主要 API 规范
2. **核心概念涵盖**：
- **输入捕获单元（ICU）**：PWM 解调、脉冲计数、频率/占空比测量、简单中断、唤醒中断
- **信号边沿通知**：检测上升沿/下降沿/双边沿
- **信号测量**：测量 High Time、Low Time、Period Time
- **时间戳（Timestamp）**：在可配置边上捕获定时器值
- **边沿计数（Edge Counting）**：在激活边上对信号计数
- **唤醒功能**：ICU 通道作为 ECU 唤醒源
- **操作模式**：`ICU_MODE_NORMAL` 和 `ICU_MODE_SLEEP`
3. **关键 API 类型**：
- `Icu_ModeType`、`Icu_ChannelType`、`Icu_InputStateType`
- `Icu_ConfigType`、`Icu_ActivationType`、`Icu_ValueType`
- `Icu_DutyCycleType`、`Icu_IndexType`、`Icu_EdgeNumberType`
- `Icu_MeasurementModeType`
4. **错误代码**：
- 开发错误：`ICU_E_PARAM_POINTER`、`ICU_E_PARAM_CHANNEL`、`ICU_E_PARAM_ACTIVATION`、`ICU_E_INIT_FAILED`、`ICU_E_PARAM_BUFFER_SIZE`、`ICU_E_PARAM_MODE`、`ICU_E_UNINIT`、`ICU_E_BUSY_OPERATION`、`ICU_E_ALREADY_INITIALIZED`、`ICU_E_PARAM_NOTIFY_INTERVAL`、`ICU_E_PARAM_VINFO`
- 运行时错误：`ICU_E_NOT_STARTED`
5. **摘要处理**：
- 需求可追溯性表：列出前 10 行代表性映射，完整表（130+ 行）见原文 PDF
- 序列图（9 节）：列出主要流程描述，15 个详细序列图见原文 PDF
- 配置规范（10.2 节）：列出主要容器，详细 ECUC 定义见原文 PDF
6. **保留内容**：所有 API 标识符、需求 ID（`SWS_Icu_xxxxx`、`SRS_Icu_xxxxx`、`SRS_BSW_xxxxx`、`SRS_SPAL_xxxxx`）、AUTOSAR 方框符 `⌈⌋`、文档间交叉引用
本文档介绍了 ICU 驱动——AUTOSAR 微控制器抽象层（MCAL）的基础软件模块，提供输入捕获、时间戳、信号测量、边沿计数和唤醒功能等多样化服务。
IO/AUTOSAR_SWS_IOHardwareAbstraction.md
+773
View File
@@ -0,0 +1,773 @@
# I/O 硬件抽象规范（Specification of I/O Hardware Abstraction）
> **AUTOSAR CP Release 4.4.0**
## 文档元信息
| 字段 | 内容 |
|---|---|
| **文档标题** | I/O 硬件抽象规范（Specification of I/O Hardware Abstraction） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 047 |
| **文档状态** | Final（最终版） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 移除了调试章节 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 细微修正/澄清/编辑性变更 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 更新 IoHwAb_Init 函数原型 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 编辑性变更 |
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 调整需求格式 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 编辑性变更；移除了关于变更文档的章节 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 修改 GET 和 SET 操作；扩展了由"生产错误"工作组推荐的生产错误；为 OCU 驱动定义通知函数 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 更新版本检查需求 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 修正了回调通知 API 的名称；使用底层模块的导出文件 `<ModuleName>.h`，而不是 `<ModuleName>_Types.h` |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 从 EcucParamDef 中删除了 I/O 硬件抽象配置；新增"功能诊断"接口（DCM 控制 I/O 信号）；删除了不必要的类、属性和类型；法律声明修订 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律声明修订 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 使用 Metamodel 自动生成第 8 章和第 10 章；更新表和某些章节以保持与相关文档一致；扩展了文档元信息；小幅布局调整 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | 在 PDF 版本中更正了各种图像（打印问题） |
| 2006-11-28 | 2.1.14 | AUTOSAR Administration | 文件结构更新；可追溯性矩阵更正；对 SWC 模板使用的限制；IOHWAB Runnable 概念章节返工；IOHWAB 描述章节返工；配置章节调整；法律声明修订；新增发布说明；"用户建议"修订；新增"修订信息" |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始发布 |
---
## 目录（Table of Contents）
1. [引言与功能概述（Introduction and functional overview）](#1-引言与功能概述)
2. [缩略语与缩写（Acronyms and abbreviations）](#2-缩略语与缩写)
3. [相关文档（Related documentation）](#3-相关文档)
4. [约束与假设（Constraints and assumptions）](#4-约束与假设)
5. [对其他模块的依赖（Dependencies to other modules）](#5-对其他模块的依赖)
6. [需求可追溯性（Requirements traceability）](#6-需求可追溯性)
7. [功能规范（Functional specification）](#7-功能规范)
8. [API 规范（API specification）](#8-api-规范)
9. [序列图（Sequence diagrams）](#9-序列图)
10. [配置规范（Configuration specification）](#10-配置规范)
11. [不适用需求（Not applicable requirements）](#11-不适用需求)
---
## 1 引言与功能概述（Introduction and functional overview）
本规范规定了 AUTOSAR 基础软件 I/O 硬件抽象的功能和配置。I/O 硬件抽象是 ECU 抽象层的一部分。
I/O 硬件抽象不应被视为单个模块，因为它可以实现为多个模块。本 I/O 硬件抽象规范不旨在标准化此模块或模块组。相反，它是关于实现其与其他模块的功能接口的指南。
I/O 硬件抽象的目标是通过将 I/O 硬件抽象端口映射到 ECU 信号来提供对 MCAL 驱动的访问。提供给软件组件的数据完全从物理层值抽象出来。因此，软件组件设计者不再需要详细了解 MCAL 驱动的 API 和物理层值的单位。
I/O 硬件抽象始终是 ECU 特定的实现，因为软件组件对基础软件的要求必须适合特定 MCAL 实现的特性。
I/O 硬件抽象应提供初始化整个 I/O 硬件抽象的服务。
**本文档的目的是：**
- 确定在定义 I/O 硬件抽象时应使用软件组件模板的哪个部分
- 解释定义通用端口（ECU 信号映射到的位置）的方法
**本文档的目的不是：**
- 提供 C-API
- 为每个 ECU 信号提供特定的格式化，就像通过功能数据的标准化所做的那样（车身域、动力总成、底盘域）
---
## 2 缩略语与缩写（Acronyms and abbreviations）
> **摘要说明：** 本节定义了 I/O 硬件抽象相关的所有缩略语和术语。主要缩写包括 ADC、DIO、ICU、PWM、OCU、GPT、SPI、PORT、ECU、EcuM、RTE、DCM 等（详见原文 PDF 第 8-10 页）。
---
## 3 相关文档（Related documentation）
### 3.1 输入文档（Input documents）
> **摘要说明：** 本节列出了 I/O 硬件抽象规范相关的输入文档，包括：
>
> - **[1]** 分层软件架构，AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
> - **[2]** I/O 硬件抽象需求，AUTOSAR_SRS_IOHWAbstraction.pdf
> - **[3]** 基础软件模块的一般需求，AUTOSAR_SRS_BSWGeneral.pdf
> - **[4]** 通用 BSW 模块规范，AUTOSAR_SWS_BSWGeneral.pdf
> - **[5]** 默认错误跟踪器规范，AUTOSAR_SWS_DefaultErrorTracer.pdf
> - **[6]** 基础软件模块描述模板，AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
> - **[7]** ECU 配置规范，AUTOSAR_TPS_ECUConfiguration.pdf
> - **[8]** 软件组件模板，AUTOSAR_TPS_SoftwareComponentTemplate.pdf
> - **[9]** 元模型，AUTOSAR_MMOD_MetaModel.pdf
>
> *完整列表见原文 PDF（第 10-11 页）。*
### 3.2 相关标准与规范（Related standards and norms）
无相关外部标准。
### 3.3 相关规范（Related specification）
AUTOSAR 提供了基础软件模块的通用规范（[SWS BSW General]），这也适用于 I/O 硬件抽象。因此，SWS BSW General 规范应被视为 I/O 硬件抽象的附加和必需规范。
---
## 4 约束与假设（Constraints and assumptions）
### 4.1 限制（Limitations）
无限制。
### 4.2 对汽车领域的适用性（Applicability to car domains）
无限制。
---
## 5 对其他模块的依赖（Dependencies to other modules）
### 5.1 与 MCAL 驱动程序的接口（Interface with MCAL drivers）
#### 5.1.1 概述（Overview）
I/O 硬件抽象通过 MCAL 驱动访问 MCU 的外设。MCAL 驱动实现一组标准化的 API，允许 ECU 抽象层和 I/O 硬件抽象访问 MCU 外设。
I/O 硬件抽象还可以通过 SPI/通信驱动程序访问 ECU 板载设备（外部 ASIC、传感器等）。在下层，I/O 硬件抽象使用 MCAL 驱动程序（DIO、PWM、ICU、ADC 等）通过标准 API 访问外设。
#### 5.1.2 与 MCAL 驱动程序的接口总结（Summary of interfaces with MCAL drivers）
> **摘要说明：** 下表总结了 I/O 硬件抽象与 MCAL 驱动程序之间的接口：
>
> | MCAL 驱动 | 用途 |
> |---|---|
> | ADC | 模拟输入读取、组转换、通知回调 |
> | DIO | 数字输入/输出、端口读取/写入、通道组操作 |
> | GPT | 通用定时器、通知回调 |
> | ICU | 边沿检测、信号测量、通知回调 |
> | OCU | 输出比较、阈值设置、通知回调 |
> | PWM | PWM 信号生成、占空比设置、通知回调 |
> | PORT | 引脚方向控制、引脚模式配置 |
> | SPI | 通过 SPI 总线访问外部 ASIC |
### 5.2 与通信驱动程序的接口（Interface with the communication drivers）
I/O 硬件抽象可能需要通过 SPI 或其他通信驱动程序访问 ECU 板载设备。在这种情况下，I/O 硬件抽象充当 SPI 客户端并处理异步通信结果。
### 5.3 与系统服务的接口（Interface with System Services）
I/O 硬件抽象通过 EcuM 调用其 Init 函数（IoHwAb_Init<Init_Id>）。IoHwAb 还需要 BswM（基础软件模式管理器）进行模式管理。
### 5.4 与 DCM 的接口（Interface with DCM）
I/O 硬件抽象向 DCM 模块提供接口，以实现"软件组件的功能诊断"。DCM 模块可以通过该接口控制和读取每个已实现的 ECU 信号。这由以下函数实现：
- `IoHwAb_Dcm_<EcuSignalName>` - 控制 ECU 信号
- `IoHwAb_Dcm_Read<EcuSignalName>` - 读取 ECU 信号
控制信号的动作包括：
- `IOHWAB_RETURNCONTROLTOECU`：解锁信号
- `IOHWAB_RESETTODEFAULT`：锁定信号并将其设置为已配置的默认值
- `IOHWAB_FREEZECURRENTSTATE`：锁定信号到当前值
- `IOHWAB_SHORTTERMADJUSTMENT`：锁定信号并将其调整为 DCM 模块给定的值
### 5.5 文件结构（File structure）
#### 5.5.1 代码文件结构（Code file structure）
**[SWS_IoHwAb_00099]** ⌈代码文件结构不应在本规范中完全定义。应指出代码文件结构应包括用于后构建配置的 IoHwAb_PBcfg.c。⌋
#### 5.5.2 头文件结构（Header file structure）
**[SWS_IoHwAb_00100]** ⌈IoHwAb.c 应包含 IoHwAb.h 和 Det.h。⌋
---
## 6 需求可追溯性（Requirements traceability）
> **摘要说明：** 本节列出 I/O 硬件抽象需求与实现需求的对应关系。完整可追溯性表见原文 PDF（第 18-22 页）。
>
> 主要需求映射：
>
> - **SWS_IoHwAb_00002、00007-00011**（信号属性、范围、分辨率、同步、生命周期、延迟、滤波、采样率、变化报告、脉冲测试）
> - **SWS_IoHwAb_00021-00023**（诊断功能：短路、开路、过载、过温检测）
> - **SWS_IoHwAb_00059-00061**（Init 函数）
> - **SWS_IoHwAb_00081-00097**（SW-C 模板使用）
> - **SWS_IoHwAb_00102-00107**（回调通知）
> - **SWS_IoHwAb_00108-00114**（调度概念）
> - **SWS_IoHwAb_00119-00120**（Init 和 GetVersionInfo API）
> - **SWS_IoHwAb_00121-00124、00155-00156**（ADC、PWM、ICU、GPT、OCU 通知回调）
> - **SWS_IoHwAb_00135-00144**（DCM 诊断接口）
> - **SWS_IoHwAb_00146-00147**（电源状态准备与进入）
> - **SWS_IoHwAb_00154**（ADC 电源状态通知）
> - **SWS_IoHwAb_00157-00158**（配置类型）
---
## 7 功能规范（Functional specification）
### 7.1 集成代码（Integration code）
#### 7.1.1 背景与原理（Background & Rationale）
集成代码是 I/O 硬件抽象层的一部分，用于将 MCAL 驱动程序调用与软件组件的接口（端口）粘合在一起。集成代码的主要作用是：
- 将 ECU 信号映射到底层 MCAL 通道
- 实现属性转换（范围、分辨率、生命周期、延迟、滤波、采样率）
- 处理同步、变化报告、脉冲测试等高级功能
- 提供诊断信息
- 实现电源状态管理
#### 7.1.2 集成代码实现的需求（Requirements for integration code implementation）
> **摘要说明：** 集成代码实现应遵循：
> - ECU 信号应在配置时映射到 MCAL 通道
> - 属性转换应在集成代码中实现，而不是 MCAL 驱动中
> - 集成代码应负责信号缓冲、去抖、滤波等
> - 集成代码应支持同步和异步数据采集
> - 集成代码应将检测到的故障传递给 DEM
### 7.2 ECU 信号概念（ECU Signals Concept）
#### 7.2.1 背景与原理（Background & Rationale）
ECU 信号是软件组件与 I/O 硬件抽象层交换数据的单位。每个 ECU 信号：
- 由符号名称标识
- 具有数据类型（电压、电流、电阻、布尔、占空比等）
- 具有范围（最小值、最大值）
- 具有分辨率（最小可表示步长）
- 可能具有同步、生命周期、延迟、滤波、采样率等属性
#### 7.2.2 关于 ECU 信号的需求（Requirements about ECU signals）
> **摘要说明：** ECU 信号应满足以下需求：
> - ECU 信号应具有唯一的符号名称
> - 数据类型应使用 AUTOSAR 标准类型
> - 范围应在配置时定义
> - ECU 信号应对应一个或多个底层 MCAL 通道
> - ECU 信号应在集成代码中实现从物理值到工程单位的转换
### 7.3 属性（Attributes）
#### 7.3.1 背景与原理（Background & Rationale）
属性定义了 ECU 信号的特征。不同的信号类型（模拟输入、模拟输出、离散输入、离散输出、周期输入、占空比输入/输出）适用不同的属性集。
#### 7.3.2 关于 ECU 信号属性的需求（Requirements about ECU signal attributes）
> **摘要说明：** ECU 信号属性应满足以下需求：
> - DataType、Range、Resolution、HW Resolution、HW Accuracy、Synchronization、Access、Inversion、Lifetime/Delay、Filtering/Debouncing、Sampling Rate、Report Changes、Pulse Test、Diagnosis 等属性应在配置时定义
> - 属性转换应在集成代码中实现
> - 属性的存在性应取决于信号类型
### 7.4 I/O 硬件抽象和软件组件模板（I/O Hardware Abstraction and Software Component Template）
#### 7.4.1 背景与原理（Background & Rationale）
I/O 硬件抽象层应使用 AUTOSAR 软件组件模板定义其接口。每个 I/O 硬件抽象模块对应一个 SW-C 模板组件。
#### 7.4.2 关于使用软件组件模板的需求（Requirements about the usage of Software Component template）
> **摘要说明：** 主要需求：
> - 每个 I/O 硬件抽象模块应定义为 SW-C 模板的"应用"类型组件
> - 接口应为 Sender-Receiver 或 Client-Server
> - 应使用 PortGroup 来组织相关端口
> - 模式声明和模式切换接口应用于电源状态管理
### 7.5 I/O 硬件抽象的调度概念（Scheduling concept for I/O Hardware Abstraction）
#### 7.5.1 背景与原理（Background & Rationale）
I/O 硬件抽象层可能需要调度函数来处理周期性任务（如 ADC 读取、信号去抖、滤波等）。调度函数由 BSW Scheduler 直接调用。
#### 7.5.2 关于 I/O 硬件抽象调度概念的需求（Requirements about I/O Hardware Abstraction Scheduling concept）
> **摘要说明：** 调度函数应满足以下需求：
> - 调度函数没有返回值和参数
> - 所有调度函数应为 Non-Reentrant
> - 调度函数的调用周期应在配置时定义
> - 调度函数可以处理 ECU 信号读取、属性转换、状态机等
### 7.6 错误分类（Error Classification）
#### 7.6.1 开发错误（Development Errors）
**[SWS_IoHwAb_00170]** ⌈开发错误类型：IOHWAB_E_UNINIT（在 API 在 I/O 硬件抽象未初始化时调用时报告）。⌋
#### 7.6.2 运行时错误（Runtime Errors）
无。
#### 7.6.3 瞬态故障（Transient Faults）
无。
#### 7.6.4 生产错误（Production Errors）
**[SWS_IoHwAb_00171]** ⌈生产错误类型：IOHWAB_E_HW_FAILURE、IOHWAB_E_SIGNAL_INVALID 等（详见原文 PDF）。⌋
#### 7.6.5 扩展的生产错误（Extended Production Errors）
> **摘要说明：** 扩展的生产错误由生产错误工作组推荐，详见原文 PDF。
### 7.7 其他需求（Other requirements）
无附加需求。
### 7.8 错误检测（Error Detection）
> **摘要说明：** 错误检测通过配置开关控制。
### 7.9 错误通知（Error notification）
> **摘要说明：** 检测到的开发错误通过 DET 报告，生产错误通过 DEM 报告。
### 7.10 I/O 硬件抽象层描述（I/O Hardware Abstraction layer description）
#### 7.10.1 背景与原理（Background & Rationale）
I/O 硬件抽象层描述应包含每个模块的功能描述、接口定义、配置参数等。
#### 7.10.2 需求（Requirements）
> **摘要说明：** I/O 硬件抽象层描述应满足以下需求：
> - 应为每个 I/O 硬件抽象模块提供 BSW 模块描述
> - 应列出所有 ECU 信号及其属性
> - 应列出所有端口和接口
> - 应列出所有配置参数
### 7.11 示例（Examples）
#### 7.11.1 示例 1：板载硬件用例（Use case of on-board hardware）
本示例源自电源 ECU：
- ECU 具有大量数字输入（DI）
- 一组是用于机械开关的"慢速 DI"
- 另一组是用于功率 IC 诊断的"快速 DI"
- MCU 引脚不够，慢速 DI 连接到 8 位多路复用器
- 最大"过流"到功率 IC 切换时间为 1 ms
- OEM 要求开关反应不超过 100 ms
- 每个 DI 必须通过 3/5 投票去抖
**解决方案：**
- 所有 DI（慢速和快速）每 0.8 ms 读取一次（循环任务）
- 慢速 DI 的去抖在每次循环中执行一次（最坏情况下去抖值的延迟为 3.2 ms）
- 如果检测到过流，引脚将在同一循环中再次读取几次，并立即关闭功率 IC
- 应用程序每 10 ms 运行一次，读取用于开关的去抖 DI 和诊断信息
**AUTOSAR 架构分解：**
| 层 | 多路复用 I/O | 功率 IC |
|---|---|---|
| Application | Runnable 每 10 ms 读取数据 | 如果功率 IC 检测到过流则获得通知 |
| RTE | 处理 runnables | |
| I/O Hardware Abstraction | 8 个信号映射到端口，端口特征定义和 Client/Server 接口，信号抽象提供去抖时间（优于去抖投票规则），循环任务通过 DIO 服务调用执行输入读取 | I/O 硬件抽象决定在检测到过流时关闭功率 IC（在外部 ASIC 的驱动中），循环任务通过 DIO 服务调用执行输入读取 |
| MCAL driver | DIO driver：地址线、1 条数据线 | DIO driver：来自功率 IC 的 1 条反馈线；PWM driver：1 条到功率 IC 的线 |
| ECU hardware | 多路复用器：8 个电气信号的映射 | 功率 IC：控制多路复用器的电源 |
#### 7.11.2 示例 2：故障监控用例（Use case of failure monitoring）
在本例中，应在 I/O 硬件抽象层上定义具有诊断属性的诊断输出信号。因此，使用输入来执行输出的诊断。
当 I/O 硬件抽象请求定位一个输出（Dio_WriteChannel）时，通过配置为输入的 ECU 引脚读取通道。
ICU 驱动向 I/O 硬件抽象发送通知。保护策略位于集成代码中。
软件组件可以通过端口使用诊断操作获取诊断值。
#### 7.11.3 示例 3：输出功率级（Output power stage）
ECU 硬件具有功率级 ASIC。因此，所有 ECU 引脚应作为"信号"在 I/O 硬件抽象层上可用（就在 RTE 之下）。
- 一些输出通过 SPI driver/handler 控制
- 一些输入直接通过 DIO driver 控制
- 一些电压、频率通过 PWM driver 设置
- 功率级驱动提供所有输出的视图。它调用 PWM、DIO drivers 和 SPI handler 的服务。信号抽象使所有这些输出从软件组件的角度"可见"（信号映射到端口）。"功率级驱动"可以配置。
**诊断：** 每个故障可以在功率级上检测到。诊断数据流通过 SPI 通信到功率级驱动，然后，诊断通过 S/R 接口提供给所有软件组件。
#### 7.11.4 示例 4：在低功耗状态下设置传感器和控制外设（Setting sensor and controlling periphery in low power state）
ECU 通过其 ADC 和 DIO 外设控制传感器。在特定情况下，ECU 进入操作模式，其中传感器关闭，ADC 设置为低功耗状态。
**动作序列如下：**
1. 应用程序电源模式管理器向 BswM 发出模式请求以切换到"LowPowerMode"。
2. BswM 评估请求，如果所有先决条件都满足，则向电源模式管理器和传感器 SWC 发出模式切换。
3. 传感器 SWC 停止读取感官数据（即不再向 IoHwAbs 请求任何 Get 操作）。
4. IoHwAbs 从 ADC 注销其通知，并最终停止 HW 循环采集。
5. IoHwAbs 将外部感官 HW 命令进入低功耗模式或关闭。
6. IoHwAbs 调用其低功耗模式准备 Callouts，然后调用其低功耗模式设置 Callouts，如配置所定义，以获得与请求的应用程序低功耗模式"LowPowerMode"相关的 ADC（在这种情况下）电源状态。
可以通过引入更细粒度的模式请求并对确认和/或切换做出反应来逐步控制该过程。
---
## 8 API 规范（API specification）
### 8.1 导入类型（Imported types）
**[SWS_IoHwAb_91000]** ⌈
| 模块 | 头文件 | 导入类型 |
|---|---|---|
| Adc | Adc.h | Adc_GroupType, Adc_StatusType, Adc_StreamNumSampleType, Adc_ValueGroupType |
| Dio | Dio.h | Dio_ChannelGroupType, Dio_ChannelType, Dio_LevelType, Dio_PortLevelType, Dio_PortType |
| EcuM | EcuM.h | EcuM_WakeupSourceType |
| GENERIC TYPES | | `<EcuSignalDataType>` |
| Gpt | Gpt.h | Gpt_ChannelType, Gpt_ModeType, Gpt_ValueType |
| Icu | Icu.h | Icu_ActivationType, Icu_ChannelType, Icu_DutyCycleType, Icu_EdgeNumberType, Icu_IndexType, Icu_InputStateType, Icu_ValueType |
| Ocu | Ocu.h | Ocu_ChannelType, Ocu_PinStateType, Ocu_ReturnType, Ocu_ValueType |
| Port | Port.h | Port_PinDirectionType, Port_PinModeType, Port_PinType |
| Pwm | Pwm.h | Pwm_ChannelType, Pwm_EdgeNotificationType, Pwm_OutputStateType, Pwm_PeriodType |
| Spi | Spi.h | Spi_AsyncModeType, Spi_ChannelType, Spi_DataBufferType, Spi_HWUnitType, Spi_JobResultType, Spi_JobType, Spi_NumberOfDataType, Spi_SeqResultType, Spi_SequenceType, Spi_StatusType |
| Std_Types | StandardTypes.h | Std_ReturnType, Std_VersionInfoType |
⌋
### 8.2 类型定义（Type definitions）
#### 8.2.1 IoHwAb<Init_Id>_ConfigType
**[SWS_IoHwAb_00157]** ⌈
| 字段 | 内容 |
|---|---|
| Name | IoHwAb<Init_Id>_ConfigType |
| Type | Structure（实现特定） |
| Description | IoHwAb 模块的配置数据结构。 |
| Available via | IoHwAb.h |
⌋ (SRS_BSW_00414)
### 8.3 函数定义（Function definitions）
**关于 I/O 硬件抽象的注释：**
如前面章节所述，不会为 I/O 硬件抽象指定功能 API。I/O 硬件抽象的接口完全通过 AUTOSAR 端口定义（使用 SW-C 模板）。
#### 8.3.1 IoHwAb_Init<Init_Id>
**[SWS_IoHwAb_00119]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | IoHwAb_Init<Init_Id> |
| Syntax | `void IoHwAb_Init<Init_Id>(const IoHwAb<Init_Id>_ConfigType* ConfigPtr)` |
| Service ID[hex] | 0x01 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | ConfigPtr - 指向所选配置集的指针 |
| Description | 初始化所有 I/O 硬件抽象软件或 I/O 硬件抽象的一部分。 |
| Available via | IoHwAb.h |
⌋ ()
**[SWS_IoHwAb_00158]** ⌈配置指针 ConfigPtr 应始终具有 NULL_PTR 值。⌋ (SRS_BSW_00414)
**注释：** 配置指针 ConfigPtr 当前未使用，因此应设置为 NULL_PTR 值。
**[SWS_IoHwAb_00059]** ⌈这种函数初始化所有 I/O 硬件抽象软件或 I/O 硬件抽象的一部分。⌋ (SRS_BSW_00101)
**[SWS_IoHwAb_00060]** ⌈I/O 硬件抽象软件管理的 I/O 设备的 multiplicity 应通过多个 init 函数处理。每个 init 函数应用 `<Init_ID>` 标记。因此，具有封装在 I/O 硬件抽象内的驱动程序的外部设备可以单独初始化。⌋ (SRS_BSW_00101)
**[SWS_IoHwAb_00061]** ⌈这种 init 函数应由 ECU 状态管理器调用。ECU 集成商能够配置 ECU 状态管理器调用的初始化序列顺序。⌋ (SRS_BSW_00101)
**[SWS_IoHwAb_00102]** ⌈完成模块初始化后，I/O 硬件抽象状态应设置为 IOHWAB_IDLE，作业结果应设置为 IOHWAB_JOB_OK。⌋ (SRS_BSW_00441)
#### 8.3.2 IoHwAb_GetVersionInfo
**[SWS_IoHwAb_00120]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | IoHwAb_GetVersionInfo |
| Syntax | `void IoHwAb_GetVersionInfo(Std_VersionInfoType* versioninfo)` |
| Service ID[hex] | 0x10 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant |
| Parameters (out) | versioninfo - 指向存储此 I/O 硬件抽象实现版本信息的变量的指针 |
| Description | 返回此模块的版本信息。 |
| Available via | IoHwAb.h |
⌋ ()
### 8.4 回调通知（Call-back notifications）
本节列出了为下层模块提供的函数。
#### 8.4.1 IoHwAb_AdcNotification<#groupID>
**[SWS_IoHwAb_00121]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | IoHwAb_AdcNotification<#groupID> |
| Syntax | `void IoHwAb_AdcNotification<#groupID>(void)` |
| Service ID[hex] | 0x20 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Description | 当 ADC 驱动完成组 `<#groupID>` 的组转换时，将由 ADC 驱动调用。 |
| Available via | IoHwAb_Adc.h |
⌋ ()
**[SWS_IoHwAb_00104]** ⌈函数 IoHwAb_AdcNotification<#groupID> 旨在由 ADC 驱动在完成组 `<#groupID>` 的组转换时调用。⌋ ()
#### 8.4.2 IoHwAb_Pwm_Notification<#channel>
**[SWS_IoHwAb_00122]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | IoHwAb_PwmNotification<#channel> |
| Syntax | `void IoHwAb_PwmNotification<#channel>(void)` |
| Service ID[hex] | 0x30 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Description | 当 PWM 通道 `<#channel>` 上发生信号边沿时，将由 PWM 驱动调用。 |
| Available via | IoHwAb_Pwm.h |
⌋ ()
**[SWS_IoHwAb_00105]** ⌈函数 IoHwAb_PwmNotification<#channel> 旨在由 PWM 驱动在通道 `<#channel>` 上发生信号边沿时调用。⌋ ()
#### 8.4.3 IoHwAb_IcuNotification<#channel>
**[SWS_IoHwAb_00123]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | IoHwAb_IcuNotification<#channel> |
| Syntax | `void IoHwAb_IcuNotification<#channel>(void)` |
| Service ID[hex] | 0x40 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Description | 当 ICU 通道 `<#channel>` 上发生信号边沿时，将由 ICU 驱动调用。 |
| Available via | IoHwAb_Icu.h |
⌋ ()
**[SWS_IoHwAb_00106]** ⌈函数 IoHwAb_IcuNotification<#channel> 旨在由 ICU 驱动在通道 `<#channel>` 上发生信号边沿时调用。⌋ ()
#### 8.4.4 IoHwAb_GptNotification<#channel>
**[SWS_IoHwAb_00124]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | IoHwAb_GptNotification<#channel> |
| Syntax | `void IoHwAb_GptNotification<#channel>(void)` |
| Service ID[hex] | 0x50 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Description | 当 GPT 通道 `<#channel>` 上定时器值到期时，将由 GPT 驱动调用。 |
| Available via | IoHwAb_Gpt.h |
⌋ ()
**[SWS_IoHwAb_00107]** ⌈函数 IoHwAb_GptNotification<#channel> 旨在由 GPT 驱动在通道 `<#channel>` 上定时器值到期时调用。⌋ ()
#### 8.4.5 IoHwAb_OcuNotification<#channel>
**[SWS_IoHwAb_00155]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | IoHwAb_OcuNotification<#channel> |
| Syntax | `void IoHwAb_OcuNotification<#channel>(void)` |
| Service ID[hex] | 0xa0 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Description | 当计数器的当前值与通道 `<#channel>` 上的阈值匹配时，将由 OCU 驱动调用。 |
| Available via | IoHwAb_Ocu.h |
⌋ ()
**[SWS_IoHwAb_00156]** ⌈函数 IoHwAb_OcuNotification<#channel> 旨在由 OCU 驱动在通道 `<#channel>` 上计数器的当前值与阈值匹配时调用。⌋ ()
#### 8.4.6 IoHwAb_Pwm_NotifyReadyForPowerState<#MODE>
**[SWS_Pwm_00198]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | IoHwAb_Pwm_NotifyReadyForPowerState<#Mode> |
| Syntax | `void IoHwAb_Pwm_NotifyReadyForPowerState<#Mode>(void)` |
| Service ID[hex] | 0x60 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Description | 当模式 `<#Mode>` 的请求电源状态准备完成时，应由 PWM 驱动调用。 |
| Available via | IoHwAb_Pwm.h |
⌋ ()
**注释：** 如果 PWM 驱动配置为支持异步模式的电源状态控制，则需要由 CDD 或 IoHwAbs 提供的此接口。
#### 8.4.7 IoHwAb_Adc_NotifyReadyForPowerState<#MODE>
**[SWS_IoHwAb_00154]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | IoHwAb_Adc_NotifyReadyForPowerState<#Mode> |
| Syntax | `void IoHwAb_Adc_NotifyReadyForPowerState<#Mode>(void)` |
| Service ID[hex] | 0x70 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Description | 当模式 `<#Mode>` 的请求电源状态准备完成时，应由 ADC 驱动调用。 |
| Available via | IoHwAb_Adc.h |
⌋ ()
**注释：** 如果 ADC 驱动配置为支持异步模式的电源状态控制，则需要由 CDD 或 IoHwAbs 提供的此接口。
### 8.5 计划函数（Scheduled functions）
这些函数由基础软件调度器直接调用。以下函数应没有返回值和参数。所有函数应为 Non-Reentrant。
#### 8.5.1 <Name of scheduled function>
| 字段 | 内容 |
|---|---|
| Service name | `<Name of API call>` |
| Service ID [hex] | `<Number of service ID. 此 ID 用作默认错误跟踪器错误报告 API 的参数。ID 不应等于第 0 章中的 ID>` |
| Description | `<包含定义此 API 调用操作的 ID 的本地软件需求集。>` |
| Timing | `<fixed cyclic / variable cyclic / on pre condition>` |
| Pre condition | `<关于 API 调用必须操作的环境的假设列表。>` |
| Configuration | `<描述影响此 API 调用的静态可配置属性。例如固定周期时序的周期时间。>` |
### 8.6 功能诊断接口（Functional Diagnostics Interface）
本章描述 I/O 硬件抽象向 DCM 模块提供的接口，以实现"软件组件的功能诊断"。
"软件组件的功能诊断"意味着，通过提供的接口，DCM 模块能够控制和读取每个已实现的 ECU 信号。
#### 8.6.1 IoHwAb_Dcm_<EcuSignalName>
**[SWS_IoHwAb_00135]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | IoHwAb_Dcm_<EcuSignalName> |
| Syntax | `void IoHwAb_Dcm_<EcuSignalName>(uint8 action, <EcuSignalDataType> signal)` |
| Description | 此函数为 DCM 模块提供对特定 ECU 信号的访问控制（`<EcuSignalname>` 是 ECU 信号的符号名称）。可以通过此函数锁定和解锁 ECU 信号。锁定将 ECU 信号"冻结"为当前值、配置的默认值或由参数"signal"给定的值。 |
| Available via | IoHwAb_Dcm.h |
⌋ (SRS_IoHwAb_00002)
| 参数 | 值 |
|---|---|
| action（输入） | IOHWAB_RETURNCONTROLTOECU：解锁信号<br>IOHWAB_RESETTODEFAULT：锁定信号并将其设置为配置的默认值<br>IOHWAB_FREEZECURRENTSTATE：锁定信号到当前值<br>IOHWAB_SHORTTERMADJUSTMENT：锁定信号并将其调整为 DCM 模块给定的值 |
| signal（输入） | 调整信号的值（仅用于"短期调整"） |
**[SWS_IoHwAb_00136]** ⌈此函数允许控制关联的 ECU 信号，即可以锁定、解锁 ECU 信号并将其调整为某个值。⌋ (SRS_IoHwAb_00002)
**[SWS_IoHwAb_00138]** ⌈此函数应可预编译时间配置 On/Off。⌋ (SRS_IoHwAb_00002)
**锁定信号**意味着某个信号在软件上锁定到 SW-C，即 SW-C 的请求在锁定状态下对硬件没有影响。如果对输入信号使用 C/S 通信，可能有必要具有 IoHwAb 内部缓冲区，其值可由 DCM 调整。
#### 8.6.2 IoHwAb_Dcm_Read<EcuSignalName>
**[SWS_IoHwAb_00139]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | IoHwAb_Dcm_Read<EcuSignalName> |
| Syntax | `void IoHwAb_Dcm_Read<EcuSignalName>(<EcuSignalDataType>* signal)` |
| Parameters (out) | signal - 指向应存储当前信号值的变量的指针 |
| Description | 此函数为 DCM 模块提供对特定 ECU 信号的读取访问（`<EcuSignalname>` 是 ECU 信号的符号名称）。 |
| Available via | IoHwAb_Dcm.h |
⌋ (SRS_IoHwAb_00002)
**[SWS_IoHwAb_00140]** ⌈此函数为 DCM 模块提供对特定 ECU 信号的读取访问。读取访问独立于 ECU 信号的当前状态（锁定/未锁定），应始终从硬件读取当前物理值。⌋ (SRS_IoHwAb_00002)
**[SWS_IoHwAb_00142]** ⌈此函数应可预编译时间配置 On/Off。⌋ (SRS_IoHwAb_00002)
### 8.7 电源状态函数（Power State Functions）
#### 8.7.1 IoHwAb_PreparePowerState<#MODE>
**[SWS_IoHwAb_00146]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | IoHwAb_PreparePowerState<#Mode> |
| Syntax | `void IoHwAb_PreparePowerState<#Mode>(void)` |
| Service ID[hex] | 0x80 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Description | 准备与模式 `<#Mode>` 关联的外设的电源状态转换。 |
| Available via | IoHwAb.h |
⌋ ()
#### 8.7.2 IoHwAb_EnterPowerState<#MODE>
> **摘要说明：** IoHwAb_EnterPowerState<#Mode> 用于执行实际的外设电源状态转换。
>
> 详细需求 SWS_IoHwAb_00147 见原文 PDF（第 49 页）。
### 8.8 预期接口（Expected Interfaces）
#### 8.8.1 强制接口（Mandatory Interfaces）
> **摘要说明：** I/O 硬件抽象的强制接口包括来自 MCAL 驱动程序的多个 API：
>
> | 源模块 | API | 用途 |
> |---|---|---|
> | Adc | Adc_Init, Adc_DeInit, Adc_StartGroupConversion, Adc_ReadGroup, Adc_EnableHardwareTrigger, Adc_DisableHardwareTrigger 等 | ADC 操作 |
> | Dio | Dio_ReadChannel, Dio_WriteChannel, Dio_ReadPort, Dio_WritePort 等 | DIO 操作 |
> | Gpt | Gpt_StartTimer, Gpt_StopTimer, Gpt_EnableNotification 等 | GPT 操作 |
> | Icu | Icu_Init, Icu_SetMode, Icu_EnableNotification, Icu_StartTimestamp 等 | ICU 操作 |
> | Ocu | Ocu_Init, Ocu_StartChannel, Ocu_StopChannel 等 | OCU 操作 |
> | Pwm | Pwm_Init, Pwm_SetDutyCycle, Pwm_SetPeriodAndDuty 等 | PWM 操作 |
> | Port | Port_Init, Port_SetPinDirection, Port_SetPinMode 等 | Port 操作 |
> | Spi | Spi_Init, Spi_AsyncTransmit, Spi_ReadIB, Spi_WriteIB 等 | SPI 操作 |
>
> *完整列表见原文 PDF（第 49-52 页）。*
#### 8.8.2 可选接口（Optional Interfaces）
无附加可选接口。
#### 8.8.3 作业结束通知（Job End Notification）
> **摘要说明：** I/O 硬件抽象可以提供作业结束通知接口，以允许异步通信（SPI、ADC 流等）。
---
## 9 序列图（Sequence diagrams）
> **摘要说明：** 本节包含以下序列图：
>
> 1. **ECU-signal provided by the I/O Hardware Abstraction (example)** - 示例 ECU 信号提供流程
> 2. **Setting ADC and PWM in a low consumption power state as a result of a request for an application low power mode (example)** - 低功耗模式下的 ADC 和 PWM 设置流程
>
> *完整序列图见原文 PDF（第 53-56 页）。*
---
## 10 配置规范（Configuration specification）
### 10.1 发布信息（Published Information）
> **摘要说明：** I/O 硬件抽象的发布信息包括：
> - 版本号
> - 供应商 ID
> - 模块 ID
> - 编译开关信息
> - 与底层 MCAL 驱动程序的依赖关系
---
## 11 不适用需求（Not applicable requirements）
> **摘要说明：** 本节列出了不适用于 I/O 硬件抽象的需求。
---
## 翻译说明
本文档为 AUTOSAR 4.4.0 版本 I/O 硬件抽象规范的中文翻译。保留了所有需求 ID（SWS_IoHwAb_xxxxx）、参考标识符及模块缩写。原始文档共 58 页，本翻译涵盖了全部主要章节，并对大型可追溯性表采用了"重点翻译+摘要"策略，标注"完整表见原文 PDF"的位置以便用户查阅原文。I/O 硬件抽象层提供基于信号的接口，向上层抽象出 ECU 硬件的信号路径。
IO/AUTOSAR_SWS_OCUDriver.md
+931
View File
@@ -0,0 +1,931 @@
# OCU 驱动规范（Specification of OCU Driver）
> **AUTOSAR CP Release 4.4.0**
## 文档元信息
| 字段 | 内容 |
|---|---|
| **文档标题** | OCU 驱动规范（Specification of OCU Driver） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 615 |
| **文档状态** | Final（最终版） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 移除 OcuGroup（ECUC_Ocu_00161、ECUC_Ocu_00162、ECUC_Ocu_00163）；更新头文件结构；多核特性（SWS_Ocu_00170、SWS_Ocu_CONSTR_00001、SWS_Ocu_CONSTR_00002） |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | OcuGroup 设为过时（ECUC_Ocu_00161、ECUC_Ocu_00162 和 ECUC_Ocu_00163）；将"默认错误检测"重命名为"开发错误检测" |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 移除 SWS_Ocu_00134 和 SWS_Ocu_00135；将"SRS_BSW_000386"重命名为"SRS_BSW_00386"；移除 SRS_BSW_00157、SRS_BSW_00326、SRS_BSW_00329、SRS_BSW_00338、SRS_BSW_00355、SRS_BSW_00370、SRS_BSW_00376、SRS_BSW_00434、SRS_BSW_0431；将"SRS_SPAL12448"更改为"SRS_SPAL_12448" |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | DET 已重命名；SWS_Ocu_00041 和 SWS_Ocu_00042 需求已移除；OCU_E_PARAM_CONFIG 已移除；新增 OCU_E_INIT_FAILED；无效的需求 ID：已更新 SWS_Ocu_156、SWS_Ocu_169 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 将 postBuildVariantValue 和 postBuildVariantMultiplicity 设置为 false，并将所有变体的 valueConfigClass 和 multiplicityConfigClass 设置为 preCompile；移除自动支持的 BSW 需求；对 SWS_BSW_00380 的引用已移除 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 文档结构的细微更新；编辑性变更；移除了关于变更文档的章节 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 初始发布 |
---
## 目录（Table of Contents）
1. [引言与功能概述（Introduction and functional overview）](#1-引言与功能概述)
2. [缩略语与缩写（Acronyms and abbreviations）](#2-缩略语与缩写)
3. [相关文档（Related documentation）](#3-相关文档)
4. [约束与假设（Constraints and assumptions）](#4-约束与假设)
5. [对其他模块的依赖（Dependencies to other modules）](#5-对其他模块的依赖)
6. [需求可追溯性（Requirements traceability）](#6-需求可追溯性)
7. [功能规范（Functional specification）](#7-功能规范)
8. [API 规范（API specification）](#8-api-规范)
9. [序列图与时序图（Sequence and Timing diagrams）](#9-序列图与时序图)
10. [配置规范（Configuration specification）](#10-配置规范)
11. [不适用需求（Not applicable requirements）](#11-不适用需求)
---
## 1 引言与功能概述（Introduction and functional overview）
本规范规定了 AUTOSAR 基础软件模块 OCU 驱动的功能、API 和配置。
每个 OCU 软件通道链接到属于微控制器的硬件 OCU 外设。可以选择性地将输出引脚附加到此通道。
驱动提供用于初始化和控制微控制器内部 OCU 功能（输出比较单元）的功能。OCU 驱动允许在计数器值与定义的阈值匹配时自动比较和执行动作。OCU 驱动为以下提供服务和配置参数：
- 启动和停止比较过程
- 设置比较阈值
- 启用和禁用通知机制
- 获取计数器值
- 更改输出引脚状态
- 触发某些硬件资源（如果可用，包括 ADC、DMA）
通道计数器的 tick 持续时间取决于通道特定设置（OCU 驱动的一部分）以及由 MCU 模块控制的系统时钟和时钟树设置。本规范不限制 tick 持续时间。
某些微控制器没有专用的 OCU 硬件单元，而是具有可配置的通用定时器模块，可提供 OCU 功能以及其他定时器功能。本规范不假设硬件架构。相反，它定义了参数和 API，以便可以在任何合适的硬件架构上实现。下图显示了 OCU 通道的典型表示：
```
Free running counter（自由运行计数器）
OUTPUT
Comparison threshold（比较阈值）
```
**图 1：OCU 通道的抽象视图**
"output" 是在比较匹配时实际执行的动作。
---
## 2 缩略语与缩写（Acronyms and abbreviations）
| 缩略语/缩写 | 描述 |
|---|---|
| OCU | 输出比较单元（Output Compare Unit） |
| DMA | 直接内存访问（Direct Memory Access） |
| MCAL | 微控制器抽象层（Microcontroller Abstraction Layer） |
| MCU | 微控制器单元（Microcontroller Unit） |
| DEM | 诊断事件管理器（Diagnostic Event Manager） |
| DET | 默认错误跟踪器（Default Error Tracer） |
| SPAL | 标准外设抽象层（Standard Peripheral Abstraction Layer） |
| ISR | 中断服务例程（Interrupt Service Routine） |
**术语定义：**
| 术语 | 描述 |
|---|---|
| OCU channel | 表示由自由运行计数器、比较阈值以及作为比较过程结果所执行的动作组成的逻辑实体。 |
| Compare threshold（比较阈值） | 每次计数器增加一个单位时与计数器内容进行比较的目标值。 |
| Free running counter（自由运行计数器） | 从最小值（或最大值）运行到最大值（或最小值）的计数器，并在达到最大值（或最小值）后自动从最小值（或最大值）重新启动的计数器。 |
| Reference Interval（参考间隔） | Ocu_SetAbsolutThreshold API 调用方以 ticks 为单位给定的间隔，用作计算返回信息的基础。 |
---
## 3 相关文档（Related documentation）
### 3.1 输入文档（Input documents）
- **[1]** 分层软件架构，AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
- **[2]** SPAL 的一般需求，AUTOSAR_SRS_SPALGeneral.pdf
- **[3]** 基础软件模块的一般需求，AUTOSAR_SRS_BSWGeneral.pdf
- **[4]** 默认错误跟踪器规范，AUTOSAR_SWS_DefaultErrorTracer.pdf
- **[5]** MCU 驱动规范，AUTOSAR_SWS_MCUDriver.pdf
- **[6]** ECU 配置规范，AUTOSAR_TPS_ECUConfiguration.pdf
- **[7]** 基础软件模块描述模板，AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
- **[8]** 基础软件模块列表，AUTOSAR_TR_BSWModuleList.pdf
---
## 4 约束与假设（Constraints and assumptions）
### 4.1 假设（Assumptions）
#### 4.1.1 时钟（Clock）
驱动不支持时钟的动态更改。
由于系统时钟完全由 MCU 模块管理，因此系统时钟设置中的任何动态更改都会影响此模块。
该模块不在睡眠模式下运行。
#### 4.1.2 资源（Resources）
资源分配仅由 SW 或 HW 完成，以避免共享资源问题。
例如：API Ocu_SetPinState 的使用。不能对处于 RUNNING 状态的通道调用此 API 来更改引脚状态，否则硬件在比较匹配时自动设置的状态与 API 设置的状态之间可能存在冲突。
#### 4.1.3 计数与比较（Counting and comparing）
假设运行此驱动的硬件具有以下计数器抽象模型（以八位计数器为例）：
```
Free running up 0 1 2 3 … 253 254 255
counter
```
**图 2：此驱动自由运行计数器的抽象模型**
- 最小值为 0
- 最大值为 255
- 当计数器超过最大值时，它将重新加载为 0。这意味着它有 256 个计数步骤。
由于计数的量化，在将计数器内容与阈值进行比较时存在两种不同的情况。比较可以在进入计数器状态时发生，也可以在退出状态时发生，如下图所示：
```
Free running counter … 34 35 36 37 38 39
…
Compare threshold 35
Or
Free running counter … 34 35 36 37 38 39
…
Compare threshold 35
```
**图 3：驱动中预期的比较过程抽象模型**
此驱动的预期行为是在进入由阈值表示的状态时进行比较。
### 4.2 限制（Limitations）
无限制。
### 4.3 对汽车领域的适用性（Applicability to car domains）
无限制。
---
## 5 对其他模块的依赖（Dependencies to other modules）
### 模块 DET
如果为 OCU 驱动启用了开发错误检测，则每当此模块遇到开发错误时，驱动应将错误报告给默认错误跟踪器（DET）。
### 模块 DEM
OCU 驱动应将生产错误报告给诊断事件管理器（DEM）。
### 模块 MCU 驱动
微控制器单元驱动（MCU 驱动）主要负责初始化和控制芯片内部时钟源和时钟预分频器。OCU 依赖于系统时钟。因此，系统时钟的更改（例如 PLL on → PLL off）也会影响 OCU 硬件的时钟设置。
MCU 驱动将设置全局预分频器和 OCU 时钟。OCU 驱动不会在其初始化函数中负责设置配置全局时钟、全局预分频器和 PLL 的寄存器。这必须由 MCU 模块完成。OCU 驱动仅配置本地（OCU 外设特定）资源。
文档 [6] AUTOSAR_TPS_ECUConfiguration 包含章节"4.8 - 时钟树配置"，详细说明了向外设提供参考时钟信号的机制。
### 模块 PORT
用作 OCU 输出的端口引脚的配置由 PORT 驱动完成。因此，PORT 驱动必须在使用 OCU 功能之前进行初始化。
### 5.1 文件结构（File structure）
#### 5.1.1 代码文件结构（Code file structure）
**[SWS_Ocu_00001]** ⌈代码文件结构不应在本规范中完全定义。在这一点上，应指出代码文件结构应包括以下文件：
- Ocu_Lcfg.c – 用于链接时可配置参数
- Ocu_PBcfg.c – 用于后构建时可配置参数
这些文件应包含所有链接时和后构建时可配置参数。⌋ (SRS_BSW_00419, SRS_BSW_00346, SRS_BSW_00158, SRS_BSW_00314)
#### 5.1.2 头文件结构（Header file structure）
**[SWS_Ocu_00006]** ⌈Ocu.c 应包含 Ocu.h 和 Det.h。⌋ ()
---
## 6 需求可追溯性（Requirements traceability）
> **摘要说明：** 本节列出 BSW 和 SPAL 通用需求与 OCU 驱动特定需求（SWS_Ocu_xxxxx）的对应关系。完整可追溯性表见原文 PDF（第 12-21 页）。
>
> 关键映射：
> - SWS_Ocu_00012（版本检查宏）← SRS_BSW_00004
> - SWS_Ocu_00036（Init 函数）← SRS_BSW_00344, SRS_BSW_00404, SRS_BSW_00101, SRS_SPAL_12057
> - SWS_Ocu_00045（DeInit 函数）← SRS_Ocu_00005
> - SWS_Ocu_00051（StartChannel 函数）← SRS_Ocu_00008
> - SWS_Ocu_00058（StopChannel 函数）← SRS_Ocu_00008
> - SWS_Ocu_00066（SetPinState 函数）← SRS_Ocu_00011
> - SWS_Ocu_00076（SetPinAction 函数）← SRS_Ocu_00012
> - SWS_Ocu_00085（GetCounter 函数）← SRS_Ocu_00009
> - SWS_Ocu_00091（SetAbsoluteThreshold 函数）← SRS_Ocu_00010
> - SWS_Ocu_00094（SetAbsoluteThreshold 可配置 On/Off）← SRS_BSW_00171
> - SWS_Ocu_00103（SetRelativeThreshold 可配置 On/Off）
> - SWS_Ocu_00111（DisableNotification 可配置 On/Off）
> - SWS_Ocu_00118（EnableNotification 可配置 On/Off）
> - SWS_Ocu_00049（DeInit 可配置 On/Off）← SRS_BSW_00171
> - SWS_Ocu_00070（SetPinState 可配置 On/Off）← SRS_BSW_00171
> - SWS_Ocu_00079（SetPinAction 可配置 On/Off）← SRS_BSW_00171
> - SWS_Ocu_00088（GetCounter 可配置 On/Off）← SRS_BSW_00171
> - SWS_Ocu_00136（DeInit 停止所有自由运行计数器）← SRS_SPAL_12125
> - SWS_Ocu_00137（DeInit 错误检测：RUNNING 状态）
> - SWS_Ocu_00138（Ocu_ReturnType 定义）
> - SWS_Ocu_00156（模块文档/标识）← SRS_BSW_xxxxx 系列
> - SWS_Ocu_00170（多核特性约束）
> - SWS_Ocu_CONSTR_00001 / 00002（多核约束）
>
> 错误检测需求（SWS_Ocu_00043、00050、00055、00056、00057、00064、00065、00071、00072、00073、00074、00075、00080、00081、00082、00083、00089、00090、00095、00096 等）实现 OCU_E_UNINIT、OCU_E_BUSY、OCU_E_PARAM_INVALID_CHANNEL、OCU_E_PARAM_NO_PIN、OCU_E_PARAM_INVALID_STATE、OCU_E_PARAM_INVALID_ACTION 等开发错误。
---
## 7 功能规范（Functional specification）
### 7.1 一般行为（General behavior）
**[SWS_Ocu_00010]** ⌈如果 OCU 单元的自由运行计数器可被另一个定时器模块使用，则 Ocu 驱动不得启动或停止该自由运行计数器。⌋ (SRS_SPAL_12125)
**[SWS_Ocu_00011]** ⌈API Ocu_Init 应启动专由此驱动使用的所有自由运行计数器。⌋ (SRS_SPAL_12125)
**[SWS_Ocu_00018]** ⌈开发错误的检测在预编译时是可配置的（ON/OFF）。开关 OcuDevErrorDetectApi 应激活或取消激活所有开发错误的检测。⌋ (SRS_BSW_00369, SRS_BSW_00386)
**[SWS_Ocu_00019]** ⌈如果启用了开关 OcuDevErrorDetectApi，则启用 API 参数检查。有关检测错误的详细说明可以在错误分类和 API 规范章节中找到。⌋ (SRS_BSW_00386, SRS_BSW_00369, SRS_BSW_00339)
**[SWS_Ocu_00020]** ⌈生产错误的检测无法关闭。⌋ (SRS_BSW_00339)
### 7.2 版本检查（Version check）
#### 7.2.1 背景与原理（Background & Rationale）
有关版本检查的详细信息，请参阅 SWS_BSWGeneral 中的第 5.1.8"版本检查"章节。
### 7.3 时间单位 Ticks（Time Unit Ticks）
#### 7.3.1 背景与原理（Background & Rationale）
要从寄存器值中获取时间，必须知道振荡器频率、预分频器等。由于这些设置是在 MCU 和/或其他模块中进行的，因此无法计算此类时间。
因此，时间与 ticks 之间的转换应属于上层。
#### 7.3.2 需求（Requirements）
> **摘要：** OCU 驱动 API 服务中使用的所有时间单位应为 ticks。物理单位与 ticks 之间的转换由 ECU 抽象层负责。
### 7.4 错误分类（Error classification）
#### 7.4.1 开发错误（Development Errors）
**[SWS_Ocu_00013]** ⌈开发错误类型：OCU_E_PARAM_INVALID_CHANNEL（当使用无效的通道号调用 API 时报告）。⌋
**[SWS_Ocu_00014]** ⌈开发错误类型：OCU_E_PARAM_NO_PIN（当通道未配置关联引脚时报告）。⌋
**[SWS_Ocu_00015]** ⌈开发错误类型：OCU_E_PARAM_INVALID_STATE（当 API 在无效状态下调用时报告）。⌋
**[SWS_Ocu_00016]** ⌈开发错误类型：OCU_E_PARAM_INVALID_ACTION（当 Ocu_SetPinAction 的动作参数无效时报告）。⌋
**[SWS_Ocu_00017]** ⌈开发错误类型：OCU_E_BUSY（当对正在运行的通道调用 Ocu_StartChannel 时报告）。⌋
**[SWS_Ocu_00173]** ⌈开发错误类型：OCU_E_UNINIT（当 API 在 OCU 驱动未初始化时调用时报告）。⌋
**[SWS_Ocu_00174]** ⌈开发错误类型：OCU_E_ALREADY_INITIALIZED（当 Ocu_Init 在 OCU 驱动和硬件已初始化时调用时报告）。⌋
**[SWS_Ocu_00175]** ⌈开发错误类型：OCU_E_INIT_FAILED（当 OCU 驱动初始化失败时报告）。⌋
#### 7.4.2 运行时错误（Runtime Errors）
无。
#### 7.4.3 瞬态故障（Transient Faults）
无。
#### 7.4.4 生产错误（Production Errors）
本模块不指定任何生产错误。
### 7.5 错误检测（Error Detection）
参见 SWS_Ocu_00018、SWS_Ocu_00019、SWS_Ocu_00020。
### 7.6 错误通知（Error Notification）
**[SWS_Ocu_00021]** ⌈检测到的开发错误应使用默认错误跟踪器（DET）的服务 Det_ReportError 进行报告（如果设置了预处理器开关 OcuDevErrorDetectApi）。⌋ (SRS_BSW_00339)
### 7.7 调试支持（Debug Support）
**[SWS_Ocu_00023]** ⌈AUTOSAR 调试可访问的每个变量应定义为全局变量。⌋ ()
**[SWS_Ocu_00024]** ⌈应调试的变量的所有类型定义应可通过头文件 Ocu.h 访问。⌋ ()
**[SWS_Ocu_00025]** ⌈头文件中变量的声明应使得可以通过 C "sizeof" 计算变量的大小。⌋ ()
**[SWS_Ocu_00026]** ⌈可用于调试的变量应在相应的 OCU 驱动描述中描述。⌋ ()
---
## 8 API 规范（API specification）
### 8.1 导入类型（Imported types）
**[SWS_Ocu_00027]** ⌈
| 模块 | 头文件 | 导入类型 |
|---|---|---|
| Std_Types | StandardTypes.h | Std_ReturnType, Std_VersionInfoType |
⌋ ()
### 8.2 类型定义（Type definitions）
#### 8.2.1 Ocu_ChannelType
**[SWS_Ocu_00028]** ⌈
| 字段 | 内容 |
|---|---|
| Name | Ocu_ChannelType |
| Type | uint |
| Range | 8 / 16 / 32 位（实现特定） |
| Description | OCU 通道的数字标识符。 |
| Available via | Ocu.h |
⌋ ()
#### 8.2.2 Ocu_ValueType
**[SWS_Ocu_00029]** ⌈
| 字段 | 内容 |
|---|---|
| Name | Ocu_ValueType |
| Type | uint |
| Range | 8 / 16 / 32 位（实现特定） |
| Description | 用于读取计数器和写入阈值值的类型（以 ticks 数表示）。 |
| Available via | Ocu.h |
⌋ (SRS_SPAL_12063)
#### 8.2.3 Ocu_PinStateType
**[SWS_Ocu_00031]** ⌈
| 字段 | 内容 |
|---|---|
| Name | Ocu_PinStateType |
| Type | Enumeration |
| Range | OCU_HIGH（OCU 通道关联的引脚处于高状态）<br>OCU_LOW（OCU 通道关联的引脚处于低状态） |
| Description | OCU 通道链接的引脚的输出状态。 |
| Available via | Ocu.h |
⌋ ()
#### 8.2.4 Ocu_PinActionType
**[SWS_Ocu_00032]** ⌈
| 字段 | 内容 |
|---|---|
| Name | Ocu_PinActionType |
| Type | Enumeration |
| Range | OCU_SET_HIGH（比较匹配时通道引脚将设置为 HIGH）<br>OCU_SET_LOW（比较匹配时通道引脚将设置为 LOW）<br>OCU_TOGGLE（比较匹配时通道引脚将设置为当前电平的反相 HIGH）<br>OCU_DISABLE（比较匹配时通道引脚将保持当前电平） |
| Description | 在 OCU 通道关联的引脚上自动执行的动作（由硬件）。 |
| Available via | Ocu.h |
⌋ ()
#### 8.2.5 Ocu_ConfigType
**[SWS_Ocu_00033]** ⌈
| 字段 | 内容 |
|---|---|
| Name | Ocu_ConfigType |
| Type | Structure（硬件特定的初始化数据结构） |
| Description | 包含 OCU 驱动初始化数据的数据结构类型。 |
| Available via | Ocu.h |
⌋ (SRS_Ocu_00002, SRS_SPAL_12263, SRS_BSW_00405, SRS_BSW_00438)
**[SWS_Ocu_00034]** ⌈Ocu_ConfigType 是包含 OCU 驱动初始化数据的数据结构类型。
**强制参数：**
- 通道/通道 ID 的符号名称
- 计数器的最大值
- 以 ticks 数表示的时间分辨率
- 通知函数
- 阈值的默认值
- 计数器的最小值
**可选参数（如果硬件支持）：**
- 计数方向
- 输出引脚（电平以及可能的自动动作）
- 硬件触发事件（ADC 或 DMA）
- 微控制器 OCU 特定的 HW 属性（如果硬件支持，可选预分频器、时钟设置）
⌋ (SRS_Ocu_00002, SRS_SPAL_12461)
#### 8.2.6 Ocu_ReturnType
**[SWS_Ocu_00138]** ⌈
| 字段 | 内容 |
|---|---|
| Name | Ocu_ReturnType |
| Type | Enumeration |
| Range | OCU_CM_IN_REF_INTERVAL（比较匹配将发生在当前参考间隔内）<br>OCU_CM_OUT_REF_INTERVAL（比较匹配将不会发生在当前参考间隔内） |
| Description | 设置新阈值后的返回信息。 |
| Available via | Ocu.h |
⌋ ()
### 8.3 函数定义（Function definitions）
#### 8.3.1 Ocu_Init
**[SWS_Ocu_00035]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | Ocu_Init |
| Syntax | `void Ocu_Init(const Ocu_ConfigType* ConfigPtr)` |
| Service ID[hex] | 0x00 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | ConfigPtr - 指向配置集的指针 |
| Description | OCU 初始化服务。 |
| Available via | Ocu.h |
⌋ ()
**[SWS_Ocu_00036]** ⌈Ocu_Init 函数应初始化所有内部变量和微控制器的已使用 Ocu 结构，根据由 ConfigPtr 引用的配置集。⌋ (SRS_BSW_00344, SRS_BSW_00404, SRS_BSW_00101, SRS_SPAL_12057)
**注意：** 所有通道均由 API Ocu_Init 一次性初始化。没有单独初始化每个通道的 API。
**[SWS_Ocu_00037]** ⌈Ocu_Init 函数应仅初始化已配置的资源，并且不应触及配置文件中未配置的资源。⌋ (SRS_SPAL_12057, SRS_SPAL_12125)
**[SWS_Ocu_00038]** ⌈如果硬件只允许寄存器的一种用途（寄存器专用于 OCU 资源），则 OCU 驱动负责初始化该寄存器。⌋ (SRS_SPAL_12461)
**注释 1：** 如果寄存器可以影响多个硬件模块，并且它不是 I/O 寄存器，则应由 MCU 驱动对其进行初始化。
**注释 2：** 复位后需要直接初始化的一次性可写寄存器应由启动代码初始化。
**注释 3：** 所有其他寄存器应由启动代码初始化。
**注释 4：** 如果寄存器可以影响多个硬件模块，并且它是 I/O 寄存器，则应由 PORT 驱动对其进行初始化。
**[SWS_Ocu_00039]** ⌈Ocu_Init 函数应停止所有通道。⌋ (SRS_SPAL_12057)
**[SWS_Ocu_00040]** ⌈Ocu_Init 函数应禁用所有通知。⌋ (SRS_SPAL_12057)
原因是这些通知的用户可能尚未准备好。他们可以调用 Ocu_EnableNotification() 来开始接收通知。
**[SWS_Ocu_00043]** ⌈如果为 OCU 驱动启用了开发错误检测，并且当 OCU 驱动和硬件已初始化时调用了函数 Ocu_Init，则函数 Ocu_Init 应引发开发错误 OCU_E_ALREADY_INITIALIZED 并返回而不执行任何操作。⌋ (SRS_BSW_00406, SRS_BSW_00386, SRS_SPAL_12448)
**[SWS_Ocu_00044]** ⌈通过执行函数 Ocu_Init 重新初始化 OCU 驱动需要先通过执行函数 Ocu_DeInit 进行反初始化。⌋ ()
#### 8.3.2 Ocu_DeInit
**[SWS_Ocu_00045]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | Ocu_DeInit |
| Syntax | `void Ocu_DeInit(void)` |
| Service ID[hex] | 0x01 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Description | 此函数反初始化 OCU 模块。 |
| Available via | Ocu.h |
⌋ (SRS_Ocu_00005)
**[SWS_Ocu_00046]** ⌈Ocu_DeInit 函数应将由 Ocu_Init 初始化的 OCU 变量和寄存器反初始化到与上电复位状态相当的状态。不可写的寄存器的值不包括在内。⌋ (SRS_BSW_00336, SRS_SPAL_12163)
**注意：** 由硬件设计负责该状态不会导致 µC 中未定义的活动。
**[SWS_Ocu_00047]** ⌈Ocu_DeInit 函数应禁用所有使用的中断和通知。⌋ (SRS_SPAL_12163)
**[SWS_Ocu_00048]** ⌈Ocu_DeInit 函数应仅影响由静态配置和/或先前调用 Ocu_Init() 传递的运行时配置集分配的外设。⌋ ()
**[SWS_Ocu_00136]** ⌈API Ocu_DeInit 应停止专由此驱动使用的所有自由运行计数器。⌋ (SRS_SPAL_12125)
**注意：** 为防止反初始化期间的未定义行为，用户必须在调用 API Ocu_DeInit 之前停止所有 RUNNING 通道（通过调用函数 Ocu_StopChannel）。
**[SWS_Ocu_00137]** ⌈如果为 OCU 驱动启用了开发错误检测：如果在调用函数 Ocu_DeInit 时通道仍处于 RUNNING 状态，则函数应引发开发错误 'OCU_E_PARAM_INVALID_STATE' 并返回而不执行任何操作。⌋ ()
**[SWS_Ocu_00049]** ⌈Ocu_DeInit 函数应通过配置参数 OcuDeInitApi {OCU_DE_INIT_API} 进行预编译时间 On/Off 配置。⌋ (SRS_BSW_00171)
**[SWS_Ocu_00050]** ⌈如果为 OCU 驱动启用了开发错误检测：如果驱动未初始化，则函数 Ocu_DeInit 应引发错误 OCU_E_UNINIT。⌋ (SRS_BSW_00406, SRS_BSW_00386, SRS_SPAL_12448)
#### 8.3.3 Ocu_StartChannel
**[SWS_Ocu_00051]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | Ocu_StartChannel |
| Syntax | `void Ocu_StartChannel(Ocu_ChannelType ChannelNumber)` |
| Service ID[hex] | 0x02 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant for different channel numbers |
| Parameters (in) | ChannelNumber - OCU 的数字标识符 |
| Description | 启动 OCU 通道的服务。 |
| Available via | Ocu.h |
⌋ (SRS_Ocu_00008)
**[SWS_Ocu_00052]** ⌈Ocu_StartChannel 函数应通过允许执行所有比较匹配已配置的动作来启动 OCU 通道。⌋ (SRS_Ocu_00008)
**[SWS_Ocu_00053]** ⌈Ocu_StartChannel 函数应在为不同通道调用时可重入。⌋ ()
**[SWS_Ocu_00054]** ⌈如果成功执行函数 Ocu_StartChannel，所选通道的状态应设置为"RUNNING"。⌋ ()
**[SWS_Ocu_00055]** ⌈如果为 OCU 驱动启用了开发错误检测：如果在处于"RUNNING"状态的通道上调用函数 Ocu_StartChannel，则函数应引发错误 OCU_E_BUSY 并返回而不执行任何操作。⌋ (SRS_BSW_00406, SRS_SPAL_12448)
**[SWS_Ocu_00056]** ⌈如果为 OCU 驱动启用了开发错误检测：如果参数 ChannelNumber 无效（不在配置指定的范围内），函数 Ocu_StartChannel 应引发错误 OCU_E_PARAM_INVALID_CHANNEL 并返回而不执行任何操作。⌋ (SRS_BSW_00323, SRS_BSW_00386, SRS_SPAL_12448)
**[SWS_Ocu_00057]** ⌈如果为 OCU 驱动启用了开发错误检测：如果驱动未初始化，函数 Ocu_StartChannel 应引发错误 OCU_E_UNINIT 并返回而不执行任何操作。⌋ (SRS_BSW_00406, SRS_BSW_00386, SRS_SPAL_12448)
#### 8.3.4 Ocu_StopChannel
**[SWS_Ocu_00058]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | Ocu_StopChannel |
| Syntax | `void Ocu_StopChannel(Ocu_ChannelType ChannelNumber)` |
| Service ID[hex] | 0x03 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant for different channel numbers |
| Parameters (in) | ChannelNumber - OCU 的数字标识符 |
| Description | 停止 OCU 通道的服务。 |
| Available via | Ocu.h |
⌋ (SRS_Ocu_00008)
**[SWS_Ocu_00059]** ⌈Ocu_StopChannel 函数应通过停止此通道的比较匹配已配置的动作来停止 OCU 通道。⌋ (SRS_Ocu_00008)
**[SWS_Ocu_00060]** ⌈Ocu_StopChannel 函数不应停止与通道关联的自由运行计数器。⌋ ()
**注意：** 这是因为自由运行计数器可以与多个 Ocu 通道关联。因此，停止该计数器会损害其他通道的操作。
**[SWS_Ocu_00061]** ⌈Ocu_StopChannel 函数应在为不同通道调用时可重入。⌋ ()
**[SWS_Ocu_00062]** ⌈如果成功执行函数 Ocu_StopChannel，所选通道的状态应设置为"STOPPED"。⌋ ()
**[SWS_Ocu_00063]** ⌈如果在处于"STOPPED"状态的通道上调用函数 Ocu_StopChannel，则函数应不执行任何操作离开（不更改通道状态），并且不应引发开发错误。⌋ ()
**[SWS_Ocu_00064]** ⌈如果为 OCU 驱动启用了开发错误检测：如果参数 ChannelNumber 无效，函数 Ocu_StopChannel 应引发错误 OCU_E_PARAM_INVALID_CHANNEL 并返回而不执行任何操作。⌋ (SRS_BSW_00323, SRS_BSW_00386, SRS_SPAL_12448)
**[SWS_Ocu_00065]** ⌈如果为 OCU 驱动启用了开发错误检测：如果驱动未初始化，函数 Ocu_StopChannel 应引发错误 OCU_E_UNINIT 并返回而不执行任何操作。⌋ (SRS_BSW_00406, SRS_BSW_00386, SRS_SPAL_12448)
#### 8.3.5 Ocu_SetPinState
**[SWS_Ocu_00066]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | Ocu_SetPinState |
| Syntax | `void Ocu_SetPinState(Ocu_ChannelType ChannelNumber, Ocu_PinStateType PinState)` |
| Service ID[hex] | 0x04 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant for different channel numbers |
| Parameters (in) | ChannelNumber - OCU 的数字标识符<br>PinState - OCU_LOW 或 OCU_HIGH |
| Description | 立即设置 OCU 通道关联引脚电平的服务。 |
| Available via | Ocu.h |
⌋ (SRS_Ocu_00011)
**[SWS_Ocu_00067]** ⌈Ocu_SetPinState 函数应将与通道关联的引脚设置为"PinState"指示的电平。⌋ (SRS_Ocu_00011)
**[SWS_Ocu_00068]** ⌈Ocu_SetPinState 函数应在为不同通道调用时可重入。⌋ ()
**[SWS_Ocu_00069]** ⌈Ocu_SetPinState 函数应仅在通道不处于 RUNNING 状态时使用。⌋ ()
**注意：** 前面的要求还意味着可以通过此 API 更改 STOPPED 通道的状态。
**[SWS_Ocu_00070]** ⌈Ocu_SetPinState 函数应通过配置参数 OcuSetPinStateApi {OCU_SET_PIN_STATE_API} 进行预编译时间 On/Off 配置。⌋ (SRS_BSW_00171)
**[SWS_Ocu_00071]** ⌈如果为 OCU 驱动启用了开发错误检测：如果参数 ChannelNumber 无效，函数 Ocu_SetPinState 应引发错误 OCU_E_PARAM_INVALID_CHANNEL 并返回而不执行任何操作。⌋ (SRS_BSW_00323, SRS_BSW_00386, SRS_SPAL_12448)
**[SWS_Ocu_00072]** ⌈如果为 OCU 驱动启用了开发错误检测：如果通道未关联引脚（未在通道配置中定义），函数 Ocu_SetPinState 应引发错误 OCU_E_PARAM_NO_PIN 并返回而不执行任何操作。⌋ (SRS_BSW_00323, SRS_BSW_00386, SRS_SPAL_12448)
**[SWS_Ocu_00073]** ⌈如果为 OCU 驱动启用了开发错误检测：如果参数 PinState 无效，函数 Ocu_SetPinState 应引发错误 OCU_E_PARAM_INVALID_STATE 并返回而不执行任何操作。⌋ (SRS_BSW_00323, SRS_BSW_00386, SRS_SPAL_12448)
**[SWS_Ocu_00074]** ⌈如果为 OCU 驱动启用了开发错误检测：如果驱动未初始化，函数 Ocu_SetPinState 应引发错误 OCU_E_UNINIT 并返回而不执行任何操作。⌋ (SRS_BSW_00406, SRS_BSW_00386, SRS_SPAL_12448)
**[SWS_Ocu_00075]** ⌈如果为 OCU 驱动启用了开发错误检测：如果通道处于 RUNNING 状态，函数 Ocu_SetPinState 应引发错误 OCU_E_PARAM_INVALID_STATE 并返回而不执行任何操作。⌋ (SRS_BSW_00323, SRS_BSW_00386, SRS_SPAL_12448)
#### 8.3.6 Ocu_SetPinAction
**[SWS_Ocu_00076]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | Ocu_SetPinAction |
| Syntax | `void Ocu_SetPinAction(Ocu_ChannelType ChannelNumber, Ocu_PinActionType PinAction)` |
| Service ID[hex] | 0x05 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant for different channel numbers |
| Parameters (in) | ChannelNumber - OCU 的数字标识符<br>PinAction - OCU_SET_LOW、OCU_SET_HIGH、OCU_TOGGLE、OCU_DISABLE |
| Description | 指示驱动在比较匹配时由硬件自动执行什么操作的服务（如果支持）。 |
| Available via | Ocu.h |
⌋ (SRS_Ocu_00012)
**[SWS_Ocu_00077]** ⌈Ocu_SetPinAction 函数应设置在相应 OCU 通道的下一次比较匹配时由硬件自动执行的动作。⌋ (SRS_Ocu_00012)
**[SWS_Ocu_00078]** ⌈Ocu_SetPinAction 函数应在为不同通道调用时可重入。⌋ ()
**[SWS_Ocu_00079]** ⌈Ocu_SetPinAction 函数应通过配置参数 OcuSetPinActionApi {OCU_SET_PIN_ACTION_API} 进行预编译时间配置。⌋ (SRS_BSW_00171)
**[SWS_Ocu_00080]** ⌈如果为 OCU 驱动启用了开发错误检测：如果参数 ChannelNumber 无效，函数 Ocu_SetPinAction 应引发错误 OCU_E_PARAM_INVALID_CHANNEL 并返回而不执行任何操作。⌋ (SRS_BSW_00323, SRS_BSW_00386, SRS_SPAL_12448)
**[SWS_Ocu_00081]** ⌈如果为 OCU 驱动启用了开发错误检测：如果通道未关联引脚，函数 Ocu_SetPinAction 应引发错误 OCU_E_PARAM_NO_PIN 并返回而不执行任何操作。⌋ (SRS_BSW_00323, SRS_BSW_00386, SRS_SPAL_12448)
**[SWS_Ocu_00082]** ⌈如果为 OCU 驱动启用了开发错误检测：如果参数 PinAction 无效（不在类型指定的范围内），函数 Ocu_SetPinAction 应引发错误 OCU_E_PARAM_INVALID_ACTION 并返回而不执行任何操作。⌋ (SRS_BSW_00323, SRS_BSW_00386, SRS_SPAL_12448)
**[SWS_Ocu_00083]** ⌈如果为 OCU 驱动启用了开发错误检测：如果驱动未初始化，函数 Ocu_SetPinAction 应引发错误 OCU_E_UNINIT 并返回而不执行任何操作。⌋ (SRS_BSW_00406, SRS_BSW_00386, SRS_SPAL_12448)
**[SWS_Ocu_00084]** ⌈如果引脚与通道关联，则应在比较匹配时执行与此引脚相关的动作。⌋ ()
#### 8.3.7 Ocu_GetCounter
**[SWS_Ocu_00085]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | Ocu_GetCounter |
| Syntax | `Ocu_ValueType Ocu_GetCounter(Ocu_ChannelType ChannelNumber)` |
| Service ID[hex] | 0x06 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant |
| Parameters (in) | ChannelNumber - OCU 通道的数字标识符 |
| Return value | Ocu_ValueType - 计数器内容（以 ticks 为单位） |
| Description | 读取计数器当前值的服务。 |
| Available via | Ocu.h |
⌋ (SRS_Ocu_00009)
**[SWS_Ocu_00086]** ⌈Ocu_GetCounter 函数应读取并返回由 ChannelNumber 指示的通道的计数器值。⌋ (SRS_Ocu_00009)
**[SWS_Ocu_00087]** ⌈Ocu_GetCounter 函数应是可重入的。⌋ ()
**[SWS_Ocu_00088]** ⌈Ocu_GetCounter 函数应通过配置参数 OcuGetCounterApi {OCU_GET_COUNTER_API} 进行预编译时间配置。⌋ (SRS_BSW_00171)
**[SWS_Ocu_00089]** ⌈如果为 OCU 驱动启用了开发错误检测：如果参数 ChannelNumber 无效，函数 Ocu_GetCounter 应引发错误 OCU_E_PARAM_INVALID_CHANNEL 并返回值"0"。⌋ (SRS_BSW_00323, SRS_BSW_00386, SRS_SPAL_12448)
**[SWS_Ocu_00090]** ⌈如果为 OCU 驱动启用了开发错误检测：如果驱动未初始化，则函数 Ocu_GetCounterValue 应引发错误 OCU_E_UNINIT 并返回值"0"。⌋ (SRS_BSW_00406, SRS_BSW_00386, SRS_SPAL_12448)
#### 8.3.8 Ocu_SetAbsoluteThreshold
**[SWS_Ocu_00091]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | Ocu_SetAbsoluteThreshold |
| Syntax | `Ocu_ReturnType Ocu_SetAbsoluteThreshold(Ocu_ChannelType ChannelNumber, Ocu_ValueType ReferenceValue, Ocu_ValueType AbsoluteValue)` |
| Service ID[hex] | 0x07 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant for different channel numbers |
| Parameters (in) | ChannelNumber - OCU 通道的数字标识符<br>ReferenceValue - 由上层给定的值，用作确定是否在函数退出之前调用通知的基础<br>AbsoluteValue - 与计数器内容进行比较的值（以 ticks 为单位） |
| Return value | Ocu_ReturnType - 告知调用者由于设置新的阈值，比较匹配是否会发生（或已经发生）在当前参考间隔内 |
| Description | 使用绝对输入数据设置通道阈值的服务。 |
| Available via | Ocu.h |
⌋ (SRS_Ocu_00010)
**[SWS_Ocu_00092]** ⌈Ocu_SetAbsoluteThreshold 函数应将通道阈值（比较值）设置为由 AbsoluteValue 给定的值。⌋ (SRS_Ocu_00010)
**[SWS_Ocu_00093]** ⌈Ocu_SetAbsoluteThreshold 函数应在为不同通道调用时可重入。⌋ ()
**[SWS_Ocu_00094]** ⌈Ocu_SetAbsoluteThreshold 函数应通过配置参数 OcuSetAbsoluteThresholdApi {OCU_SET_ABSOLUTE_THRESHOLD_API} 进行预编译时间 On/Off 配置。⌋ (SRS_BSW_00171)
**[SWS_Ocu_00095]** ⌈如果为 OCU 驱动启用了开发错误检测：如果驱动未初始化，函数 Ocu_SetAbsoluteThreshold 应引发错误 OCU_E_UNINIT 并返回而不执行任何操作。⌋ (SRS_BSW_00406, SRS_BSW_00386, SRS_SPAL_12448)
**[SWS_Ocu_00096]** ⌈如果为 OCU 驱动启用了开发错误检测：如果参数 ChannelNumber 无效，函数 Ocu_SetAbsoluteThreshold 应引发错误 OCU_E_PARAM_INVALID_CHANNEL 并返回而不执行任何操作。⌋ (SRS_BSW_00323, SRS_BSW_00386, SRS_SPAL_12448)
**关于 ReferenceValue：** ReferenceValue 是来自上层的信息。通过组合 ReferenceValue 和 AbsoluteValue 提供了一个间隔（定义为"参考间隔"，下图中的绿色区域）以考虑计数器连续运行以及调用方更新比较阈值的请求与阈值的实际修改之间可能存在延迟的事实。
**情况 1：阈值在实际比较匹配发生之前写入**
```
Free running counter 29 30 31 32 33 34 35 36 37 38 39
…
Reference Value 30
Compare threshold 35
(Absolute value)
```
相等性将在写入阈值后发生。中断将被触发，通知函数应由驱动调用。
**图 6：阈值在实际比较匹配发生之前写入**
**情况 2：阈值在实际比较匹配发生之后写入**
```
Free running counter 29 30 31 32 33 34 35 36 37 38 39
…
Reference Value 30
35
Compare threshold
```
在此周期内不会发生相等性，因为所使用的计数器值已经大于阈值。
**图 7：阈值在实际比较匹配发生之后写入**
**参考间隔定义（含计数器回绕）：**
```
… …
Free running counter 69 70 71 255 0 19 20 21 22
…
Reference Value 70
Compare threshold 20
```
**图 8：参考间隔的定义**
#### 8.3.9 Ocu_SetRelativeThreshold
> **摘要说明：** Ocu_SetRelativeThreshold 允许相对于当前计数器值或当前阈值值设置新阈值。
>
> **[SWS_Ocu_00103]** ⌈Ocu_SetRelativeThreshold 函数应通过配置参数 OcuSetRelativeThresholdApi {OCU_SET_RELATIVE_THRESHOLD_API} 进行预编译时间 On/Off 配置。⌋ (SRS_BSW_00171)
>
> 详细函数签名与需求见原文 PDF（第 41-43 页）。
#### 8.3.10 Ocu_DisableNotification
> **摘要说明：** Ocu_DisableNotification 禁用 OCU 通道的通知。
>
> **[SWS_Ocu_00111]** ⌈Ocu_DisableNotification 函数应通过配置参数 OcuNotificationSupported {OCU_NOTIFICATION_SUPPORTED} 进行预编译时间 On/Off 配置。⌋ (SRS_BSW_00171)
#### 8.3.11 Ocu_EnableNotification
> **摘要说明：** Ocu_EnableNotification 启用 OCU 通道的通知。
>
> **[SWS_Ocu_00118]** ⌈Ocu_EnableNotification 函数应通过配置参数 OcuNotificationSupported {OCU_NOTIFICATION_SUPPORTED} 进行预编译时间 On/Off 配置。⌋ (SRS_BSW_00171)
#### 8.3.12 Ocu_GetVersionInfo
> **摘要说明：** Ocu_GetVersionInfo 返回此驱动版本的详细信息（vendor ID、module ID、vendor specific version numbers）。通过 Std_VersionInfoType 指针返回。
### 8.4 回调通知（Callback notifications）
无。
### 8.5 计划函数（Scheduled functions）
无。
### 8.6 预期接口（Expected Interfaces）
#### 8.6.1 强制接口（Mandatory Interfaces）
- `Det_ReportError`（来自 Det）
#### 8.6.2 可选接口（Optional Interfaces）
无。
#### 8.6.3 可配置接口（Configurable interfaces）
- `Ocu_DeInit`
- `Ocu_StartChannel`
- `Ocu_StopChannel`
- `Ocu_SetPinState`
- `Ocu_SetPinAction`
- `Ocu_GetCounter`
- `Ocu_SetAbsoluteThreshold`
- `Ocu_SetRelativeThreshold`
- `Ocu_DisableNotification`
- `Ocu_EnableNotification`
- `Ocu_GetVersionInfo`
---
## 9 序列图与时序图（Sequence and Timing diagrams）
> **摘要说明：** 本节包含以下序列图：
>
> 1. **初始化**（Ocu_Init 调用流程）
> 2. **反初始化**（Ocu_DeInit 调用流程）
> 3. **使用 OCU 通知**（启用/禁用通知流程）
> 4. **Ocu_SetPinState**（设置引脚状态流程）
> 5. **Ocu_SetPinAction**（设置引脚动作流程）
> 6. **设置新的比较阈值**（SetAbsoluteThreshold/SetRelativeThreshold 流程）
>
> *完整序列图见原文 PDF（第 48-52 页）。*
---
## 10 配置规范（Configuration specification）
### 10.1 如何阅读本章（How to read this chapter）
#### 10.1.1 配置和配置参数（Configuration and configuration parameters）
容器和参数定义遵循 AUTOSAR 配置规范。
#### 10.1.2 容器（Containers）
#### 10.1.3 配置参数的规范模板（Specification template for configuration parameters）
### 10.2 容器和配置参数（Containers and configuration parameters）
#### 10.2.1 Ocu
> Ocu 是顶层容器，包含所有 OCU 驱动配置。
#### 10.2.2 OcuGeneral
> **摘要：** OcuGeneral 包含全局 OCU 配置：
> - `OcuConfigSetPointer` - 配置集指针
> - `OcuDevErrorDetectApi` - 启用/禁用开发错误检测
> - `OcuDeInitApi` - 启用/禁用 DeInit API
> - `OcuSetPinStateApi` - 启用/禁用 SetPinState API
> - `OcuSetPinActionApi` - 启用/禁用 SetPinAction API
> - `OcuGetCounterApi` - 启用/禁用 GetCounter API
> - `OcuSetAbsoluteThresholdApi` - 启用/禁用 SetAbsoluteThreshold API
> - `OcuSetRelativeThresholdApi` - 启用/禁用 SetRelativeThreshold API
> - `OcuNotificationSupported` - 启用/禁用通知
> - `OcuGetVersionInfoApi` - 启用/禁用版本信息 API
> - `OcuIndex` - OCU 驱动实例索引
>
> *完整参数定义见原文 PDF（第 56-58 页）。*
#### 10.2.3 OcuConfigurationOfOptionalApis
> **摘要：** 包含每个可选 API 的配置：
> - `OcuSetPinStateApi`
> - `OcuSetPinActionApi`
> - `OcuGetCounterApi`
> - `OcuSetAbsoluteThresholdApi`
> - `OcuSetRelativeThresholdApi`
> - `OcuNotificationSupported`
> - `OcuGetVersionInfoApi`
> - `OcuDeInitApi`
>
> *完整参数定义见原文 PDF（第 58-61 页）。*
#### 10.2.4 OcuConfigSet
OcuConfigSet 容器包含一组 OcuChannel 配置。
#### 10.2.5 OcuChannel
> **摘要：** OcuChannel 包含每个 OCU 通道的配置：
> - `OcuChannelId` - 通道 ID
> - `OcuCounterMaxValue` - 计数器最大值
> - `OcuCounterMinValue` - 计数器最小值
> - `OcuDefaultThreshold` - 默认阈值
> - `OcuChannelNotification` - 通道通知
> - `OcuHardwareChannel` - 已分配的硬件通道
> - `OcuHwUsed` - 是否使用硬件
> - `OcuPinAction` - 引脚动作
> - `OcuPinState` - 引脚状态
> - `OcuOutputPinUsed` - 是否使用输出引脚
> - `OcuHardwareTriggered` - 是否硬件触发（ADC/DMA）
> - `OcuHwResourceId` - 硬件资源 ID
> - `OcuHwResource` - 硬件资源数量
> - `OcuExpectedHardwareTrigger` - 预期的硬件触发
> - `OcuCountDirection` - 计数方向
> - `OcuMcuClockReferencePoint` - MCU 时钟参考点
> - `OcuPrescaler` - 预分频器
>
> *完整参数定义见原文 PDF（第 63-69 页）。*
#### 10.2.6 OcuHWSpecificSettings
> **摘要：** 包含每个 OCU 通道的硬件特定设置。
### 10.3 发布信息（Published Information）
> **摘要说明：** 发布信息参数定义了由 OCU 驱动模块发布给其他模块的信息，例如版本号、供应商 ID 等。
---
## 11 不适用需求（Not applicable requirements）
> **摘要说明：** 本节列出了不适用于 OCU 驱动的需求，包括：
> - 与特定 BSW 通用规范条目相关的限制
> - 多核分发相关需求的适用性说明
---
## 翻译说明
本文档为 AUTOSAR 4.4.0 版本 OCU 驱动软件规范的中文翻译。保留了所有需求 ID（SWS_Ocu_xxxxx）、参考标识符及模块缩写。原始文档共 72 页，本翻译涵盖了全部主要章节，并对大型可追溯性表和详细配置参数表采用了"重点翻译+摘要"策略，标注"完整表见原文 PDF"的位置以便用户查阅原文。OCU（输出比较单元）驱动提供计数器与阈值比较、自动引脚动作、通知和硬件触发等关键功能。
IO/AUTOSAR_SWS_PWMDriver.md
+837
View File
@@ -0,0 +1,837 @@
# PWM 驱动规范（Specification of PWM Driver）
> **AUTOSAR CP Release 4.4.0**
## 文档元信息
| 字段 | 内容 |
|---|---|
| **文档标题** | PWM 驱动规范（Specification of PWM Driver） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 037 |
| **文档状态** | Final（最终版） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 引入 MCAL 多核分发（Draft）概念；移除过时元素；头文件清理；修正自动化文档处理的文档结构 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 添加运行时错误分类；移除 SWS_Pwm_20069、SWS_Pwm_10120 和 SWS_Pwm_20120 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 更新 Pwm_GetOutputState 返回值需求 SWS_Pwm_30051 及其引用；更新 PwmChannelID 的配置类；移除配置变体定义；移除 BSW 需求的未解析引用；更新头文件结构图 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 移除关于 NULL_PTR 检查的需求；DET 已重命名 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 更新代码文件结构需求的追踪引用 |
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 引入 McuClockReferencePoint；编辑性变更 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 更新与 PwmPowerStateAsynchTransitionMode 相关的需求；更新计划函数章节；编辑性变更；移除变更文档章节 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 新增 ECU 降级概念；适配新的 SWS BSW General；拆分内存映射头 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 重新阐述 SWS_Pwm_00045 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 新错误符号 PWM_E_PARAM_POINTER：在 API Pwm_GetVersionInfo 以 NULL 参数调用时报告；更新版本检查章节；措辞和维护性改进 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 解释 Pwm_SetPeriodAndDuty 函数在零周期输入值时的行为；新增调试支持章节；拆分某些需求使每个 ID 唯一；法律声明修订 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律声明修订 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 从 UML 模型生成的表和链接到 UML 模型的 UML 图；通用需求的改进以为 CT 开发做准备；IDLE PWM 通道的重新激活概念适配；已初始化模块的开发错误添加；文档元信息扩展；小幅布局调整 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | 更新文件包含结构；为 PWM API 添加 ON/OFF 配置宏；将配置参数 PWM_PERIOD_UPDATED_ENDPERIOD 重命名为 PwmPeriodUpdatedEndperiod；更新 PWM 信号描述图；法律声明修订；"用户建议"修订；"修订信息"新增 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 文档结构适配通用 Release 2.0 SWS 模板；修改 PWM 通道的抽象级别；通知可配置；更新模块的配置 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 初始发布 |
---
## 目录（Table of Contents）
1. [引言与功能概述（Introduction and functional overview）](#1-引言与功能概述)
2. [缩略语与缩写（Acronyms and abbreviations）](#2-缩略语与缩写)
3. [相关文档（Related documentation）](#3-相关文档)
- 3.1 [输入文档（Input documents）](#31-输入文档)
- 3.2 [相关规范（Related specification）](#32-相关规范)
4. [约束与假设（Constraints and assumptions）](#4-约束与假设)
- 4.1 [限制（Limitations）](#41-限制)
- 4.2 [对汽车领域的适用性（Applicability to car domains）](#42-对汽车领域的适用性)
5. [对其他模块的依赖（Dependencies to other modules）](#5-对其他模块的依赖)
- 5.1 [文件结构（File structure）](#51-文件结构)
6. [需求可追溯性（Requirements traceability）](#6-需求可追溯性)
7. [功能规范（Functional specification）](#7-功能规范)
8. [API 规范（API specification）](#8-api-规范)
9. [序列图（Sequence diagrams）](#9-序列图)
10. [配置规范（Configuration specification）](#10-配置规范)
11. [不适用需求（Not applicable requirements）](#11-不适用需求)
---
## 1 引言与功能概述（Introduction and functional overview）
本规范规定了 AUTOSAR 基础软件模块 PWM 驱动的功能、API 和配置。
每个 PWM 通道链接到属于微控制器的硬件 PWM。PWM 信号的类型（例如中心对齐、左对齐等）不在本规范中定义，留给实现。
驱动提供用于初始化和控制微控制器内部 PWM 级（脉宽调制）的功能。PWM 模块生成具有可变脉冲宽度的脉冲。它允许选择占空比和信号周期时间。
**图 1：PWM 信号描述**
---
## 2 缩略语与缩写（Acronyms and abbreviations）
| 缩略语 | 描述 |
|---|---|
| PWM Channel | 链接到硬件 PWM 的数字标识符 |
| PWM Output State | 定义 PWM 信号的输出状态。可以是：<br>- High（高）<br>- Low（低） |
| PWM Idle State | 空闲状态表示在调用 Pwm_SetOutputToIdle 或 Pwm_DeInit 之后 PWM 通道的输出状态 |
| PWM Polarity | 定义每个 PWM 通道的起始输出状态 |
| PWM Duty cycle | 定义相对于周期的起始电平（高或低）的百分比 |
| PWM period | 定义 PWM 信号的周期 |
| 缩写 | 描述 |
|---|---|
| PWM | 脉宽调制（Pulse Width Modulation） |
| DEM | 诊断事件管理器（Diagnostic Event Manager） |
| DET | 默认错误跟踪器（Default Error Tracer） |
| MCU | 微控制器单元（Microcontroller Unit） |
| PLL | 锁相环（Phase Locked Loop） |
| ISR | 中断服务例程（Interrupt Service Routine） |
---
## 3 相关文档（Related documentation）
### 3.1 输入文档（Input documents）
- **[1]** 分层软件架构，AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
- **[2]** SPAL 的一般需求，AUTOSAR_SRS_SPALGeneral.pdf
- **[3]** 基础软件模块的一般需求，AUTOSAR_SRS_BSWGeneral.pdf
- **[4]** 默认错误跟踪器规范，AUTOSAR_SWS_DefaultErrorTracer.pdf
- **[5]** MCU 驱动规范，AUTOSAR_SWS_MCUDriver.pdf
- **[6]** ECU 配置规范，AUTOSAR_TPS_ECUConfiguration.pdf
- **[7]** 基础软件模块描述模板，AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
- **[8]** 基础软件模块列表，AUTOSAR_TR_BSWModuleList
- **[9]** 基础软件模块通用规范，AUTOSAR_SWS_BSWGeneral.pdf
### 3.2 相关规范（Related specification）
AUTOSAR 提供了基础软件模块的通用规范 [9]（SWS BSW General），这也适用于 PWM 驱动。
因此，SWS BSW General 规范应被视为 PWM 驱动的附加和必需规范。
---
## 4 约束与假设（Constraints and assumptions）
### 4.1 限制（Limitations）
**[SWS_Pwm_00001]** ⌈PWM SWS 不涵盖通用 I/O 上的 PWM 仿真。⌋ (SRS_Pwm_12386)
- 电源状态控制 API 仅在 MCAL 驱动拥有完整的底层 HW 外设（即 HW 外设未被其他 MCAL 模块访问）时可实现。
### 4.2 对汽车领域的适用性（Applicability to car domains）
无限制。
---
## 5 对其他模块的依赖（Dependencies to other modules）
PWM 依赖于系统时钟。因此，系统时钟的更改（例如 PLL on → PLL off）也会影响 PWM 硬件的时钟设置。
PWM 驱动依赖于以下模块：
- **PORT 驱动**：用于设置端口引脚功能（PWM141）
- **MCU 驱动**：用于设置预分频器、系统时钟和 PLL（PWM142）
- **DET**：开发模式下的默认错误跟踪器（PWM143）
文档 087_AUTOSAR_ECU_Configuration 包含章节 4.6 - 时钟树配置，详细说明了向外设提供参考时钟信号的机制。
### 5.1 文件结构（File structure）
#### 5.1.1 代码文件结构（Code file structure）
**[SWS_Pwm_00065]** ⌈PWM SWS 不应定义代码文件结构。⌋ (SRS_BSW_00346, SRS_BSW_00158, SRS_BSW_00314)
#### 5.1.2 头文件结构（Header file structure）
- **[SWS_Pwm_50075]** ⌈Pwm.c 应包含 Pwm.h、Det.h 和 ... ⌋ ()
- **[SWS_Pwm_70075]** ⌈Pwm_Irq.c 应包含 Pwm.h。⌋ ()
---
## 6 需求可追溯性（Requirements traceability）
> **摘要说明：** 本节列出 BSW 和 SPAL 通用需求与 PWM 驱动特定需求（SWS_Pwm_xxxxx）的对应关系。完整的可追溯性表见原文 PDF，主要包括以下类别：
>
> - **通用 BSW 需求**（SRS_BSW_xxxxx）：模块版本、初始化、配置、命名约定、错误处理、内存映射等
> - **SPAL 特定需求**（SRS_SPAL_xxxxx）：初始化接口、通知机制、模式选择、ISR、休眠源等
> - **PWM 特定 SRS 需求**（SRS_Pwm_xxxxx）：占空比设置、周期设置、通知开关、参数配置等
>
> 关键映射：
> - SWS_Pwm_00007（Init 函数）← SRS_BSW_00101, SRS_SPAL_12057
> - SWS_Pwm_00010（DeInit 函数）← SRS_BSW_00336, SRS_SPAL_12163, SRS_Pwm_12381
> - SWS_Pwm_00013（SetDutyCycle 函数）← SRS_Pwm_12295
> - SWS_Pwm_00019（SetPeriodAndDuty 函数）← SRS_Pwm_12297
> - SWS_Pwm_00021（SetOutputToIdle）← SRS_Pwm_12358
> - SWS_Pwm_00022（GetOutputState）← SRS_Pwm_12385
> - SWS_Pwm_00023/00024（Disable/EnableNotification）← SRS_Pwm_12378, SRS_Pwm_12299
> - SWS_Pwm_00041（仅允许 variable period 类型的通道更改周期）← SRS_Pwm_12389
> - SWS_Pwm_00058（16 位占空比宽度）← SRS_Pwm_12383
> - SWS_Pwm_00059（占空比缩放方案）← SRS_Pwm_12459
> - SWS_Pwm_00070（时间单位为 ticks）← SRS_BSW_00343
> - SWS_Pwm_00093、00116、00118、00121（Init 时序约束与错误检测）
> - SWS_Pwm_00117、00047、10051、20051（API 参数验证）
> - SWS_Pwm_00150（周期为 0 时的行为）
> - SWS_Pwm_00153（模块文档/标识）
> - SWS_Pwm_00165（PowerStateRequestResultType 定义）
> - SWS_Pwm_00197（Pwm_PowerStateType 定义 + PWM 通道属性配置）
> - SWS_Pwm_10080/20080（DeInit 可配置 On/Off）
> - SWS_Pwm_10082/20082（SetDutyCycle 可配置 On/Off）
> - SWS_Pwm_10083/20083（SetPeriodAndDuty 可配置 On/Off）
> - SWS_Pwm_10084/20084（SetOutputToIdle 可配置 On/Off）
> - SWS_Pwm_10085/20085（GetOutputState 可配置 On/Off）
> - SWS_Pwm_10086/20086/00119（SetOutputToIdle 后重新激活）
> - SWS_Pwm_10112/20112（DisableNotification 可配置）
> - SWS_Pwm_20002/30002/40002/50002（开发错误分类）
> - SWS_Pwm_30051（GetOutputState 错误返回）
>
> *完整可追溯性表见原文 PDF（第 12-18 页）。*
---
## 7 功能规范（Functional specification）
### 7.1 一般行为（General behavior）
**[SWS_Pwm_00088]** ⌈PWM 模块除 Pwm_Init、Pwm_DeInit 和 Pwm_GetVersionInfo 外的所有函数应对不同 PWM 通道号可重入。
为保持模块实现的简单性，模块不应执行 SWS_Pwm_00088 的检查。⌋ ()
**[SWS_Pwm_00089]** ⌈PWM 模块的用户应确保在运行时不同任务或 ISR 中对同一 PWM 通道进行多次函数调用时的完整性。⌋ ()
### 7.2 时间单位 Ticks（Time Unit Ticks）
#### 7.2.1 背景与原理（Background & Rationale）
要从寄存器值中获取时间，必须知道振荡器频率、预分频器等。由于这些设置是在 MCU 和/或其他模块中进行的，因此无法计算此类时间。
因此，时间与 ticks 之间的转换应属于上层。
#### 7.2.2 需求（Requirements）
**[SWS_Pwm_00070]** ⌈PWM 模块 API 服务中使用的所有时间单位应为 ticks 单位。⌋ (SRS_BSW_00343)
### 7.3 支持和管理 HW 低功耗状态（Support and management of HW low power states）
某些 PWM HW 模块允许被设置为某些降低功耗的操作模式，代价可能是较慢的反应时间、较低的性能或完全不可用。每个 PWM 模块可以支持一个或多个低功耗操作模式，将全功率模式视为始终存在并在启动时默认设置。
#### 7.3.1 背景（Background）
PWM 驱动提供电源状态控制 API 和后台处理机制来处理异步电源状态更改过程（即电源状态更改不会在请求时立即完成，而是需要一些更长的操作）。
#### 7.3.2 需求（Requirements）
> **摘要：** PWM 驱动实现以下电源状态管理 API：
> - `Pwm_SetPowerState`：请求电源状态转换
> - `Pwm_GetCurrentPowerState`：读取当前电源状态
> - `Pwm_GetTargetPowerState`：读取目标电源状态
> - `Pwm_PreparePowerState`：准备电源状态转换
> - `Pwm_Main_PowerTransitionManager`：主电源转换管理函数（计划函数）
>
> 详细需求 SWS_Pwm_xxxxx 见原文 PDF（第 19-21 页）。
### 7.4 错误分类（Error classification）
#### 7.4.1 开发错误（Development Errors）
**[SWS_Pwm_20002]** ⌈开发错误类型：PWM_E_PARAM_CONFIG（API Pwm_Init 在已初始化的状态下调用时报告）。⌋ (SRS_BSW_00337, SRS_BSW_00385)
**[SWS_Pwm_30002]** ⌈开发错误类型：PWM_E_UNINIT（API 服务在 PWM 驱动未初始化时被调用时报告）。⌋ (SRS_BSW_00337, SRS_BSW_00385)
**[SWS_Pwm_40002]** ⌈开发错误类型：PWM_E_PARAM_CHANNEL（API 服务使用无效的通道 ID 调用时报告）。⌋ (SRS_BSW_00337, SRS_BSW_00385)
**[SWS_Pwm_50002]** ⌈开发错误类型：PWM_E_PARAM_POINTER（API Pwm_GetVersionInfo 使用 NULL 参数调用时报告）。⌋ (SRS_BSW_00337, SRS_BSW_00385)
**[SWS_Pwm_00045]** ⌈如果 Pwm_SetPeriodAndDuty 的输入参数 Period 等于零，则输出应为 0%（零占空比）。⌋ (SRS_BSW_00386, SRS_BSW_00323)
**[SWS_Pwm_00047]** ⌈Pwm 模块应验证 API 参数的可用性并报告相应的开发错误。⌋ (SRS_BSW_00323, SRS_BSW_00386)
#### 7.4.2 运行时错误（Runtime Errors）
**[SWS_Pwm_00117]** ⌈静态状态变量，表示 BSW 模块已初始化。⌋ (SRS_BSW_00406, SRS_BSW_00386, SRS_BSW_00323)
#### 7.4.3 瞬态故障（Transient Faults）
无。
#### 7.4.4 生产错误（Production Errors）
无。
### 7.5 错误检测（Error Detection）
**[SWS_Pwm_10051]** ⌈如果启用了开发错误检测，Pwm 模块应在以下情况下报告开发错误：
- PWM_E_UNINIT：在调用任何 API 时 PWM 驱动未初始化
- PWM_E_PARAM_CHANNEL：使用无效的通道 ID 调用 API
- PWM_E_ALREADY_INITIALIZED：在 Pwm_Init 期间 PWM 驱动和硬件已初始化
- PWM_E_PARAM_POINTER：使用 NULL 参数调用 Pwm_GetVersionInfo
⌋ (SRS_BSW_00386, SRS_BSW_00323)
**[SWS_Pwm_20051]** ⌈如果启用了开发错误检测，开发错误的配置参数开关定义如下：
- PWM_DE_INIT_API
- PWM_SET_DUTY_CYCLE_API
- PWM_SET_PERIOD_AND_DUTY_API
- PWM_SET_OUTPUT_TO_IDLE_API
- PWM_GET_OUTPUT_STATE_API
- PWM_NOTIFICATION_SUPPORTED
- PWM_VERSION_INFO_API
⌋ (SRS_BSW_00386, SRS_BSW_00323)
### 7.6 错误通知（Error Notification）
有关详细信息，请参阅 SWS_BSWGeneral 中的第 7.2"错误分类"和 7.3"错误检测"章节。
### 7.7 占空比分辨率与缩放（Duty Cycle Resolution and scaling）
**[SWS_Pwm_00058]** ⌈占空比参数的宽度为 16 位。⌋ (SRS_Pwm_12383)
**[SWS_Pwm_00059]** ⌈Pwm 模块应遵循占空比的以下缩放方案：
- `0x0000` 表示 0%。
- `0x8000` 表示 100%。0x8000 提供最高分辨率，同时允许使用 16 位值表示 100% 占空比。
作为实现指南，给出以下源代码示例：
```c
AbsoluteDutyCycle = ((uint32)AbsolutePeriodTime * RelativeDutyCycle) >> 15;
```
⌋ (SRS_Pwm_12459)
### 7.8 版本检查（Version check）
有关详细信息，请参阅 SWS_BSWGeneral 中的第 5.1.8"版本检查"章节。
---
## 8 API 规范（API specification）
### 8.1 导入类型（Imported types）
**[SWS_Pwm_00094]** ⌈
| 模块 | 头文件 | 导入类型 |
|---|---|---|
| Std_Types | StandardTypes.h | Std_ReturnType, Std_VersionInfoType |
⌋ ()
### 8.2 类型定义（Type definitions）
#### 8.2.1 Pwm_ChannelType
**[SWS_Pwm_00106]** ⌈
| 字段 | 内容 |
|---|---|
| Name | Pwm_ChannelType |
| Type | uint |
| Range | 8..32 位（实现特定） |
| Description | PWM 通道的数字标识符。 |
| Available via | Pwm.h |
⌋ ()
#### 8.2.2 Pwm_PeriodType
**[SWS_Pwm_00107]** ⌈
| 字段 | 内容 |
|---|---|
| Name | Pwm_PeriodType |
| Type | uint |
| Range | 8..32 位（实现特定） |
| Description | PWM 通道的周期定义。 |
| Available via | Pwm.h |
⌋ ()
#### 8.2.3 Pwm_OutputStateType
**[SWS_Pwm_00108]** ⌈
| 字段 | 内容 |
|---|---|
| Name | Pwm_OutputStateType |
| Type | Enumeration |
| Range | PWM_HIGH（PWM 通道处于高状态）<br>PWM_LOW（PWM 通道处于低状态） |
| Description | PWM 通道的输出状态。 |
| Available via | Pwm.h |
⌋ ()
#### 8.2.4 Pwm_EdgeNotificationType
**[SWS_Pwm_00109]** ⌈
| 字段 | 内容 |
|---|---|
| Name | Pwm_EdgeNotificationType |
| Type | Enumeration |
| Range | PWM_RISING_EDGE（PWM 输出信号发生上升沿时调用通知）<br>PWM_FALLING_EDGE（PWM 输出信号发生下降沿时调用通知）<br>PWM_BOTH_EDGES（PWM 输出信号发生上升沿或下降沿时调用通知） |
| Description | PWM 通道边沿通知类型的定义。 |
| Available via | Pwm.h |
⌋ ()
#### 8.2.5 Pwm_ChannelClassType
**[SWS_Pwm_00110]** ⌈
| 字段 | 内容 |
|---|---|
| Name | Pwm_ChannelClassType |
| Type | Enumeration |
| Range | PWM_VARIABLE_PERIOD（PWM 通道具有可变周期，可以更改占空比和周期）<br>PWM_FIXED_PERIOD（PWM 通道具有固定周期，仅可以更改占空比）<br>PWM_FIXED_PERIOD_SHIFTED（PWM 通道具有固定的移相周期，无法更改，仅当硬件支持时） |
| Description | 定义 PWM 通道的类别。 |
| Available via | Pwm.h |
⌋ ()
#### 8.2.6 Pwm_ConfigType
**[SWS_Pwm_00111]** ⌈
| 字段 | 内容 |
|---|---|
| Name | Pwm_ConfigType |
| Type | Structure（硬件相关的初始化数据结构） |
| Description | 包含 PWM 驱动初始化数据的数据结构类型。 |
| Available via | Pwm.h |
⌋ ()
**[SWS_Pwm_00061]** ⌈Pwm_ConfigType 是包含 PWM 驱动初始化数据的数据结构类型。⌋ ()
#### 8.2.7 Pwm_PowerStateRequestResultType
**[SWS_Pwm_00165]** ⌈
| 字段 | 内容 |
|---|---|
| Name | Pwm_PowerStateRequestResultType |
| Type | Enumeration |
| Range | PWM_SERVICE_ACCEPTED 0x00（电源状态更改已执行）<br>PWM_NOT_INIT 0x01（PWM 模块未初始化）<br>PWM_SEQUENCE_ERROR 0x02（错误的 API 调用序列）<br>PWM_HW_FAILURE 0x03（HW 模块有故障，无法进入所需的电源状态）<br>PWM_POWER_STATE_NOT_SUPP 0x04（PWM 模块不支持请求的电源状态）<br>PWM_TRANS_NOT_POSSIBLE 0x05（PWM 模块无法直接从当前电源状态转换到请求的电源状态，或者 HW 外设仍忙） |
| Description | 与电源状态转换相关的请求结果。 |
| Available via | Pwm.h |
⌋ ()
#### 8.2.8 Pwm_PowerStateType
**[SWS_Pwm_00197]** ⌈
| 字段 | 内容 |
|---|---|
| Name | Pwm_PowerStateType |
| Type | Enumeration |
| Range | 1..255（功耗递减的电源模式）<br>PWM_FULL_POWER 0x00 全功率 |
| Description | 当前活动的电源状态或设置为目标电源状态。 |
| Available via | Pwm.h |
⌋ (SRS_Pwm_12293, SRS_Pwm_12378)
**强制参数：**
- 已分配的 HW 通道
- 周期的默认值
- 占空比的默认值
- 极性（高或低）
- 空闲状态高或低
- 通道类别：
- 固定周期
- 固定周期、移相（如果硬件支持）
- 可变周期
**可选参数（如果硬件支持）：**
- 通道相位偏移
- 相位偏移的参考通道
- 微控制器特定通道属性
### 8.3 函数定义（Function definitions）
#### 8.3.1 Pwm_Init
**[SWS_Pwm_00095]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | Pwm_Init |
| Syntax | `void Pwm_Init(const Pwm_ConfigType* ConfigPtr)` |
| Service ID[hex] | 0x00 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | ConfigPtr - 指向配置集的指针 |
| Parameters (inout) | None |
| Parameters (out) | None |
| Return value | None |
| Description | PWM 初始化服务。 |
| Available via | Pwm.h |
⌋ ()
**[SWS_Pwm_00007]** ⌈Pwm_Init 函数应根据 ConfigPtr 中指定的参数初始化所有内部变量和微控制器的已使用 PWM 结构。⌋ (SRS_BSW_00101, SRS_SPAL_12057)
**[SWS_Pwm_00062]** ⌈Pwm_Init 函数应仅初始化已配置的资源，并且不应触及配置文件中未配置的资源。⌋ (SRS_SPAL_12057, SRS_SPAL_12125)
**[SWS_Pwm_10009]** ⌈Pwm_Init 函数应使用配置的默认值启动所有 PWM 通道。⌋ (SRS_SPAL_12057)
- **[SWS_Pwm_20009]** ⌈如果占空比参数等于 0% 或 100%：则 PWM 输出信号应处于根据配置的极性参数的状态。⌋ (SRS_SPAL_12057)
- **[SWS_Pwm_30009]** ⌈如果占空比参数大于 0% 且小于 100%：则 PWM 输出信号应根据周期、占空比和配置的极性参数进行调制。⌋ (SRS_SPAL_12057)
**[SWS_Pwm_00052]** ⌈Pwm_Init 函数应禁用所有通知。⌋ (SRS_SPAL_12057)
**[SWS_Pwm_00093]** ⌈Pwm 模块的用户不应在运行操作期间调用 Pwm_Init 函数。⌋ ()
**[SWS_Pwm_00116]** ⌈Pwm 模块的环境在调用 Pwm_Init 之前不应调用 Pwm 模块的任何函数。⌋ ()
**[SWS_Pwm_00118]** ⌈如果启用了开发错误检测，在 PWM 驱动和硬件已初始化时调用 Pwm_Init 将导致开发错误 PWM_E_ALREADY_INITIALIZED。所需的功能应在不执行任何操作的情况下离开。⌋ ()
**[SWS_Pwm_00121]** ⌈通过执行 Pwm_Init() 函数重新初始化 Pwm 驱动需要先通过执行 Pwm_DeInit() 进行反初始化。⌋ ()
#### 8.3.2 Pwm_DeInit
**[SWS_Pwm_00096]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | Pwm_DeInit |
| Syntax | `void Pwm_DeInit(void)` |
| Service ID[hex] | 0x01 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Description | PWM 反初始化服务。 |
| Available via | Pwm.h |
⌋ ()
**[SWS_Pwm_00010]** ⌈Pwm_DeInit 函数应反初始化 PWM 模块。⌋ (SRS_BSW_00336, SRS_SPAL_12163, SRS_Pwm_12381)
**[SWS_Pwm_00011]** ⌈Pwm_DeInit 函数应将 PWM 输出信号的状态设置为空闲状态。⌋ (SRS_SPAL_12163)
**[SWS_Pwm_00012]** ⌈Pwm_DeInit 函数应禁用 PWM 中断和 PWM 信号边沿通知。⌋ (SRS_SPAL_12163)
**[SWS_Pwm_10080]** ⌈Pwm_DeInit 函数应通过配置参数 PwmDeInitApi 进行预编译时间 On/Off 配置。⌋ (SRS_BSW_00171)
**[SWS_Pwm_20080]** ⌈Pwm_DeInit 函数应通过配置参数 PwmDeInitApi {PWM_DE_INIT_API} 进行 On/Off 配置。⌋ (SRS_BSW_00171)
#### 8.3.3 Pwm_SetDutyCycle
**[SWS_Pwm_91000]** ⌈（draft）
| 字段 | 内容 |
|---|---|
| Service name | Pwm_SetDutyCycle |
| Syntax | `void Pwm_SetDutyCycle(Pwm_ChannelType ChannelNumber, uint16 DutyCycle)` |
| Service ID[hex] | 0x02 |
| Sync/Async | Asynchronous |
| Reentrancy | Reentrant for different channel numbers |
| Parameters (in) | ChannelNumber - PWM 的数字标识符<br>DutyCycle - Min=0x0000 Max=0x8000 |
| Description | 服务设置 PWM 通道的占空比。 |
⌋ ()
**[SWS_Pwm_00013]** ⌈Pwm_SetDutyCycle 函数应设置 PWM 通道的占空比。⌋ (SRS_Pwm_12295)
**[SWS_Pwm_00014]** ⌈当请求的占空比为 0% 或 100% 时，Pwm_SetDutyCycle 函数应将 PWM 输出状态设置为 PWM_HIGH 或 PWM_LOW，同时考虑配置的极性参数和请求的占空比。因此对于 0% 请求的占空比，输出将是配置的极性参数的反相，对于 100% 占空比，输出将等于配置的极性参数。⌋ ()
**[SWS_Pwm_00016]** ⌈当占空比 > 0% 且 < 100% 时，Pwm_SetDutyCycle 函数应根据周期、占空比和配置的极性参数调制 PWM 输出信号。⌋ ()
**[SWS_Pwm_00017]** ⌈Pwm_SetDutyCycle 函数应在实现支持且通过 PwmDutycycleUpdatedEndperiod 配置的情况下始终在周期结束时更新占空比。⌋ (SRS_Pwm_12382)
**[SWS_Pwm_00018]** ⌈驱动应禁止 PWM 输出信号上的尖峰。⌋ ()
**[SWS_Pwm_10082]** ⌈Pwm_SetDutyCycle 函数应通过配置参数 PwmSetDutyCycle 进行预编译时间 On/Off 配置。⌋ (SRS_BSW_00171)
**[SWS_Pwm_20082]** ⌈Pwm_SetDutyCycle 函数应通过配置参数 PwmSetDutyCycle {PWM_SET_DUTY_CYCLE_API} 进行 On/Off 配置。⌋ (SRS_BSW_00171)
#### 8.3.4 Pwm_SetPeriodAndDuty
**[SWS_Pwm_91001]** ⌈（draft）
| 字段 | 内容 |
|---|---|
| Service name | Pwm_SetPeriodAndDuty |
| Syntax | `void Pwm_SetPeriodAndDuty(Pwm_ChannelType ChannelNumber, Pwm_PeriodType Period, uint16 DutyCycle)` |
| Service ID[hex] | 0x03 |
| Sync/Async | Asynchronous |
| Reentrancy | Reentrant for different channel numbers |
| Parameters (in) | ChannelNumber - PWM 的数字标识符<br>Period - PWM 信号的周期<br>DutyCycle - Min=0x0000 Max=0x8000 |
| Description | 服务设置 PWM 通道的周期和占空比。 |
⌋ ()
**[SWS_Pwm_00019]** ⌈Pwm_SetPeriodAndDuty 函数应设置 PWM 通道的周期和占空比。⌋ (SRS_Pwm_12297)
**[SWS_Pwm_00076]** ⌈Pwm_SetPeriodAndDuty 函数应在实现支持且通过 PwmPeriodUpdatedEndperiod 配置的情况下始终在当前周期结束时更新周期。⌋ ()
**[SWS_Pwm_00020]** ⌈更新 PWM 周期和占空比时，驱动应抑制 PWM 输出信号上的任何尖峰。⌋ ()
**[SWS_Pwm_00041]** ⌈Pwm_SetPeriodAndDuty 函数应仅允许更改被声明为可变周期类型的 PWM 通道的周期。⌋ (SRS_Pwm_12389)
**[SWS_Pwm_10083]** ⌈Pwm_SetPeriodAndDuty 函数应通过配置参数 PwmSetPeriodAndDuty 进行预编译时间 On/Off 配置。⌋ (SRS_BSW_00171)
**[SWS_Pwm_20083]** ⌈Pwm_SetPeriodAndDuty 函数应通过配置参数 PwmSetPeriodAndDuty {PWM_SET_PERIOD_AND_DUTY_API} 进行 On/Off 配置。⌋ (SRS_BSW_00171)
**[SWS_Pwm_00150]** ⌈如果周期设置为零，则占空比的设置不相关。在这种情况下，输出应为零（零占空比）。⌋ ()
#### 8.3.5 Pwm_SetOutputToIdle
**[SWS_Pwm_91002]** ⌈（draft）
| 字段 | 内容 |
|---|---|
| Service name | Pwm_SetOutputToIdle |
| Syntax | `void Pwm_SetOutputToIdle(Pwm_ChannelType ChannelNumber)` |
| Service ID[hex] | 0x04 |
| Sync/Async | Asynchronous |
| Reentrancy | Reentrant for different channel numbers |
| Parameters (in) | ChannelNumber - PWM 的数字标识符 |
| Description | 服务将 PWM 输出设置为配置的空闲状态。 |
⌋ ()
**[SWS_Pwm_00021]** ⌈Pwm_SetOutputToIdle 函数应立即将 PWM 输出设置为配置的空闲状态。⌋ (SRS_Pwm_12358)
**[SWS_Pwm_10084]** ⌈Pwm_SetOutputToIdle 函数应通过配置参数 PwmSetOutputToIdle 进行预编译时间 On/Off 配置。⌋ (SRS_BSW_00171)
**[SWS_Pwm_20084]** ⌈Pwm_SetOutputToIdle 函数应通过配置参数 PwmSetOutputToIdle {PWM_SET_OUTPUT_TO_IDLE_API} 进行 On/Off 配置。⌋ (SRS_BSW_00171)
**[SWS_Pwm_10086]** ⌈调用 Pwm_SetOutputToIdle 函数后，可变周期类型的通道应使用 API Pwm_SetPeriodAndDuty() 重新激活，以使用新传入的周期激活 PWM 通道。⌋ ()
**[SWS_Pwm_20086]** ⌈调用 Pwm_SetOutputToIdle 函数后，通道应使用 API Pwm_SetDutyCycle() 重新激活，以使用旧周期激活 PWM 通道。⌋ ()
**[SWS_Pwm_00119]** ⌈调用 Pwm_SetOutputToIdle 函数后，固定周期类型的通道应仅使用 API Pwm_SetDutyCycle() 重新激活，以使用旧周期激活 PWM 通道。⌋ ()
#### 8.3.6 Pwm_GetOutputState
**[SWS_Pwm_00100]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | Pwm_GetOutputState |
| Syntax | `Pwm_OutputStateType Pwm_GetOutputState(Pwm_ChannelType ChannelNumber)` |
| Service ID[hex] | 0x05 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant for different channel numbers |
| Parameters (in) | ChannelNumber - PWM 的数字标识符 |
| Return value | PWM_HIGH（PWM 输出状态为高）<br>PWM_LOW（PWM 输出状态为低） |
| Description | 服务读取 PWM 输出信号的内部状态。 |
| Available via | Pwm.h |
⌋ ()
**[SWS_Pwm_00022]** ⌈Pwm_GetOutputState 函数应读取 PWM 输出信号的内部状态并按以下图所示返回：值从 PWM 单元读取，经过端口逻辑后作为端口引脚输出。⌋ (SRS_Pwm_12385)
**[SWS_Pwm_10085]** ⌈Pwm_GetOutputState 函数应通过配置参数 PwmGetOutputState 进行预编译时间 On/Off 配置。⌋ (SRS_BSW_00171)
**[SWS_Pwm_20085]** ⌈Pwm_GetOutputState 函数应通过配置参数 PwmGetOutputState {PWM_GET_OUTPUT_STATE_API} 进行 On/Off 配置。
由于实时约束和 PWM 通道的设置（项目相关），输出状态可以在调用服务 Pwm_GetOutputState 后立即修改。⌋ (SRS_BSW_00171)
**[SWS_Pwm_30051]** ⌈如果在模块初始化之前调用 Pwm_GetOutputState，或使用无效通道调用，则应返回 PWM_LOW。⌋ (SRS_BSW_00323, SRS_BSW_00386)
#### 8.3.7 Pwm_DisableNotification
**[SWS_Pwm_91003]** ⌈（draft）
| 字段 | 内容 |
|---|---|
| Service name | Pwm_DisableNotification |
| Syntax | `void Pwm_DisableNotification(Pwm_ChannelType ChannelNumber)` |
| Service ID[hex] | 0x06 |
| Sync/Async | Asynchronous |
| Reentrancy | Reentrant for different channel numbers |
| Parameters (in) | ChannelNumber - PWM 的数字标识符 |
| Description | 服务禁用 PWM 信号边沿通知。 |
⌋ ()
**[SWS_Pwm_00023]** ⌈Pwm_DisableNotification 函数应禁用 PWM 信号边沿通知。⌋ (SRS_Pwm_12378, SRS_Pwm_12299)
**[SWS_Pwm_10112]** ⌈Pwm_DisableNotification 函数应通过配置参数 PwmNotificationSupported 进行预编译时间 On/Off 配置。⌋ ()
**[SWS_Pwm_20112]** ⌈Pwm_DisableNotification 函数应通过配置参数 PwmNotificationSupported {PWM_NOTIFICATION_SUPPORTED} 进行 On/Off 配置。⌋ ()
#### 8.3.8 Pwm_EnableNotification
**[SWS_Pwm_91004]** ⌈（draft）
| 字段 | 内容 |
|---|---|
| Service name | Pwm_EnableNotification |
| Syntax | `void Pwm_EnableNotification(Pwm_ChannelType ChannelNumber, Pwm_EdgeNotificationType Notification)` |
| Service ID[hex] | 0x07 |
| Sync/Async | Asynchronous |
| Reentrancy | Reentrant for different channel numbers |
| Description | 服务启用 PWM 信号边沿通知。 |
⌋ ()
**[SWS_Pwm_00024]** ⌈Pwm_EnableNotification 函数应启用 PWM 信号边沿通知。⌋ (SRS_Pwm_12378, SRS_Pwm_12299)
#### 8.3.9 - 8.3.13 电源状态管理与版本 API
> **摘要说明：** 以下 API 函数与电源状态管理和版本信息相关：
>
> | 函数 | 描述 |
> |---|---|
> | `Pwm_SetPowerState` | 请求电源状态转换，返回 Pwm_PowerStateRequestResultType |
> | `Pwm_GetCurrentPowerState` | 读取当前电源状态 |
> | `Pwm_GetTargetPowerState` | 读取目标电源状态 |
> | `Pwm_PreparePowerState` | 准备电源状态转换（用于异步电源状态切换） |
> | `Pwm_GetVersionInfo` | 返回驱动版本信息（通过 Std_VersionInfoType 指针） |
>
> 详细函数签名与需求见原文 PDF（第 38-42 页）。
### 8.4 回调通知（Callback notifications）
无。
### 8.5 计划函数（Scheduled functions）
#### 8.5.1 Pwm_Main_PowerTransitionManager
**[SWS_Pwm_00167]** ⌈
| 字段 | 内容 |
|---|---|
| Service name | Pwm_Main_PowerTransitionManager |
| Syntax | `void Pwm_Main_PowerTransitionManager(void)` |
| Description | 计划函数，处理 PWM 模块的异步电源状态转换。 |
⌋ ()
### 8.6 预期接口（Expected Interfaces）
#### 8.6.1 强制接口（Mandatory Interfaces）
- `Dem_SetEventStatus`（来自 Dem）
- `Det_ReportError`（来自 Det）
#### 8.6.2 可选接口（Optional Interfaces）
- `Pwm_GetVersionInfo`
- `Pwm_GetOutputState`
#### 8.6.3 可配置接口（Configurable interfaces）
- `Pwm_DeInit`
- `Pwm_SetDutyCycle`
- `Pwm_SetPeriodAndDuty`
- `Pwm_SetOutputToIdle`
- `Pwm_DisableNotification`
- `Pwm_EnableNotification`
### 8.7 API 参数检查（API parameter checking）
> **摘要说明：** API 参数检查的需求已通过 SWS_Pwm_10051、SWS_Pwm_20051 集中定义。这些开关通过配置参数（PWM_DE_INIT_API 等）控制开发错误检测的启用和禁用。详细的检查规则请参阅 7.5 错误检测和 8.3 函数定义部分。
---
## 9 序列图（Sequence diagrams）
> **摘要说明：** 本节包含以下序列图，描述了主要操作场景：
>
> 1. **初始化**（Pwm_Init 调用流程）
> 2. **反初始化**（Pwm_DeInit 调用流程）
> 3. **设置占空比**（Pwm_SetDutyCycle 调用流程）
> 4. **设置周期和占空比**（Pwm_SetPeriodAndDuty 调用流程）
> 5. **将 PWM 输出设置为空闲**（Pwm_SetOutputToIdle 调用流程）
> 6. **获取 PWM 输出状态**（Pwm_GetOutputState 调用流程）
> 7. **使用 PWM 通知**（启用/禁用通知流程）
>
> *完整序列图见原文 PDF（第 47-53 页）。*
---
## 10 配置规范（Configuration specification）
### 10.1 如何阅读本章（How to read this chapter）
容器和参数定义遵循 AUTOSAR 配置规范。
### 10.2 容器和配置参数（Containers and configuration parameters）
#### 10.2.1 Pwm
> Pwm 是顶层容器，包含所有 PWM 驱动配置。
#### 10.2.2 PwmGeneral
> **摘要：** PwmGeneral 包含全局 PWM 配置：
> - `PwmChannelId` 配置类
> - `PwmDeInitApi` - 启用/禁用 DeInit API
> - `PwmSetDutyCycle` - 启用/禁用 SetDutyCycle API
> - `PwmSetPeriodAndDuty` - 启用/禁用 SetPeriodAndDuty API
> - `PwmSetOutputToIdle` - 启用/禁用 SetOutputToIdle API
> - `PwmGetOutputState` - 启用/禁用 GetOutputState API
> - `PwmNotificationSupported` - 启用/禁用通知
> - `PwmVersionInfoApi` - 启用/禁用版本信息 API
> - `PwmDutycycleUpdatedEndperiod` - 占空比周期结束更新
> - `PwmPeriodUpdatedEndperiod` - 周期结束更新
>
> *完整参数定义见原文 PDF（第 54-58 页）。*
#### 10.2.3 PwmPowerStateConfig
> **摘要：** PwmPowerStateConfig 包含电源状态相关配置：
> - `PwmPowerStateAsynchTransitionMode` - 异步电源状态转换模式
> - `PwmPowerStateConfigSet` - 电源状态配置集
>
> *完整参数定义见原文 PDF（第 58-59 页）。*
#### 10.2.4 PwmChannel
> **摘要：** PwmChannel 包含每个 PWM 通道的配置：
> - `PwmChannelId` - 通道 ID
> - `PwmChannelClass` - 通道类别（Variable Period、Fixed Period、Fixed Period Shifted）
> - `PwmPolarity` - 极性
> - `PwmIdleState` - 空闲状态
> - `PwmPeriodDefault` - 默认周期
> - `PwmDutycycleDefault` - 默认占空比
> - `PwmNotification` - 通知配置
> - `PwmHwChannel` - 已分配的 HW 通道
> - `PwmChannelPhaseShift` - 通道相位偏移（可选）
> - `PwmReferenceChannel` - 相位偏移参考通道（可选）
> - `PwmMcuClockReferencePoint` - MCU 时钟参考点
>
> *完整参数定义见原文 PDF（第 59-62 页）。*
#### 10.2.5 PwmChannelConfigSet
PwmChannelConfigSet 容器包含一组 PwmChannel 配置。
#### 10.2.6 PwmConfigurationOfOptApiServices
> **摘要：** 包含每个可选 API 的配置：
> - `PwmSetDutyCycle`
> - `PwmSetPeriodAndDuty`
> - `PwmSetOutputToIdle`
> - `PwmGetOutputState`
> - `PwmNotificationSupported`
> - `PwmVersionInfo`
> - `PwmDeInitApi`
>
> *完整参数定义见原文 PDF（第 62-64 页）。*
### 10.3 发布信息（Published Information）
> **摘要说明：** 发布信息参数定义了由 PWM 驱动模块发布给其他模块的信息，例如版本号、供应商 ID 等。
---
## 11 不适用需求（Not applicable requirements）
> **摘要说明：** 本节列出了不适用于 PWM 驱动的需求，包括：
> - 与特定 BSW 通用规范条目相关的限制
> - 多核分发相关需求的适用性说明
---
## 翻译说明
本文档为 AUTOSAR 4.4.0 版本 PWM 驱动软件规范的中文翻译。保留了所有需求 ID（SWS_Pwm_xxxxx）、参考标识符及模块缩写。原始文档共 65 页，本翻译涵盖了全部主要章节，并对大型可追溯性表、序列图和详细配置参数表采用了"重点翻译+摘要"策略，标注"完整表见原文 PDF"的位置以便用户查阅原文。
IO/AUTOSAR_SWS_PortDriver.md
+1062
View File
File diff suppressed because it is too large Load Diff
Memory/AUTOSAR_EXP_NVDataHandling.md
+466
View File
@@ -0,0 +1,466 @@
# 非易失数据处理指南
> **文档标题**: NV Data Handling Guideline
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 810
> **文档类型**: EXP (Explanation/Guideline)
---
## 文档标识
| 项目 | 内容 |
|------|------|
| Document Title | NV Data Handling Guideline |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 810 |
| 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 | 初始版本发布 |
---
## 目录
1. [介绍与功能概述](#1-介绍与功能概述)
2. [缩略语](#2-缩略语)
3. [相关文档](#3-相关文档)
4. [总体机制和概念](#4-总体机制和概念)
5. [用例摘要](#5-用例摘要)
6. [附录](#6-附录)
---
## 1 介绍与功能概述
本文档介绍 AUTOSAR 关于非易失存储器(Non-volatile Memory)的基本概念以及应用软件组件可用的各种访问机制。
第 4 章简要概述非易失内存概念,第 5 章提供从应用程序(最终用户)访问非易失内存的各种用例。
---
## 2 缩略语
| 缩略语 | 描述 |
|--------|------|
| NvM | NVRAM Manager(NVRAM 管理器) |
| NV | Non-volatile(非易失) |
| NVRAM | Non-volatile Random Access Memory(非易失随机存取存储器) |
| NVRAM Block | 管理并存储 NV 数据块所需的整个结构 |
| NV Block | 基础存储对象。表示驻留在 NV 存储器中的"NVRAM 块"的部分 |
| RAM Block | 基础存储对象。表示驻留在 RAM 中的"NVRAM 块"的部分 |
| RAM Mirror | NvM 内部缓冲区,用于读写 `NvMBlockUseSyncMechanism` 设为 TRUE 的 NVRAM 块的 RAM 块 |
| ROM Block | 基础存储对象。表示驻留在 ROM 中的"NVRAM 块"的部分 |
| ROM | Read-Only Memory(只读存储器) |
| RTE | Runtime Environment(运行时环境) |
| SW-C | Software Component(软件组件) |
---
## 3 相关文档
### 3.1 输入文档
[1] AUTOSAR Specification for Runtime Environment — AUTOSAR_SWS_RTE.pdf
[2] AUTOSAR Template Specification of Software Component — AUTOSAR_TPS_SoftwareComponentTemplate.pdf
[3] AUTOSAR Specification for NVRAM Manager — AUTOSAR_SWS_NVRAMManager.pdf
[4] AUTOSAR Guide on Mode Management — AUTOSAR_EXP_ModeManagementGuide.pdf
### 3.2 相关标准与规范
无。
### 3.3 相关规范
无。
---
## 4 总体机制和概念
### 4.1 NvM 及其特性
可变性(changeability)和持久性(durability)是与 ECU 内数据相关的属性。值可变但跨电源周期保留的数据需要存储在非易失存储器中。**NV Data** 是非易失存储器中的数据。在 AUTOSAR 中,应用程序只能通过 **NVRAM Manager (NvM)** 访问该非易失存储器。该模块提供管理和维护数据所需的服务(同步/异步)。
```
应用层(Application SW-C)
│
▼
RTE
│
▼
NvM (NVRAM Manager)
│
▼
Memory Abstraction Interface (MemIf)
│
▼
FEE / EA
│
▼
Flash Driver / EEPROM Driver
│
▼
NV 存储器硬件
```
*图 1:AUTOSAR 中内存栈概览*
#### 4.1.1 基础存储对象
"基础存储对象"是"NVRAM 块"的最小实体。多个"基础存储对象"可用于构建一个 NVRAM 块。"基础存储对象"可驻留在不同的内存位置(RAM/ROM/NV 存储器)。
##### 4.1.1.1 RAM 块
"RAM 块"表示 NVRAM 块中驻留在 RAM 的部分。由用户数据、(可选)CRC 值和(可选)NV 块头部组成。用于保存活动数据。这是 NVRAM 块的**可选**部分。
##### 4.1.1.2 ROM 块
"ROM 块"表示 NVRAM 块中驻留在 ROM 的部分。"ROM 块"是 NVRAM 块的**可选**部分。
ROM 块内容是持久性的,在程序执行期间无法修改,驻留在 ROM/Flash 中。用于在空或损坏的 NV 块的情况下提供默认数据。
##### 4.1.1.3 NV 块
"NV 块"表示 NVRAM 块中驻留在 NV 存储器的部分。"NV 块"是 NVRAM 块的**强制**部分。
NV 块内容是持久性的,可在程序执行期间修改,驻留在 Flash 中。由 NV 用户数据、(可选)CRC 值和(可选)NV 块头部组成。
##### 4.1.1.4 管理块
"管理块"驻留在 RAM 中。"管理块"是 NVRAM 块的**强制**部分。
管理块内容是非持久性的,驻留在 RAM 中。用于保存相应 NVRAM 块的属性/错误/状态信息以及"Dataset"类型 NVRAM 块的块索引。
#### 4.1.2 块管理类型
NvM 支持以下 NVRAM 块管理类型:
##### 4.1.2.1 Native NVRAM 块
最简单的块管理类型,以最少开销存储/检索 NV 存储器。
`NVM_BLOCK_NATIVE` 类型的 NVRAM 存储由以下基础存储对象组成:
- NV 块:1
- RAM 块:1
- ROM 块:0..1
- 管理块:1
##### 4.1.2.2 Redundant NVRAM 块
除 Native NVRAM 块外,Redundant NVRAM 块提供增强的容错性、可靠性和可用性,增加对数据损坏的抵抗力。
`NVM_BLOCK_REDUNDANT` 类型的 NVRAM 存储由以下基础存储对象组成:
- NV 块:2
- RAM 块:1
- ROM 块:0..1
- 管理块:1
##### 4.1.2.3 Dataset NVRAM 块
等大小数据块的数组。应用一次可访问恰好一个数据块。
`NVM_BLOCK_DATASET` 类型的 NVRAM 存储由以下基础存储对象组成:
- NV 块:1..NvMNvBlockNum
- RAM 块:1
- ROM 块:0..NvMRomBlockNum
- 管理块:1
配置数据集总数(NV+ROM 块)必须在 1..255 范围内。
#### 4.1.3 支持的同步机制
访问 NvM 模块的 RAM 镜像数据时支持两种同步机制。
##### 4.1.3.1 隐式同步
应用程序和 NvM 并发访问一个公共 RAM 块。应用程序通过调用 NvM API 向/从 RAM 写入/读取数据。
```
应用程序 ────────► RAM 块 ◄──────── NvM
(共享访问)
│
▼
NV 存储器
```
*图 2:隐式同步概览*
在这种情况下,RAM 块映射到一个 SW-C,不建议共享 RAM 块。当 SW-C 使用 RAM 块(临时/永久)访问 NVRAM 时,必须确保 RAM 块的数据一致性,直到 NvM 完成正在进行的操作。
**写请求步骤**:
1. 应用程序用要由 NvM 模块写入的数据填充 RAM 块
2. 应用程序发出 NvM_WriteBlock 或 NvM_WritePRAMBlock 请求,将控制权转移到 NvM 模块
3. 之后,应用程序在请求成功或失败信号发出或通过轮询导出之前不得修改 RAM 块
4. 应用程序可使用轮询获取请求状态或通过回调函数异步通知
5. NvM 模块操作完成后,RAM 块可重新用于修改
##### 4.1.3.2 显式同步
在显式同步中,NvM 定义一个 RAM 镜像用于与应用程序的 RAM 块交换数据。应用程序在 RAM 块中写入数据并调用 NvM 写 API。NvM 调用 API 读取 RAM 镜像,数据从 RAM 镜像复制到 RAM 块,最后到 NV 块。数据通过回调例程(由 NvM 模块调用)在两个方向上由应用程序传输。
```
应用程序 ────► RAM 块 ──回调──► RAM 镜像 ─────► NV 存储器
(NvM 内部) (通过 NvM)
```
*图 3:显式同步概览*
**优点**:应用程序可以高效控制其 RAM 块。它们负责使用 ReadRamBlockFromNvM / WriteRamBlockToNvM 在 NvM 模块的 RAM 镜像中复制一致数据。
**缺点**:需要与使用此机制的最大 NVRAM 块大小相同的额外 RAM,以及每个操作两个 RAM 位置之间的额外复制。
**写请求步骤(显式同步)**:
1. 应用程序用要由 NvM 模块写入的数据填充 RAM 块
2. 应用程序发出 NvM_WriteBlock 或 NvM_WritePRAMBlock 请求
3. 应用程序可修改 RAM 块,直到 NvM 模块调用 `NvMWriteRamBlockToNvM` 例程
4. 如果调用了 `NvMWriteRamBlockToNvM`,应用程序必须将 RAM 块的一致副本提供到 NvM 模块请求的目的地。应用程序可使用返回值 E_NOT_OK 信号数据不一致。NvM 模块将接受 `NvMRepeatMirrorOperations` 次,然后推迟请求并继续下一个请求
5. 仅在数据复制到 NvM 模块后才继续
6. 之后应用程序可以再次读写 RAM 块
#### 4.1.4 其他特性
##### 4.1.4.1 基于 CRC 的比较
NvM 模块内部使用 CRC 生成例程(8/16/32 位),作为可配置选项,用于检查和生成 NVRAM 块的 CRC。
NvM 模块提供通过实现 CRC 比较机制跳过写入未更改数据的选项。CRC 比较机制可通过设置配置参数 `NvMBlockUseCRCCompMechanism` 启用。
**注**:一般来说,RAM 块的某些更改内容可能导致与初始内容相同的 CRC,因此如果使用此选项可能会丢失更新。因此,此选项应仅用于可容忍此风险的块。
##### 4.1.4.2 错误恢复
NvM 模块为 NATIVE 和 REDUNDANT 块管理类型提供读时隐式错误恢复(通过加载默认值,如配置)。
ROM 数据的显式检索可通过调用 API `NvM_RestoreBlockDefaults` 用于所有块管理类型。对于 DATASET,必须在调用此 API 之前设置相关索引(指向 ROM 块)。
NvM 模块通过执行写重试为写提供错误恢复,无论 NVRAM 块管理类型如何。
##### 4.1.4.3 写验证
写验证时,当 RAM 块写入 NV 存储器时,立即回读 NV 块并与 RAM 块的原始内容比较。
如果 RAM 块的原始内容与回读不同,则执行写重试。如果启用,生产代码错误 `NVM_E_VERIFY_FAILED` 报告给 DEM。
如果回读操作失败,则不执行读重试。
##### 4.1.4.4 使用 NvM_SetRamBlockStatus API 处理 RAM 块
###### 4.1.4.4.1 启动阶段(NvM_ReadAll)
对于某些 NVRAM 块,可能需要在 NvM_ReadAll 期间保留相应 RAM 块的数据内容不被覆盖,以防相应 NV 块中存储的数据比 RAM 块中的更旧(例如,在 RAM 中的数据尚未写入 NV 存储器时发生热复位)。在这种情况下,RAM 块必须分配到 reset-safe(非初始化)RAM 区域,配置参数 `CalcRamBlockCrc` 必须设为 TRUE,并且 `NvMSetRamBlockStatusApi` 设为 TRUE。
每次 RAM 块数据内容更改后,必须为相应 NVRAM 块调用 API `NvM_SetRamBlockStatus`,参数 `BlockChanged` 设为 TRUE。NVRAM 管理器随后重新计算此 RAM 块的 CRC 并将结果存储在 reset-safe RAM 区域分配的内部变量中。
每次启动(`NvM_ReadAll`)时,NvM 模块计算该 RAM 块的 CRC,如果与已存储的 CRC 值匹配,RAM 块将不被覆盖。如果计算的 CRC 与已存储的不匹配,RAM 块将被从 NV 块读取的数据覆盖,或者如果此读取尝试失败,则用默认数据覆盖。
###### 4.1.4.4.2 关机阶段(NvM_WriteAll)
如果配置参数 `NvMSetRamBlockStatusApi` 设为 FALSE,NVRAM 管理器在 NvM_WriteAll 过程中将 RAM 块的数据内容复制到所有为 WriteAll 配置的 NVRAM 块的相应 NV 块。
为了最小化 NV 存储器的写周期数,仅复制其数据内容已被 NVRAM 块用户更改的 RAM 块的内容很有用。为了在 NvM_WriteAll 过程中启用此功能,必须将 `NvMSetRamBlockStatusApi` 设为 TRUE。在这种情况下,NVRAM 块用户必须在每次 RAM 块数据更改后通过调用 API `NvM_SetRamBlockStatus`(参数 `BlockChanged` 设为 TRUE)通知 NVRAM 管理器。
##### 4.1.4.5 抵抗软件变化
NvM 模块在启动期间(即处理 NvM_ReadAll 请求时)的行为受两个配置参数影响:`NvMDynamicConfiguration` 和 `NvMResistantToChangedSw`。
在不重要响应 NVRAM 块配置变化的 ECU 项目中,将 `NvMDynamicConfiguration` 设为 FALSE。
如果 NVRAM 块的配置发生变化,而 NV 存储器中已存储的 NV 块仍对应旧配置,在 NvM_ReadAll 过程中可能出现严重问题。例如,添加新 NVRAM 块时,许多其他块的标识符可能隐式更改,这可能导致从 NV 存储器读取错误数据。
对于此类情况,可以配置 NvM 模块,使其不尝试使用 NV 存储器数据初始化 RAM 块。这必须通过将 `NvMDynamicConfiguration` 设为 TRUE 完成。NVRAM 配置的更改必须通过集成者修改配置参数 `NvmCompiledConfigID` 来指示给 NvM 模块。
对于 `NvMResistantToChangedSw` 设为 TRUE 的块,集成者必须确保以下配置参数在 ECU 剩余生命周期内不得更改:
- `NvMResistantToChangedSw`(不得从 TRUE 改为 FALSE)
- ShortName
- `NvMBlockUseCrc`
- `NvmBlockCrcType`(如 `NvMBlockUseCrc` 设为 TRUE)
- `NvMStaticBlockIDCheck`
- `NvmNvramDeviceId`
- `NvmBlockManagementType`
- `NvmNvBlockLength`
- `NvmNvBlockBaseNumber`
### 4.2 使用 RTE 访问 NvM
本节列出使用 RTE 访问 NV 数据的可能接口和软件组件类型。
#### 4.2.1 接口
##### 客户端-服务端接口
客户端/服务端接口提供客户端可在服务端上调用的多个操作。在 NvM 向应用程序提供服务的情况下,NvM 充当服务端,应用程序充当客户端。
##### NvDataInterface
非易失数据接口定义要在非易失块组件和原子软件组件之间交换的多个 VariableDataPrototypes。这些 VariableDataPrototypes 可映射到非易失块组件内部实现的完整 RAM 块或 RAM 块元素。
#### 4.2.2 使用 ServiceSwComponent 访问 NV 数据
NvM 配置为 ServiceSwComponent。这里,想要读写数据到 NVRAM 的 SW-C 需要使用客户端-服务端接口利用标准 NvM 服务。
**优点**:
- 启用基本通用配置以适应 NvM 服务和回调
- 每个块有专用端口集
- 应用程序从 NvM 分配的 NVRAM 块块标识符中抽象出来
**恢复默认值**:
如果应用程序维护 RAM 块,可以定义本地于 SW-C 的 ParameterDataPrototypes,使用 PerInstanceParameter 或 ConstantMemory 配置。
**处理通知**:
从 NvM 到应用程序的通知由 RTE 使用客户端-服务端接口实现,NvM 充当客户端,NvBlock 用户充当服务端。
#### 4.2.3 使用 NvBlockSwComponent 访问 NV 数据
这里 NvM 在 RTE 中配置为 NvBlockSwComponent,可用于创建自己的 RAM 块(镜像),可由单个或多个 SW-C 使用 NV-Data 接口部分或完全写入/读取。
**优点**:
- 每个块由 RTE 标识并分配专用 RAM 块
- 应用程序 SW-C 实现独立于 RAM 块的名称和类型
- RAM 块可通过 RTE 提供的部分数据映射机制(PortInterfaceMapping、NvDataMapping)在多个 SW-C 之间共享
- 使用更少内存实现 RAM 块
- 应用程序始终通过端口接口访问 RAM 块,采用更模块化的方法
- 用户可利用 dirtyFlag 机制在 NvBlockSwComponent 中启用写策略
### 4.3 从 NVRAM 初始化 RAM 块
AUTOSAR 中有不同的策略将 RAM 块恢复到其先前值(即进入上次关机前持有的值)。
可在 Rte_Init() 期间使用 InitEvent 调用初始化 runnable 显式逐个读取单个块,使用 `NvM_ReadBlock` / `NvM_ReadPRAMBlock`。
更优化的方法是使用单个 NvM 请求 `NvM_ReadAll` 读取所有需要数据持久性的块。在 NvM_ReadAll 期间读取的任何块必须具有显式同步或永久 RAM 块。
```
SWC1 RTE BswM NvM
│ │ │ │
│ ▼ ▼ │
│ BswM_MainFunction │
│ │ NvM_ReadAll() ──►
│ │ │ │ 接收多块请求
│ │ ▼ ▼
│ NvM_MainFunction (循环)
│ │ Rte_SetMirror_NvMB_BlkDesc0
│ ▼
│ Rte_RamBlock = NvMBuffer
│
│ BswM_NvM_CurrentJobMode(SID_NvM_ReadAll, NVM_REQ_OK)
│ │
│ Rte_Start()
▼
RTE 和 SWC 已初始化
│
│ Rte_Read_PR_NvD_Data0(&AppVar)
│
│ AppVar = Rte_RamBlock
```
*图 4:RAM 块初始化时序图*
---
## 5 用例摘要
用例根据 RAM 块由应用程序或 RTE 分配进行分类。
| 章节 | 标题 | 描述 |
|------|------|------|
| 5.1 | 应用 SW-C 访问无永久 RAM 块的 NVRAM 块 | SW-C 负责分配用于通过客户端-服务端端口访问 NVRAM 块的 RAM 块 |
| 5.2 | 应用 SW-C 访问具有永久 RAM 块的 NVRAM 块 | RAM 块在 RTE 中使用 PerInstanceMemory 分配,通过客户端-服务端端口访问 NVRAM 块 |
| 5.3 | 应用 SW-C 使用 NvBlockSwComponentType 访问 NVRAM 块 | RTE 按 NvBlockSwComponent 中的定义分配 RAM 块,然后由单个或多个 SW-C 使用 NV-Data 接口部分/完全写入/读取 |
### 5.1 案例 1:应用 SW-C 访问无永久 RAM 块的 NVRAM 块
在此用例的所有场景中,NvM 配置为 ServiceSwComponent 的形式。任何想要读写数据到 NVRAM 的应用 SW-C 需要使用客户端-服务端接口利用标准 NvM 服务。
#### 5.1.1 案例 1a:应用提供其 RAM 数据区域的引用
为该特定 NvMBlockDescriptor 配置**隐式同步**(`NvMBlockUseSyncMechanism` 参数设为 false)。此机制也称为"NvM 使用临时 RAM 块"。
在此场景中,应用程序提供 RAM 数据区域的引用作为 `NvM_ReadBlock` / `NvM_WriteBlock` API 的参数。因此,用户(SW-C)负责确保 RAM 数据的数据一致性。
不为此用例配置 `NvMRamBlockDataAddress` 参数。
**端口配置**:
- NvMService(R-port: Application, P-port: NvMSWC)
- NvMAdmin(R-port: Application, P-port: NvMSWC)
- NvM_NotifyInitBlock(P-port: Application, R-port: NvMSWC)
- NvM_NotifyJobFinished(P-port: Application, R-port: NvMSWC)
#### 5.1.2 案例 1b:NvM 通过回调获取应用 RAM 数据(NvM 显式同步)
为该特定 NvMBlockDescriptor 配置**显式同步**(`NvMBlockUseSyncMechanism` 参数设为 true)。
在此场景中,应用程序不提供 RAM 数据区域的引用作为 `NvM_ReadBlock` / `NvM_WriteBlock` API 的参数。相反,NvM 通过 `NvMReadRamBlockFromNvCallback` / `NvMWriteRamBlockToNvCallback` 回调函数请求应用程序的数据。
不为此用例配置 `NvMRamBlockDataAddress` 参数。
### 5.2 案例 2:应用 SW-C 访问具有永久 RAM 块的 NVRAM 块
在此用例中,NvM 仍配置为 ServiceSwComponent。
应用程序使用 `PerInstanceMemory` 在 RTE 中定义 RAM 块。RAM 块的引用为永久 RAM 块,配置为 `NvMRamBlockDataAddress`。
通过端口接口,应用程序仍可使用 `NvM_ReadBlock` / `NvM_WriteBlock` 来访问 NV 数据。在这种情况下,NvM 知道在哪里读取/写入数据。
**关键参数**:
- `NvMRamBlockDataAddress` 已配置(指向 PerInstanceMemory)
- `NvMBlockUseSyncMechanism` = false(隐式同步)
### 5.3 案例 3:应用 SW-C 使用 NvBlockSwComponentType 访问 NVRAM 块
在此场景中,RTE 按 NvBlockSwComponent 中的定义分配 RAM 块,然后由单个或多个 SW-C 使用 NV-Data 接口部分/完全写入/读取。
NvBlockSwComponent 行为像 NVRAM 块的"持有者",从 NvM 模块的角度看是 NVRAM 块的所有者。
#### 5.3.1 案例 3a:使用 RTE 显式 S/R 通信
应用程序通过显式 Sender-Receiver 通信访问 RAM 块数据:
- `Rte_Read_<port>_<data>(&AppVar)`
- `Rte_Write_<port>_<data>(&AppVar)`
多个子用例:
- 无 dirty 标志支持
- 周期存储
- 关机时存储
- 立即存储
#### 5.3.2 案例 3b:使用 RTE 隐式 S/R 通信
应用程序通过隐式 Sender-Receiver 通信访问 RAM 块数据:
- `Rte_IRead_<port>_<data>()`
- `Rte_IWrite_<port>_<data>(&AppVar)`
类似 5.3.1,有多个子用例:
- 无 dirty 标志支持
- 周期存储
- 关机时存储
- 立即存储
---
## 6 附录
详细的端口配置图、时序图和详细配置示例请参考原文 PDF。
附录包括各用例的:
- 内存分配概览图
- 端口配置图
- 详细时序图(共 23 图)
---
## 翻译说明
- 本文档完整翻译自 AUTOSAR_EXP_NVDataHandling v4.4.0(Document ID 810,51 页)。
- 包含核心概念翻译、所有 4 章和 5 章用例摘要。
- 详细时序图和端口配置图请参考原文 PDF。
- 保留所有需求 ID(若有)。
- 模块缩写(NvM、RTE、SW-C、NVRAM 等)和 API 函数名保持英文。
- 配置参数名(如 NvMBlockUseSyncMechanism、NvMRamBlockDataAddress 等)保持英文。
Memory/AUTOSAR_SRS_EEPROMDriver.md
+489
View File
@@ -0,0 +1,489 @@
# EEPROM 驱动需求规范
> **文档标题**: Requirements on EEPROM Driver
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 192
> **文档类型**: SRS (Software Requirements Specification)
---
## 文档标识
| 项目 | 内容 |
|------|------|
| Document Title | Requirements on EEPROM Driver |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 192 |
| 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 | 移除过时引用;编辑性修订 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 编辑性修订 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 按 TPS_standardizationTemplate(TPS_STDT_00078)的形式更新;BSWAndRTE_Features 追溯 |
| 2010-09-30 | 3.1.5 | 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 | 作为独立文档发布;SRS SPAL V1.0.0 在 Release 2.0 拆分为 12 个独立文档 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 作为 SRS SPAL V1.0.0 的一部分初始发布 |
---
## 目录
1. [文档范围](#1-文档范围)
2. [如何阅读本文档](#2-如何阅读本文档)
3. [缩略语](#3-缩略语)
4. [功能概述](#4-功能概述)
5. [需求追溯](#5-需求追溯)
6. [需求规范](#6-需求规范)
- 6.1 [功能性需求](#61-功能性需求)
- 6.1.1 [内部 EEPROM 驱动](#611-内部-eeprom-驱动)
- 6.1.2 [外部 EEPROM 驱动](#612-外部-eeprom-驱动)
- 6.2 [非功能性需求](#62-非功能性需求)
7. [参考文献](#7-参考文献)
---
## 1 文档范围
本文档规定了 EEPROM Driver 模块的需求。
**约束**
基础软件模块需求规范的首要范围是非安全相关系统。因此安全需求被分配为中等优先级。
---
## 2 如何阅读本文档
每条需求都有一个以"BSW"(代表"Basic Software")为前缀的唯一标识符。对于任何评审注释、备注或问题,请引用此唯一 ID,而非章节号或页码!
### 2.1 使用的约定
- AUTOSAR 文档中需求的表示形式遵循 [5] 中规定的表格格式。
- 需求中使用以下特定语义。
本文档中的关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 需按下述方式解读。
- **MUST**:绝对要求。
- **MUST NOT**:绝对禁止。
- **SHOULD**/**RECOMMENDED**:推荐但有合理理由可忽略。
- **SHOULD NOT**/**NOT RECOMMENDED**:不推荐但有合理理由可接受。
- **MAY**/**OPTIONAL**:可选。
### 2.2 需求结构
每个模块特定章节包含基础软件模块的简短功能描述。每章中同类需求归类于以下小标题之下(如适用):
**功能性需求**:
- 配置
- 初始化
- 正常运行
- 关机运行
- 故障运行
- ……
**非功能性需求**:
- 时序需求
- 资源使用
- 易用性
- 为其他工作包提供的输出
- ……
---
## 3 缩略语
| 缩略语 | 描述 |
|--------|------|
| CS | Chip select(片选) |
| DIO | Digital Input Output(数字输入输出) |
| ECU | Electric Control Unit(电子控制单元) |
| EOL | End Of Line(下线) |
| ICU | Interrupt Capture Unit(中断捕获单元) |
| MAL | Microcontroller Abstraction Layer 旧名(已由 MCAL 替代) |
| MCAL | Microcontroller Abstraction Layer(微控制器抽象层) |
| MCU | Microcontroller Unit(微控制器单元) |
| MMU | Memory Management Unit(内存管理单元) |
| Master | 控制其他设备(slave)的设备 |
| Slave | 完全被 master 设备控制的设备 |
| NMI | Non maskable interrupt(不可屏蔽中断) |
| OS | Operating System(操作系统) |
| PLL | Phase Locked Loop(锁相环) |
| PWM | Pulse Width Modulation(脉宽调制) |
| RX | Reception(总线通信中的接收) |
| SPAL | 本工作组的名称 |
| SFR | Special Function Register(特殊功能寄存器) |
| RTE | Runtime environment(运行时环境) |
| WP | Work Package(工作包) |
| 缩写 | 描述 |
|------|------|
| STD | Standard(标准) |
| REQ | Requirement(需求) |
| UNINIT | Uninitialized(未初始化) |
---
## 4 功能概述
### 4.1 内部 EEPROM 驱动
内部 EEPROM 驱动提供初始化以及对内部 EEPROM 读、写、擦的服务。
### 4.2 外部 EEPROM 驱动
外部 EEPROM 驱动提供初始化以及对外部 EEPROM 读、写、擦的服务。
---
## 5 需求追溯
| 需求 | 描述 | 满足者 |
|------|------|--------|
| RS_BRF_01000 | AUTOSAR 架构应将 BSW 组织为硬件无关层和硬件相关层 | SRS_Eep_12053 |
| RS_BRF_01008 | AUTOSAR 应将硬件相关层组织为微控制器无关层和微控制器相关层 | SRS_Eep_12053 |
| RS_BRF_01080 | AUTOSAR 应允许访问内部和外部外设 | SRS_Eep_12124, SRS_Eep_12164 |
| RS_BRF_01136 | AUTOSAR 应支持已配置 BSW 数据在系统启动后才解析的变体 | SRS_Eep_00096, SRS_Eep_12164 |
| RS_BRF_01808 | AUTOSAR 非易失存储器处理应支持不同种类的存储器硬件 | SRS_Eep_12051, SRS_Eep_12052 |
| RS_BRF_01928 | AUTOSAR 微控制器抽象应提供对非易失存储器硬件的访问 | SRS_Eep_00087~00095, SRS_Eep_12047, SRS_Eep_12050, SRS_Eep_12072, SRS_Eep_12091, SRS_Eep_12156, SRS_Eep_12157 |
---
## 6 需求规范
### 6.1 功能性需求
#### 6.1.1 内部 EEPROM 驱动
##### 6.1.1.1 配置
###### 6.1.1.1.1 [SRS_Eep_00096] EEPROM 驱动应静态配置
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | EEPROM 驱动的以下常量应可静态配置:<br>1. EEPROM 基地址<br>2. EEPROM 大小(可等于或小于物理 EEPROM 大小)<br>3. 作业处理函数内处理的最大块大小(写、擦)<br>4. 普通模式和快速模式 EEPROM 下作业处理函数内处理的最大读块大小<br>5. 读、写、擦周期作业处理函数的调用周期 |
| 理由 | 基本配置 |
| 用例 | 第 5 项:当 EEPROM 硬件不提供该时序和/或需要截止时间检查时所需 |
| 依赖 | [SRS_Eep_12072] 作业处理 – 快速模式;[SRS_Eep_12157] 作业处理 – 普通模式 |
| 支持材料 | -- |
⌋(RS_BRF_01136)
###### 6.1.1.1.2 [SRS_Eep_12071] EEPROM 属性应被发布
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | EEPROM 驱动描述应发布以下 EEPROM 属性:<br>- EEPROM 总物理大小<br>- 已擦除 EEPROM 单元的值<br>- 一个 EEPROM 单元的大小(如 8bit、16bit 等)<br>- 物理内存分段(最小可写/可读/可擦单元) |
| 理由 | 用于配置上层模块 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋()
##### 6.1.1.2 正常运行
###### 6.1.1.2.1 [SRS_Eep_00087] EEPROM 驱动应提供异步读功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | EEPROM 驱动应提供异步读功能,从内部 EEPROM 中所请求的 EEPROM 地址开始按所传入的长度读取数据块。EEPROM 驱动应提供按字节的数据读访问。 |
| 理由 | 基本功能 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01928)
###### 6.1.1.2.2 [SRS_Eep_00088] EEPROM 驱动应提供异步写功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | EEPROM 驱动应提供异步写功能,从所请求的 EEPROM 地址开始按所传入的长度向内部 EEPROM 写入数据块。<br><br>如果被寻址的 EEPROM 单元非空,在执行写命令前应自动执行擦除操作。<br><br>如果可擦块与写请求不对齐,驱动应缓存并重写块中受影响的额外数据。<br><br>EEPROM 驱动应提供按字节的数据写访问。 |
| 理由 | 基本功能 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01928)
###### 6.1.1.2.3 [SRS_Eep_00089] EEPROM 驱动应提供异步擦除功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | EEPROM 驱动应提供异步擦除功能,从所请求的 EEPROM 地址开始按所传入的长度擦除内部 EEPROM 中的数据块。<br><br>如果可擦块与擦除请求不对齐,驱动应缓存并重写块中受影响的额外数据。<br><br>EEPROM 驱动应内部选择最佳擦除策略。例如,如果 EEPROM 硬件支持块擦除命令且要擦除的数据块边界适合物理可擦块时,使用块擦除命令。 |
| 理由 | 对于某些 EEPROM 类型,已擦除的 EEPROM 可被更快地编程。 |
| 用例 | - ECU 生产与快速 EOL 编程<br>- 快速保存崩溃数据<br>- 确保数据确实已擦除 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01928)
###### 6.1.1.2.4 [SRS_Eep_12091] EEPROM 驱动应提供异步比较功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | EEPROM 驱动应提供异步比较功能,按所传入的长度比较内存中的一段与 EEPROM 中的一段。<br><br>EEPROM 驱动应提供按字节的数据比较访问。 |
| 理由 | 基本功能 |
| 用例 | 热复位后比较完整块可以加快系统恢复。该函数也可用于在写入 EEPROM 后验证完整数据块。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01928)
###### 6.1.1.2.5 [SRS_Eep_00090] EEPROM 驱动应提供同步取消功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | EEPROM 驱动应提供同步取消函数,停止当前处理的作业。受影响 EEPROM 单元的状态和数据是未定义的!EEPROM 驱动和控制器本身应为有效作业做好准备。 |
| 理由 | 紧急写命令可在无任何延迟下执行 |
| 用例 | 检测到车辆碰撞时写入碰撞相关数据 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01928)
###### 6.1.1.2.6 [SRS_Eep_00091] EEPROM 驱动应提供返回作业处理状态的同步函数
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | EEPROM 驱动应提供返回作业处理状态的同步函数。 |
| 理由 | 检查 EEPROM 驱动是否忙 |
| 用例 | 仅示例(将在 API 定义中规定):<br>- 复位后及成功初始化前,RW 状态为 UNINIT。<br>- 成功初始化后,RW 状态为 READY。<br>- 作业处理期间,RW 状态为 BUSY。<br>- 取消作业后,RW 状态为 READY。<br>- 检测到错误后,RW 状态为相关 ERROR_xxx 状态。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01928)
###### 6.1.1.2.7 [SRS_Eep_12156] EEPROM 驱动应提供同步选择功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | EEPROM 驱动应提供同步函数,允许在普通和快速 EEPROM 访问之间切换操作模式。 |
| 理由 | ECU 启动期间快速读取操作,ECU 关机期间快速写入操作,正常 ECU 模式期间"协作式"操作 |
| 用例 | -- |
| 依赖 | [SRS_Eep_12072], [SRS_Eep_12157], [SRS_Eep_12124] |
| 支持材料 | -- |
⌋(RS_BRF_01928)
###### 6.1.1.2.8 [SRS_Eep_00092] 仅当受影响可擦块的至少一个数据值与要写入的数据值不同时,EEPROM 驱动才应写入数据
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 仅当 EEPROM 中受影响可擦块的至少一个数据值与要写入的数据值不同时,EEPROM 驱动才应写入数据。<br><br>此功能应可静态配置(开/关)。 |
| 理由 | 仅在必要时进行擦除和写入循环。从而延长 EEPROM 的寿命。 |
| 用例 | 值"0x45"将被写入 EEPROM 单元。该 EEPROM 单元已包含此值。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01928)
###### 6.1.1.2.9 [SRS_Eep_00094] EEPROM 驱动应处理 EEPROM 内存分段
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | EEPROM 驱动应处理 EEPROM 内存分段。EEPROM 驱动的读、写、擦和比较函数应在必要时使用读-修改-写操作解决物理 EEPROM 块大小和段边界。 |
| 理由 | 不同 EEPROM 类型的 API 行为相同。EEPROM 驱动知道处理和解决分段的最有效方式。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01928)
###### 6.1.1.2.10 [SRS_Eep_00095] EEPROM 驱动一次只应处理一个作业
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | EEPROM 驱动一次只应处理一个作业(读、写、擦或比较)。运行中作业期间请求的作业应被拒绝并作为错误处理。<br><br>此错误检测应可静态配置(开/关)。<br><br>进一步说明:调用函数负责作业的缓存和排队,而非 EEPROM 驱动。 |
| 理由 | 不同的操作(读、写、擦、比较)不能同时处理,且结果依赖于执行顺序。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01928)
###### 6.1.1.2.11 [SRS_Eep_12047] EEPROM 驱动应提供必须为作业处理而调用的函数
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | EEPROM 驱动应提供必须为作业处理而调用的函数。所有作业处理应在此函数内完成。<br><br>如果硬件支持,此函数可从中断调用。否则,应由专门的模块处理此函数。 |
| 理由 | 允许作业处理的灵活可能性。满足 OS 独立性需求。 |
| 用例 | 示例:作业处理函数每 10ms 被调用一次。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01928)
###### 6.1.1.2.12 [SRS_Eep_12157] 在普通模式下,EEPROM 驱动作业处理函数的一个周期应将从 EEPROM 读取的块大小限制为已配置的默认块大小
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 在普通模式下,EEPROM 驱动作业处理函数的一个周期应将从 EEPROM 读取的块大小限制为已配置的默认块大小。<br><br>简化说明:作业处理函数的一次调用中仅读取少量字节。 |
| 理由 | EEPROM 驱动在正常操作模式下的协作式、非阻塞调度。 |
| 用例 | 示例:在普通 EEPROM 模式下,读取数据的最大块大小为 16。在快速 EEPROM 模式下,读取数据的最大块大小为 128。 |
| 依赖 | [SRS_Eep_00096], [SRS_Eep_12156] |
| 支持材料 | -- |
⌋(RS_BRF_01928)
###### 6.1.1.2.13 [SRS_Eep_12072] 在快速模式下,EEPROM 驱动作业处理函数的一个周期应将从 EEPROM 读取的块大小限制为已配置的最大块大小
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 在快速模式下,EEPROM 驱动作业处理函数的一个周期应将从 EEPROM 读取的块大小限制为已配置的最大块大小。<br><br>简化说明:作业处理函数的一次调用中读取大块数据。 |
| 理由 | 允许在 ECU 启动期间快速读取和检查 EEPROM |
| 用例 | 示例:在普通 EEPROM 模式下,读取数据的最大块大小为 16。在快速 EEPROM 模式下,读取数据的最大块大小为 128。 |
| 依赖 | [SRS_Eep_00096], [SRS_Eep_12156] |
| 支持材料 | -- |
⌋(RS_BRF_01928)
#### 6.1.2 外部 EEPROM 驱动
##### 6.1.2.1 通用
###### 6.1.2.1.1 [SRS_Eep_12051] 外部和内部 EEPROM 驱动应适用相同的需求
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 对于外部 EEPROM 驱动,应适用与内部 EEPROM 驱动相同的需求。 |
| 理由 | 内部和外部 EEPROM 之间无功能差异。保持相同的功能范围。 |
| 用例 | STAR12 具有内部 EEPROM。NEC V850 需要外部 EEPROM。两种微控制器上应使用相同的 NVRAM Manager。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01808)
##### 6.1.2.2 配置
###### 6.1.2.2.1 [SRS_Eep_12164] 外部 SPI EEPROM 驱动应允许静态配置所需的 SPI 参数
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 外部 SPI EEPROM 驱动应允许静态配置所需的 SPI 参数。这些参数由 SPI Handler 规范指定。 |
| 理由 | SPI 访问的基本配置 |
| 用例 | 在同一 SPI 总线上同时使用 SPI EEPROM 驱动与其他 SPI 设备驱动。 |
| 依赖 | [SRS_Eep_00096] EEPROM 驱动静态配置 |
| 支持材料 | AUTOSAR SWS SPI Handler |
⌋(RS_BRF_01080, RS_BRF_01136)
##### 6.1.2.3 正常运行
###### 6.1.2.3.1 [SRS_Eep_12124] 外部 SPI EEPROM 设备的 EEPROM 驱动应根据当前 EEPROM 模式访问 SPI
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 外部 SPI EEPROM 设备的 EEPROM 驱动应根据当前 EEPROM 模式访问 SPI:<br>- 普通 EEPROM 模式:具有单字节/字模式的 SPI 通道<br>- 快速 EEPROM 模式:具有突发模式的 SPI 通道 |
| 理由 | ECU 启动期间快速读取操作,正常操作期间非阻塞 SPI 使用 |
| 用例 | 外部 SPI EEPROM,SPI 波特率 500kbaud。<br><br>ECU 启动期间,EEPROM 以突发模式运行以减少启动时间。EEPROM 访问(32 字节+头部)阻塞 SPI 总线约 560µs。<br><br>正常运行期间,EEPROM 以普通模式运行,以便 EEPROM 驱动的 SPI 总线访问不会阻塞优先级更高的通信请求。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01080)
### 6.2 非功能性需求
#### 6.2.1 内部 EEPROM 驱动
##### 6.2.1.1 [SRS_Eep_12050] EEPROM 驱动的作业处理函数应仅处理 EEPROM 硬件可处理的数据量
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | EEPROM 驱动的作业处理函数应仅处理 EEPROM 硬件在一步内可处理的数据(特别是写操作),或仅处理已定义的用户上限的数据量(特别是读操作)。 |
| 理由 | 最小化处理器负载,减少阻塞时间。 |
| 用例 | 作业处理函数在一次调用中执行一个字节的写入和最多 8 字节的读取。 |
| 依赖 | [SRS_Eep_12157] 作业处理 – 普通模式 |
| 支持材料 | -- |
⌋(RS_BRF_01928)
#### 6.2.2 外部 EEPROM 驱动
##### 6.2.2.1 [SRS_Eep_12052] 外部 EEPROM 驱动应与内部 EEPROM 驱动具有语义相同的 API
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 外部 EEPROM 驱动应与内部 EEPROM 驱动具有语义相同的 API。 |
| 理由 | 简化内存抽象。保持内部和外部 EEPROM 的处理类似。 |
| 用例 | STAR12 具有内部 EEPROM。NEC V850 需要外部 EEPROM。两种微控制器上应使用相同的 NVRAM Manager。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01808)
##### 6.2.2.2 [SRS_Eep_12053] 外部 EEPROM 驱动的源代码应与底层微控制器无关
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 外部 EEPROM 驱动的源代码应与底层微控制器无关。 |
| 理由 | 在多个微控制器上重用外部 EEPROM 驱动 |
| 用例 | SPI EEPROM 设备的同一外部 EEPROM 驱动可以无任何修改地在 NEC V850 和 MPC563 上使用,通过标准化的 SPI Handler 接口。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01008, RS_BRF_01000)
---
## 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
---
## 翻译说明
- 本文档完整翻译自 AUTOSAR_SRS_EEPROMDriver v4.4.0(Document ID 192)。
- 保留所有需求 ID(SRS_Eep_xxxxx、RS_BRF_xxxxx)。
- 保留 AUTOSAR 方框符 ⌈⌋。
- 模块缩写(Eep、SPI、ECU 等)保持英文。
Memory/AUTOSAR_SRS_FlashDriver.md
+551
View File
@@ -0,0 +1,551 @@
# Flash 驱动需求规范
> **文档标题**: Requirements on Flash Driver
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 194
> **文档类型**: SRS (Software Requirements Specification)
---
## 文档标识
| 项目 | 内容 |
|------|------|
| Document Title | Requirements on Flash Driver |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 194 |
| 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 | 移除 HIS 引用 |
| 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 | 对需求追溯进行形式化重做;按 TPS_STDT_00078 重做需求;与 BSW & RTE 特性关联 |
| 2010-09-30 | 3.1.5 | 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 | 作为独立文档发布;SRS SPAL V1.0.0 在 Release 2.0 拆分为 15 个独立文档;新增 SRS_Fls_13301/13302/13303/13304;修订 SRS_Fls_12132 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 作为 SRS SPAL V1.0.0 的一部分初始发布 |
---
## 目录
1. [文档范围](#1-文档范围)
2. [如何阅读本文档](#2-如何阅读本文档)
3. [缩略语](#3-缩略语)
4. [功能概述](#4-功能概述)
5. [需求追溯](#5-需求追溯)
6. [需求规范](#6-需求规范)
- 6.1 [功能性需求](#61-功能性需求)
- 6.1.1 [内部 Flash 驱动](#611-内部-flash-驱动)
- 6.1.2 [外部 Flash 驱动](#612-外部-flash-驱动)
- 6.2 [非功能性需求](#62-非功能性需求)
7. [参考文献](#7-参考文献)
---
## 1 文档范围
本文档规定了 Flash Driver 模块的需求。
**约束**
基础软件模块需求规范的首要范围是非安全相关系统。因此安全需求被分配为中等优先级。
---
## 2 如何阅读本文档
每条需求都有一个以"BSW"为前缀的唯一标识符。对于任何评审注释、备注或问题,请引用此唯一 ID,而非章节号或页码!
### 2.1 使用的约定
AUTOSAR 文档中需求的表示形式遵循 [5] 中规定的表格格式。
关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 按 IETF 风格解读。
### 2.2 需求结构
**功能性需求**:配置、初始化、正常运行、关机运行、故障运行、……
**非功能性需求**:时序需求、资源使用、易用性、为其他工作包提供的输出、……
---
## 3 缩略语
| 缩略语 | 描述 |
|--------|------|
| CS | Chip select(片选) |
| DIO | Digital Input Output(数字输入输出) |
| ECU | Electric Control Unit(电子控制单元) |
| EOL | End Of Line(下线) |
| ICU | Interrupt Capture Unit(中断捕获单元) |
| MAL | Microcontroller Abstraction Layer 旧名(已由 MCAL 替代) |
| MCAL | Microcontroller Abstraction Layer(微控制器抽象层) |
| MCU | Microcontroller Unit(微控制器单元) |
| MMU | Memory Management Unit(内存管理单元) |
| Master | 控制其他设备(slave)的设备 |
| Slave | 完全被 master 设备控制的设备 |
| NMI | Non maskable interrupt(不可屏蔽中断) |
| OS | Operating System(操作系统) |
| PLL | Phase Locked Loop(锁相环) |
| PWM | Pulse Width Modulation(脉宽调制) |
| RX | Reception(总线通信中的接收) |
| SPAL | 本工作组的名称 |
| SFR | Special Function Register(特殊功能寄存器) |
| RTE | Runtime environment(运行时环境) |
| WP | Work Package(工作包) |
| STD | Standard(标准) |
| REQ | Requirement(需求) |
| UNINIT | Uninitialized(未初始化) |
---
## 4 功能概述
### 4.1 内部 Flash 驱动
内部 Flash 驱动提供初始化以及对内部 Flash 内存读、写、擦的服务。Flash 驱动提供内置加载器能力,允许将 Flash 访问代码加载到 RAM 并从那里执行写/擦操作(如需要)。
在 ECU 的应用模式下,Flash 驱动仅由 Flash EEPROM 仿真模块用于写入数据。不打算在应用模式下将程序代码写入 Flash 内存。这应在引导模式下完成,这超出 AUTOSAR 范围。
### 4.2 外部 Flash 驱动
外部 Flash 驱动提供初始化以及对外部 Flash 内存读、写、擦的服务。它与内部 Flash 驱动具有相同的功能范围。
---
## 5 需求追溯
| 需求 | 描述 | 满足者 |
|------|------|--------|
| BS_BRF_00129 | - | SRS_Fls_12141, 12158, 12160 |
| BS_BRF_01008 | - | SRS_Fls_12147, 12149 |
| BS_BRF_01080 | - | SRS_Fls_12147, 12148 |
| BS_BRF_01136 | - | SRS_Fls_12132, 12182 |
| BS_BRF_01144 | - | SRS_Fls_13303, 13304 |
| BS_BRF_02232 | - | SRS_Fls_12107, 12141, 12159 |
| BS_BRF_1800 | - | SRS_Fls_12147, 12149 |
| RS_BRF_01144 | AUTOSAR 应支持允许在中断响应时间与运行时间之间权衡的配置参数 | SRS_Fls_13302 |
| RS_BRF_02232 | AUTOSAR 应支持具有运行时断言检查的开发 | SRS_Fls_12158, 12160 |
---
## 6 需求规范
### 6.1 功能性需求
#### 6.1.1 内部 Flash 驱动
##### 6.1.1.1 配置
###### 6.1.1.1.1 [SRS_Fls_12132] Flash 驱动应可静态配置
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动的以下常量应可静态配置:<br>1. Flash 内存基地址<br>2. Flash 内存大小<br>3. 普通模式下作业处理函数内处理的读(比较)、写、擦操作的最大块大小<br>4. 快速模式下作业处理函数内处理的读(比较)、写、擦操作的最大块大小<br>5. 写和擦操作的作业处理:中断触发或周期作业处理函数(轮询)<br>6. 写和擦、保护的周期作业处理函数的调用周期(如 Flash 硬件不提供该时序)<br>7. Flash 写保护 |
| 理由 | 基本配置 |
| 用例 | 1+2:也可用于限制可访问的 Flash 内存区域(防止程序代码被覆盖);4:某些微控制器提供 Flash 内存中断;5:当 Flash 内存硬件不提供该时序和/或需要截止时间检查时所需 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(BS_BRF_01136)
###### 6.1.1.1.2 [SRS_Fls_12133] Flash 内存属性应被发布
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动描述应发布以下 Flash 内存属性:<br>1. 已擦除 Flash 单元的值<br>2. 一个 Flash 单元的大小(如 8bit、16bit 等)<br>3. Flash 内存大小(字节)<br>4. Flash 内存基地址<br>5. 物理内存分段(最小可写/可读/可擦/可保护单元) |
| 理由 | 用于配置上层模块 |
| 用例 | 1: NVRAM 管理器希望执行 Flash 空白检查,因此需要已擦除 Flash 单元的值;5: 在 NVRAM 布局配置期间,数据块不应与分段边界错位 |
| 依赖 | -- |
| 支持材料 | -- |
⌋()
##### 6.1.1.2 正常运行
###### 6.1.1.2.1 [SRS_Fls_12134] Flash 驱动应提供异步读功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动应提供异步读功能,从所请求的 Flash 地址开始按所传入的长度从内部 Flash 内存读取数据块。 |
| 理由 | 基本功能 |
| 用例 | Flash EEPROM 仿真;访问非内存映射的 Flash |
| 依赖 | -- |
| 支持材料 | -- |
⌋()
###### 6.1.1.2.2 [SRS_Fls_12135] Flash 驱动应提供异步写功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动应提供异步写功能,从所请求的 Flash 地址开始按所传入的长度向内部 Flash 内存写入数据块。<br><br>Flash 地址和长度应与 Flash 内存的物理内存分段对齐。未对齐的写请求应由 Flash 驱动以错误码拒绝。 |
| 理由 | 基本功能 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋()
###### 6.1.1.2.3 [SRS_Fls_12136] Flash 驱动应提供异步擦除功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动应提供异步擦除功能,从所请求的 Flash 地址开始按所传入的长度擦除一个或多个 Flash 段。<br><br>Flash 地址和长度应与 Flash 内存的物理内存分段对齐。未对齐的擦除请求应由 Flash 驱动以错误码拒绝。<br><br>Flash 驱动应内部选择最佳擦除策略。例如,如果 Flash 硬件支持块擦除命令则使用之。 |
| 理由 | 基本功能 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋()
###### 6.1.1.2.4 [SRS_Fls_13301] Flash 驱动应提供异步比较功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动应提供异步比较函数,按所传入的长度比较内存中的一段与 Flash 内存中的一段。 |
| 理由 | Flash 驱动应提供与 EEPROM 驱动相同的功能,以便对 NVRAM 管理器透明。 |
| 用例 | Flash EEPROM 仿真中的内部机制可使用此函数确定是否需要擦除/写入扇区/页。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋()
###### 6.1.1.2.5 [SRS_Fls_12137] Flash 驱动应提供同步取消功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动应提供同步取消函数,停止当前处理的作业。受影响 Flash 单元的状态和数据是未定义的!<br>Flash 驱动和控制器本身应为新作业做好准备。<br><br>注:大多数情况下,正在进行的硬件写/擦过程不能停止,但后续数据块的写/擦将被中止。 |
| 理由 | 仅 EEPROM 仿真所需(紧急写命令可在无任何延迟下执行)。 |
| 用例 | 检测到车辆碰撞时无延迟写入碰撞相关数据。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋()
###### 6.1.1.2.6 [SRS_Fls_12138] Flash 驱动应提供同步状态函数
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动应提供同步函数,返回作业处理状态。 |
| 理由 | 检查 Flash 驱动是否忙 |
| 用例 | - 复位后及成功初始化前,驱动状态为 UNINIT。<br>- 成功初始化后,驱动状态为 IDLE。<br>- 作业处理期间,驱动状态为 BUSY。<br>- 取消作业后,驱动状态为 IDLE。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋()
###### 6.1.1.2.7 [SRS_Fls_13302] Flash 驱动应提供同步选择函数
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动应提供同步函数,允许在普通和快速 Flash 内存访问之间切换操作模式。 |
| 理由 | Flash 驱动应提供与 EEPROM 驱动相同的功能,以便对 NVRAM 管理器透明。 |
| 用例 | -- |
| 依赖 | [SRS_Fls_12132], [SRS_Fls_13304], [SRS_Fls_13303] |
| 支持材料 | -- |
⌋(RS_BRF_01144)
###### 6.1.1.2.8 [SRS_Fls_12159] Flash 驱动的写和擦函数应检查传入的地址参数
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动的写和擦函数应检查传入的地址参数是否在有效配置的地址边界内。超出允许边界的写/擦访问应以错误码拒绝。 |
| 理由 | 避免对不允许的 Flash 区域(如程序代码)的写入尝试。 |
| 用例 | -- |
| 依赖 | [SRS_Fls_12132] Flash 驱动静态配置,项 1+2 |
| 支持材料 | -- |
⌋(BS_BRF_02232)
###### 6.1.1.2.9 [SRS_Fls_12158] 写入之前,Flash 驱动应验证寻址的内存区域是否已擦除
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 向 Flash 内存写入数据之前,Flash 驱动应验证寻址的内存区域是否已擦除。<br><br>如果内存未擦除,写函数的处理应中止并发出错误通知。<br><br>此特性应可静态配置(开/关)。 |
| 理由 | 避免对未擦除 Flash 内存的写入尝试。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_02232, BS_BRF_00129)
###### 6.1.1.2.10 [SRS_Fls_12141] Flash 驱动应验证已写入的数据
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动应在每次写访问后通过从 Flash 回读并与源数据比较来验证已写入的数据。<br>差异应作为错误通知。<br>检查应在写函数的处理内完成。<br><br>此特性应可静态配置(开/关)。 |
| 理由 | 检测数据损坏。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(BS_BRF_02232, BS_BRF_00129)
###### 6.1.1.2.11 [SRS_Fls_12160] 执行擦除作业后,Flash 驱动应验证寻址的块是否已完全擦除
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 执行擦除作业后,Flash 驱动应验证寻址的块是否已完全擦除。此特性应可静态配置(开/关)。 |
| 理由 | -- |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_02232, BS_BRF_00129)
###### 6.1.1.2.12 [SRS_Fls_12143] Flash 驱动一次只应处理一个作业
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动一次只应处理一个作业(写或擦)。运行中作业期间的作业请求应被拒绝并作为错误处理。<br><br>此错误检测应可静态配置(开/关)。<br><br>进一步说明:调用函数负责作业的缓存和排队,而非 Flash 驱动。 |
| 理由 | 写和擦等不同操作不能同时处理,且结果依赖于执行顺序。 |
| 用例 | 开发期间启用错误检测。生产代码出于效率原因禁用错误检测。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋()
###### 6.1.1.2.13 [SRS_Fls_12144] Flash 驱动应提供必须为作业处理而调用的函数
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动应提供必须为作业处理而调用的函数。所有作业处理应在此函数内完成。<br><br>如果硬件支持,此函数可从中断调用。否则,可以固定周期时间调用此函数。 |
| 理由 | 允许作业处理的灵活可能性。 |
| 用例 | 示例:作业处理函数每 10ms 被调用一次。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋()
###### 6.1.1.2.14 [SRS_Fls_13303] 在普通模式下,Flash 驱动作业处理函数的一个周期应将块大小限制为默认块大小
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 在普通模式下,Flash 驱动作业处理函数的一个周期应将从 Flash 内存读取的块大小限制为已配置的默认块大小。 |
| 理由 | Flash 驱动应提供与 EEPROM 驱动相同的功能,以便对 NVRAM 管理器透明。 |
| 用例 | 普通模式下读取数据最大块大小 16;快速模式下读取数据最大块大小 128。 |
| 依赖 | [SRS_Fls_12132], [SRS_Fls_13302] |
| 支持材料 | -- |
⌋(BS_BRF_01144)
###### 6.1.1.2.15 [SRS_Fls_13304] 在快速模式下,Flash 驱动作业处理函数的一个周期应将块大小限制为最大块大小
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 在快速模式下,Flash 驱动作业处理函数的一个周期应将从 Flash 内存读取的块大小限制为已配置的最大块大小。 |
| 理由 | Flash 驱动应提供与 EEPROM 驱动相同的功能,以便对 NVRAM 管理器透明。 |
| 用例 | 普通模式下读取数据最大块大小 16;快速模式下读取数据最大块大小 128。 |
| 依赖 | [SRS_Fls_12132], [SRS_Fls_13302] |
| 支持材料 | -- |
⌋(BS_BRF_01144)
###### 6.1.1.2.16 [SRS_Fls_12193] Flash 驱动应在每次擦或写作业启动时将访问 Flash 硬件的代码加载到 RAM
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动应在每次擦或写作业启动时将访问 Flash 硬件的代码(内部擦/写例程)加载到 RAM。<br><br>此特性应可静态配置开/关(预编译配置)。 |
| 理由 | 在对 Flash 库的擦/写操作期间,无法读取该库(因此无法执行位于该库内的代码)。 |
| 用例 | 包含 Flash 访问例程的 Flash 库也是当前被擦/写操作寻址的库。 |
| 依赖 | -- |
| 支持材料 | 仅当擦/写例程位于要被擦除或重新编程的同一库中时才需要。 |
⌋()
###### 6.1.1.2.17 [SRS_Fls_12194] Flash 驱动应从 RAM 执行访问 Flash 硬件的代码
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动应从 RAM 执行访问 Flash 硬件的代码(内部擦/写例程)。此需求仅当 Flash 访问代码已加载到 RAM 时适用。<br><br>Flash 驱动必须确保此代码执行不被中断。因此该例程的运行时间应保持尽可能短。 |
| 理由 | 在对 Flash 库的擦/写操作期间,无法读取该库。 |
| 用例 | 包含 Flash 驱动代码的 Flash 库也是当前被擦/写操作寻址的库。 |
| 依赖 | [SRS_Fls_12193] 作业启动时将 Flash 访问代码加载到 RAM |
| 支持材料 | -- |
⌋()
###### 6.1.1.2.18 [SRS_Fls_13300] 当前作业完成或取消后,Flash 驱动应从 RAM 中移除访问 Flash 硬件的代码
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 当前擦或写作业完成或取消后,Flash 驱动应从 RAM 中移除访问 Flash 硬件的代码(内部擦/写例程)。<br><br>从 RAM 中移除 Flash 访问代码仅在 Flash 驱动于擦/写作业启动期间将该代码加载到 RAM 时才必要。如果 FAC 在初始化期间已加载到 RAM,Flash 驱动不应将代码从 RAM 中移除。<br><br>此特性应可静态配置开/关(预编译配置)。 |
| 理由 | 应从 RAM 中移除 Flash 访问代码,以避免 Flash 驱动操作之外可能有害的操作(Flash 擦/写)。 |
| 用例 | 用于擦除 Flash 内存的 Flash 访问代码在擦除作业开始时加载,擦除作业完成后卸载,以防止进一步(意外)的 Flash 内存擦除。 |
| 依赖 | [SRS_Fls_12193] 作业启动时将 Flash 访问代码加载到 RAM |
| 支持材料 | -- |
⌋()
#### 6.1.2 外部 Flash 驱动
##### 6.1.2.1 通用
###### 6.1.2.1.1 [SRS_Fls_12147] 外部和内部 Flash 驱动应适用相同的需求
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 对于外部 Flash 驱动,应适用与内部 Flash 驱动相同的需求。 |
| 理由 | 内部和外部 Flash 内存之间无功能差异。保持相同的功能范围。 |
| 用例 | STAR12 具有内部 Flash。其他微控制器仅使用外部 Flash。两种类型微控制器上应使用相同的 NVRAM Manager。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(BS_BRF_01080, BS_BRF_01008, BS_BRF_1800)
##### 6.1.2.2 配置
###### 6.1.2.2.1 [SRS_Fls_12182] 外部 Flash 驱动应允许静态配置硬件 Flash ID 和挂起时间
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 除基本配置参数外,外部 Flash 驱动应允许静态配置以下参数:<br>1. 预期的硬件 Flash ID<br>2. 最大读访问阻塞时间("挂起时间") |
| 理由 | 基本配置 |
| 用例 | 1: [SRS_Fls_12107] 检查 Flash 类型;2: [SRS_Fls_12184] 限制读访问阻塞时间 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(BS_BRF_01136)
##### 6.1.2.3 故障操作
###### 6.1.2.3.1 [SRS_Fls_12107] 外部 Flash 驱动应检查配置的 Flash 类型是否与硬件 Flash ID 匹配
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 外部 Flash 驱动应在其初始化函数内检查配置的 Flash 类型是否与硬件 Flash ID 匹配。检测到的不匹配应报告给 Error Manager。<br><br>仅当 Flash 硬件提供 Flash ID 时才提供此检查。 |
| 理由 | 避免使用错误的编程配置 |
| 用例 | -- |
| 依赖 | [SRS_Fls_12182] 外部 Flash 驱动静态配置 |
| 支持材料 | Requirements Specification CAS LLD – Configuration Tool: RS_LLD_CONFIG/7.11 |
⌋(BS_BRF_02232)
### 6.2 非功能性需求
#### 6.2.1 内部 Flash 驱动
##### 6.2.1.1 [SRS_Fls_12145] Flash 驱动的作业处理函数应仅处理 Flash 硬件可处理的数据量
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动的作业处理函数应仅处理 Flash 硬件在一步内可处理的数据(特别是写操作),或仅处理已定义的用户上限的数据量(特别是读操作)。 |
| 理由 | 最小化处理器负载,减少阻塞时间。 |
| 用例 | 例如,作业处理函数在一次调用中执行一个字节的写入和最多 8 字节的读取。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋()
#### 6.2.2 外部 Flash 驱动
##### 6.2.2.1 [SRS_Fls_12184] Flash 驱动应将读访问阻塞时间限制为配置的时间
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 驱动应将读访问阻塞时间限制为配置的时间(最大读访问阻塞时间)。 |
| 理由 | 避免阻塞整个系统的调度和中断。 |
| 用例 | Bosch EDC16:阻塞时间最大为 40µs。 |
| 依赖 | [SRS_Fls_12194], [SRS_Fls_12182] |
| 支持材料 | -- |
⌋()
##### 6.2.2.2 [SRS_Fls_12148] 外部 Flash 驱动应与内部 Flash 驱动具有语义相同的 API
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 外部 Flash 驱动应与内部 Flash 驱动具有语义相同的 API。 |
| 理由 | 简化内存抽象。保持内部和外部 Flash 内存的处理类似。 |
| 用例 | 一个 ECU 使用具有内部 Flash 的 STAR12。另一个 ECU 使用仅有外部 Flash 的控制器。两种微控制器上应使用相同的上层(NVRAM Manager、Flash/EEPROM 仿真)。 |
| 依赖 | 内部 Flash 驱动需求。 |
| 支持材料 | -- |
⌋(BS_BRF_01080)
##### 6.2.2.3 [SRS_Fls_12149] 外部 Flash 驱动的源代码应与底层微控制器无关
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 外部 Flash 驱动的源代码应与底层微控制器无关。 |
| 理由 | 在多个微控制器上重用外部 Flash 驱动 |
| 用例 | Flash 设备的同一外部 Flash 驱动可以无任何修改地在 NEC V850 和 MPC563 上使用。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(BS_BRF_01008, BS_BRF_1800)
---
## 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
---
## 翻译说明
- 本文档完整翻译自 AUTOSAR_SRS_FlashDriver v4.4.0(Document ID 194)。
- 保留所有需求 ID(SRS_Fls_xxxxx、BS_BRF_xxxxx、RS_BRF_xxxxx)。
- 保留 AUTOSAR 方框符 ⌈⌋。
- 模块缩写(Fls、ECU、NVRAM、EEPROM 等)保持英文。
Memory/AUTOSAR_SRS_FlashTest.md
+488
View File
@@ -0,0 +1,488 @@
# Flash 测试需求规范
> **文档标题**: Requirements on Flash Test
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 260
> **文档类型**: SRS (Software Requirements Specification)
---
## 文档标识
| 项目 | 内容 |
|------|------|
| Document Title | Requirements on Flash Test |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 260 |
| 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 | 移除 HIS 引用;将"default error"重命名为"development error";小幅更正/澄清/编辑性修订 |
| 2016-11-30 | 4.3.0 | 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 | 将需求与 BSW Feature 文档关联;根据 TPS_StandardizationTemplate 更新需求格式 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 初始版本发布 |
---
## 目录
1. [文档范围](#1-文档范围)
2. [使用的约定](#2-使用的约定)
3. [缩略语](#3-缩略语)
4. [功能概述](#4-功能概述)
5. [需求追溯](#5-需求追溯)
6. [需求规范](#6-需求规范)
- 6.1 [功能性需求](#61-功能性需求)
- 6.2 [非功能性需求](#62-非功能性需求)
7. [参考文献](#7-参考文献)
---
## 1 文档范围
本文档规定了 Flash Test 模块的需求。
---
## 2 使用的约定
- AUTOSAR 文档中需求的表示形式遵循 [TPS_STDT_00078] 中规定的表格格式。
- 需求中应使用以下特定语义(基于 IETF)。
本文档中的关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 需按下述方式解读:
- **SHALL**:规范的绝对要求
- **SHALL NOT**:规范的绝对禁止
- **MUST**:由于法律问题而构成的规范绝对要求
- **MUST NOT**:由于法律约束而构成的规范绝对禁止
- **SHOULD** / **RECOMMENDED**:特定情况下可能存在忽略的合理理由
- **SHOULD NOT** / **NOT RECOMMENDED**:特定情况下可能存在该行为可接受的合理理由
- **MAY** / **OPTIONAL**:真正可选
---
## 3 缩略语
| 缩略语 | 描述 |
|--------|------|
| ECU | Electric Control Unit(电子控制单元) |
| EOL | End Of Line(下线) |
| CRC | Cyclic Redundancy Check(循环冗余校验) |
| MCAL | Microcontroller Abstraction Layer(微控制器抽象层) |
| MCU | Microcontroller Unit(微控制器单元) |
| NMI | Non maskable interrupt(不可屏蔽中断) |
| OS | Operating System(操作系统) |
| DEM | Diagnostic Event Manager(诊断事件管理器) |
| SFR | Special Function Register(特殊功能寄存器) |
| RTE | Runtime environment(运行时环境) |
| WP | Work Package(工作包) |
| ECC | Error Correction Code(纠错码) |
| 缩写 | 描述 |
|------|------|
| STD | Standard(标准) |
| REQ | Requirement(需求) |
| UNINIT | Uninitialized(未初始化) |
| 术语 | 描述 |
|------|------|
| signature | 特定内存块内容的唯一计算结果 |
| Memory scrubbing | 自动顺序数据读取以触发检测/验证机制(典型如 ECC) |
| Invariable memory(不变内存) | 不变内存可以是程序 Flash、程序 SRAM、锁定缓存和 ROM |
| Background test(后台测试) | 由调度程序周期性调用且可中断,测试在多个调度任务上分散执行 |
| Foreground test(前台测试) | 通过用户调用启动 |
| Test interval(测试间隔) | 后台模式下完整 Flash 测试的间隔 |
---
## 4 功能概述
本软件模块提供测试不变内存的算法。不变内存可以是数据/程序 Flash、程序 SRAM、锁定缓存,要么嵌入微控制器中,要么通过内存映射与微控制器相连。为简化,该软件模块称为 Flash Test Driver。
测试服务可在 MCU 初始化后随时执行,由 Flash Test Driver 的用户选择合适的测试算法和正确的执行位置,以满足系统的安全需求。测试服务本身依赖于系统的存储概念。因此,不同测试算法的可用性是可配置的。
Flash Test 驱动旨在集成于整体安全概念中,本身不会提供所需的诊断覆盖率。
---
## 5 需求追溯
| 需求 | 描述 | 满足者 |
|------|------|--------|
| RS_BRF_00129 | AUTOSAR 应支持数据损坏检测与保护 | SRS_FlsTst_14200~14209、14211~14217、14219、14221~14225 |
| RS_BRF_01024 | AUTOSAR 应为公共符号提供命名规则 | SRS_FlsTst_14225 |
| RS_BRF_02168 | AUTOSAR 诊断应提供异常运行条件的集中分类和处理 | SRS_FlsTst_14223 |
| RS_BRF_02224 | AUTOSAR 应支持运行时硬件测试 | SRS_FlsTst_14200, 14201, 14208, 14209, 14211~14217, 14219, 14221~14225 |
---
## 6 需求规范
### 6.1 功能性需求
Flash Test 模块使用 Diagnostic Event Manager (DEM) 进行错误报告。错误通过 DEM API(BSW,`Dem_SetEventStatus()`)报告。开发错误报告给 Default Error Tracer (DET)。
#### 6.1.1 配置
本章列出对模块可配置性的需求。
##### 6.1.1.1 [SRS_FlsTst_14222] 内存块测试应被配置
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 配置待测试的内存块。块大小应可配置。应可配置多个 Flash 块区域(例如通过配置其起始与结束地址)。此外,如适用,应为每个内存块配置已存储签名或校验和位置的链接。 |
| 理由 | 定义待测试的内存块。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_02224, RS_BRF_00129)
##### 6.1.1.2 [SRS_FlsTst_14200] Flash 测试服务应被配置
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应可配置每个内存块可使用的测试算法。 |
| 理由 | 使 Flash 测试服务适应系统存储概念并优化驱动代码 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | AUTOSAR_SWS_RAM_Test.pdf (AUTOSAR Release 2.1) |
⌋(RS_BRF_02224, RS_BRF_00129)
##### 6.1.1.3 [SRS_FlsTst_14201] 应支持后构建配置
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应支持后构建配置 |
| 理由 | 1. 用于目标代码交付;2. Flash 测试配置依赖于地址,可能随 SW 版本而变化 |
| 用例 | 为不同 ECU 变体加载配置 |
| 依赖 | -- |
| 支持材料 | AUTOSAR_SWS_RAM_Test.pdf (AUTOSAR Release 2.1) |
⌋(RS_BRF_02224, RS_BRF_00129)
#### 6.1.2 初始化
未收集特殊初始化需求。
#### 6.1.3 正常运行
本章列出模块"正常"功能的需求。
##### 6.1.3.1 [SRS_FlsTst_14202] 应使用 ECC 检查数据完整性
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 主动使用 ECC 测试数据完整性。应提供算法,在读取字时检查数据和扩展到内存字的冗余位的正确性。如果不变内存支持此机制,此算法可适用。测试在出现任何故障时应报告 DEM 错误。 |
| 理由 | 检测 16 位字内的单位故障、双位故障、三位故障 |
| 用例 | SW ECC 或 HW ECC。可用于"内存清洗"。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_00129)
##### 6.1.3.2 [SRS_FlsTst_14203] 应使用校验和检查数据完整性
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 使用校验和检查数据完整性。应提供算法,重新计算内存块的校验和,并与存储在不变内存中定义地址处的校验和进行比较。如果 Flash 内存包含校验和,此算法可适用。已存储校验和位置的链接应可配置。测试在校验和不匹配时应报告 DEM 错误。 |
| 理由 | 检测位故障 |
| 用例 | -- |
| 依赖 | SRS_FlsTst_14222 |
| 支持材料 | -- |
⌋(RS_BRF_00129)
##### 6.1.3.3 [SRS_FlsTst_14204] 应使用 CRC 签名(8 位长度)检查数据完整性
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应提供算法,使用 CRC 算法重新计算内存块的签名,并与存储在不变内存中定义地址处的签名进行比较。CRC 校验和长度应为 8 位字。如果 Flash 内存包含块签名,此测试可适用。已存储签名位置的链接应可配置。测试在签名不匹配时应报告 DEM 错误。 |
| 理由 | 检测字内的位故障以及 99.6% 的所有可能位故障 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_00129)
##### 6.1.3.4 [SRS_FlsTst_14205] 应使用 CRC 签名(16 位长度)检查数据完整性
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应提供算法,使用 CRC 算法重新计算内存块的签名,并与存储在不变内存中定义地址处的签名进行比较。CRC 校验和长度应为 16 位字。 |
| 理由 | 检测字内的位故障以及 99.998% 的所有可能位故障 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_00129)
##### 6.1.3.5 [SRS_FlsTst_14206] 应使用 CRC 签名(32 位长度)检查数据完整性
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应提供算法,使用 CRC 算法重新计算内存块的签名,并与存储在不变内存中定义地址处的签名进行比较。CRC 校验和长度应为 32 位字。 |
| 理由 | 检测字内的位故障以及 99.99999995% 的所有可能位故障。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_00129)
##### 6.1.3.6 [SRS_FlsTst_14207] 应通过比较重复内存块检查数据完整性
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应提供测试以比较两个相同的内存块。测试用例在内存重复时适用。测试在不匹配时应报告 DEM 错误。 |
| 理由 | 根据块复制技术检测所有位故障 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_00129)
##### 6.1.3.7 [SRS_FlsTst_14208] 后台 Flash 测试应可中断
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Changed |
| 描述 | -- |
| 理由 | 测试旨在用于调度的后台任务。因此不应阻塞其他操作。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | AUTOSAR_SWS_RAM_Test.pdf (AUTOSAR Release 2.1) |
⌋(RS_BRF_02224, RS_BRF_00129)
##### 6.1.3.8 [SRS_FlsTst_14209] 待测内存应被划分为更小的部分
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 待测内存应被划分为更小的单独部分,可根据系统需要进行调度。 |
| 理由 | 与并发任务共享 CPU 资源 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | AUTOSAR_SWS_RAM_Test.pdf (AUTOSAR Release 2.1) |
⌋(RS_BRF_02224, RS_BRF_00129)
##### 6.1.3.9 [SRS_FlsTst_14211] Flash 测试执行状态应可用
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | Flash 测试执行的当前状态应通过 get status 接口可用。此功能应为可选。 |
| 理由 | 能够监视当前运行的测试以进行测试流控制。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | AUTOSAR_SWS_RAM_Test.pdf (AUTOSAR Release 2.1) |
⌋(RS_BRF_02224, RS_BRF_00129)
##### 6.1.3.10 [SRS_FlsTst_14212] Flash 测试执行完成应通过通知机制提供
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 关于测试已完成的信息应通过通知机制提供给用户。此功能应为可选。 |
| 理由 | 能够指示当前运行测试的完成以进行测试流控制。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | AUTOSAR_SWS_RAM_Test.pdf (AUTOSAR Release 2.1) |
⌋(RS_BRF_02224, RS_BRF_00129)
##### 6.1.3.11 [SRS_FlsTst_14213] 应提供已完成测试的签名/校验和计算
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 已完成测试的签名/校验和计算应提供给用户。此功能应为可选。 |
| 理由 | 已完成测试的通过/失败判定可在本软件模块之外做出。 |
| 用例 | 通过或失败判定可由外部安全单元完成 |
| 依赖 | -- |
| 支持材料 | AUTOSAR_SWS_RAM_Test.pdf (AUTOSAR Release 2.1) |
⌋(RS_BRF_02224, RS_BRF_00129)
##### 6.1.3.12 [SRS_FlsTst_14214] 应提供 Flash 测试执行结果服务
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应在 SW 请求时提供关于已完成测试的信息。此功能应为可选。 |
| 理由 | 能够监视已完成测试以用于诊断目的。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | AUTOSAR_SWS_RAM_Test.pdf (AUTOSAR Release 2.1) |
⌋(RS_BRF_02224, RS_BRF_00129)
##### 6.1.3.13 [SRS_FlsTst_14215] 应可能暂停 Flash 测试执行
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应提供服务以暂停正在运行的 Flash 测试。暂停将在下一个原子边界停止测试执行并保存中间状态。此功能应为可选。 |
| 理由 | 在更高优先级任务出现时暂停后台 Flash 测试任务。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | AUTOSAR_SWS_RAM_Test.pdf (AUTOSAR Release 2.1) |
⌋(RS_BRF_02224, RS_BRF_00129)
##### 6.1.3.14 [SRS_FlsTst_14216] 暂停的 Flash 测试执行应可恢复
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应提供服务以恢复已暂停的 Flash 测试。此功能应为可选。 |
| 理由 | 完成已暂停的 Flash 测试。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | AUTOSAR_SWS_RAM_Test.pdf (AUTOSAR Release 2.1) |
⌋(RS_BRF_02224, RS_BRF_00129)
##### 6.1.3.15 [SRS_FlsTst_14217] 需要时应停止 Flash 测试执行
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应提供服务以停止 Flash 测试。测试应被取消,重新启动测试应从头开始。 |
| 理由 | -- |
| 用例 | 在出现 DEM 错误时,用户可取消正在运行的 Flash 测试执行 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_02224, RS_BRF_00129)
##### 6.1.3.16 [SRS_FlsTst_14219] 应提供前台 Flash 测试
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应提供服务以前台模式测试内存块。此功能应为可选。 |
| 理由 | -- |
| 用例 | 启动阶段测试完整程序 Flash;关键操作前测试特殊内存块 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_02224, RS_BRF_00129)
##### 6.1.3.17 [SRS_FlsTst_14223] 应报告 Flash 测试错误细节
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应提供服务以报告从 ECC 测试中检测到的特定错误数据。<br><br>该服务应为可选,适用于以下情况:<br>- 硬件配备了不变内存的 ECC<br>- 硬件能够报告硬件特定错误细节<br>- 调用方需要此数据<br><br>调用方负责解释此服务提供的数据。 |
| 理由 | 这些详细错误数据用于诊断目的。 |
| 用例 | ECU 启动期间应测试不变内存的 ECC 故障。出现故障时,此功能应用于收集硬件特定的故障数据,如 ECC 故障的故障地址 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_02224, RS_BRF_00129, RS_BRF_02168)
##### 6.1.3.18 [SRS_FlsTst_14224] 应测试 ECC 电路
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应提供服务以测试 ECC 电路并报告测试结果。<br><br>该服务应为可选,适用于以下情况:<br>- 硬件配备了不变内存的 ECC<br>- 硬件提供测试 ECC 电路的机制<br>- 调用方需要此测试 |
| 理由 | 在安全相关应用中,可能有必要确定硬件内存测试机制功能正常。这可以通过验证可用电路(ECC)无错误运行来实现。 |
| 用例 | ECU 启动期间验证 ECC 硬件逻辑。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_02224, RS_BRF_00129)
##### 6.1.3.19 [SRS_FlsTst_14225] 每个 Flash 测试间隔应具有一个标识符
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 每个 Flash 测试间隔应具有一个标识符,该标识符应在后台模式下每次启动有效测试间隔时递增。Flash 测试间隔的值应提供给上层。标识符的结束值应可配置。 |
| 理由 | 将测试结果或测试签名分配给一个测试间隔,以便上层监视 ECU 测试流。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_02224, RS_BRF_00129, RS_BRF_01024)
#### 6.1.4 关机操作
未收集关机操作的专用需求。
#### 6.1.5 故障操作
本软件模块未收集故障/恢复操作的专用需求。
### 6.2 非功能性需求
未收集专用非功能性需求。
#### 6.2.1 时序需求
未收集专用时序需求。
#### 6.2.2 资源使用
##### 6.2.2.1 [SRS_FlsTst_14221] 测试期间被测试内存内容不应有效
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 测试基于内容,要求测试期间内容不变。这必须由调用方确保。 |
| 理由 | 被测内存块的内容在测试期间不应有效 |
| 用例 | 运行时测试数据 Flash |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_02224, RS_BRF_00129)
---
## 7 参考文献
### AUTOSAR 交付物
- [DOC_LAYERED_ARCH] Layered Software Architecture, AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
- [AUTOSAR_GLOSSARY] Glossary, AUTOSAR_TR_Glossary.pdf
- [SRS_BSW_GENERAL] General Requirements on Basic Software Modules, AUTOSAR_SRS_BSWGeneral.pdf
- [SRS_BSW_SPAL] General Requirements on SPAL, AUTOSAR_SRS_SPALGeneral.pdf
- [SWS_BSW] Specification of Diagnostic Event Manager, AUTOSAR_SWS_DiagnosticEventManager.pdf
- [SWS_BSW] Specification of Default Error Tracer, AUTOSAR_SWS_DefaultErrorTracer.pdf
- [SWS_BSW_MCAL] Specification of RAM Test, AUTOSAR_SWS_RAMTest.pdf
- [SWS_BSW] Specification of ECU state manager, AUTOSAR_SWS_ECUStateManager.pdf
- [TPS_STDT_0078] Software Standardization Template, AUTOSAR_TPS_StandardizationTemplate.pdf
---
## 翻译说明
- 本文档完整翻译自 AUTOSAR_SRS_FlashTest v4.4.0(Document ID 260)。
- 保留所有需求 ID(SRS_FlsTst_xxxxx、RS_BRF_xxxxx)。
- 保留 AUTOSAR 方框符 ⌈⌋。
- 模块缩写(FlsTst、Fls、ECC、CRC、DEM、DET 等)保持英文。
Memory/AUTOSAR_SRS_MemoryHWAbstractionLayer.md
+556
View File
@@ -0,0 +1,556 @@
# 内存硬件抽象层需求规范
> **文档标题**: 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 等)保持英文。
Memory/AUTOSAR_SRS_MemoryServices.md
+807
View File
@@ -0,0 +1,807 @@
# 内存服务需求规范
> **文档标题**: Requirements on Memory Services
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 007
> **文档类型**: SRS (Software Requirements Specification)
---
## 文档标识
| 项目 | 内容 |
|------|------|
| Document Title | Requirements on Memory Services |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 007 |
| 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-09-30 | 3.1.5 | AUTOSAR Administration | 增加 NVM 安全机制;增加调试和诊断支持;增加块共享;法律免责声明修订 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 移除 CRC 库相关需求;文档元信息扩充;小幅排版调整 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | 移除关于符合性和强制需求的声明;法律免责声明修订;"用户须知"修订;增加"版本信息" |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 块管理类型需求变更;新增需求(RAM 块类型、错误检测、减少写负载、配置等);移除"写访问分散"和"不完整写入检测"需求 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 初始发布 |
---
## 目录
1. [文档范围](#1-文档范围)
2. [如何阅读本文档](#2-如何阅读本文档)
3. [缩略语](#3-缩略语)
4. [功能概述](#4-功能概述)
5. [需求追溯](#5-需求追溯)
6. [需求规范](#6-需求规范)
- 6.1 [功能性需求](#61-功能性需求)
- 6.2 [非功能性需求(质量)](#62-非功能性需求质量)
7. [参考文献](#7-参考文献)
---
## 1 文档范围
本文档规定了以下软件层中基础软件模块的需求:
- 服务层(Service Layer)
这些模块属于以下类型:
- NVRAM 管理
- 接口
模块的选择源自基础软件模块列表和 AUTOSAR 分层软件架构。涉及以下模块:
- NVRAM Manager
需求按以下方式组织:
- 基础软件模块的通用需求(其他文档)
- 适用于 NVRAM 管理所有模块的通用需求
- 模块特定需求
**约束**
基础软件模块需求规范的首要范围是非安全相关系统。因此安全需求被分配为中等优先级。
---
## 2 如何阅读本文档
每条需求都有一个以"BSW"为前缀的唯一标识符。
### 2.1 使用的约定
关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 按 IETF 风格解读。AUTOSAR 文档中需求的表示形式遵循 [TPS_STDT_00078] 中规定的表格格式。
### 2.2 需求结构
**功能性需求**:配置、初始化、正常运行、关机运行、故障运行、……
**非功能性需求**:时序需求、资源使用、易用性、为其他工作包提供的输出、……
---
## 3 缩略语
| 缩略语 | 描述 |
|--------|------|
| Basic Storage Object(基础存储对象) | NVRAM 块的最小实体。多个"基础存储对象"可用于构建一个 NVRAM 块。"基础存储对象"可驻留在不同的存储位置(RAM/ROM/NV 存储器)。 |
| NVRAM Block(NVRAM 块) | 管理并存储 NV 数据块所需的整个结构。 |
| NV data(NV 数据) | 要存储于非易失存储器的数据。 |
| Block Management Type(块管理类型) | NVRAM 块的类型,取决于(可配置的)由强制/可选基础存储对象不同块组成 NVRAM 块的个性化构成及对其的后续处理。 |
| NV Block Header(NV 块头部) | 启用"静态块 ID"机制时 NV 块包含的附加信息。 |
| RAM Block(RAM 块) | 基础存储对象。表示 NVRAM 块中驻留在 RAM 的部分。参见 [SRS_LIBS_08534] |
| ROM Block(ROM 块) | 基础存储对象。表示 NVRAM 块中驻留在 ROM 的部分。"ROM 块"是 NVRAM 块的可选部分。 |
| NV Block(NV 块) | 基础存储对象。表示 NVRAM 块中驻留在 NV 存储器的部分。"NV 块"是 NVRAM 块的强制部分。 |
| Administrative Block(管理块) | 驻留在 RAM 中的基础存储对象。包含管理 NVRAM 块、执行其处理及交付状态信息所需的任何 RAM 数据。"管理块"是 NVRAM 块的强制部分。 |
| MemHwA | Memory Hardware Abstraction,见 [AUTOSAR_SRS_MEMHW] |
---
## 4 功能概述
非易失 RAM 管理器(NVRAM Manager)管理所有类型非易失存储器中的数据存储。
NVRAM 管理器本身应是硬件无关的,所有直接访问硬件的功能(如内部或外部 EEPROM、内部或外部 Flash 中的仿真 EEPROM 等)封装在基础 SW 的较低层中。NVRAM 管理器处理对非易失数据的并发访问,并为单个数据元素提供如校验和保护等可靠性机制。为了在汽车系统所有领域都可用,NVRAM 管理器需要具有高度可扩展性(如可定义请求队列的数量和大小、支持不同的块管理类型、EEPROM 仿真等)。
---
## 5 需求追溯
| 需求 | 描述 | 满足者 |
|------|------|--------|
| RS_BRF_00129 | AUTOSAR 应支持数据损坏检测与保护 | SRS_Mem_00030, 00129, 08001, 08010, 08545, 08546, 08547, 08550, 08552, 08553, 08555, 08556 |
| RS_BRF_01048 | AUTOSAR 模块设计应支持多任务环境下模块协同工作 | SRS_Mem_00034, 08542, 08558 |
| RS_BRF_01064 | AUTOSAR BSW 应提供回调函数以访问上层模块 | SRS_Mem_00125 |
| RS_BRF_01076 | AUTOSAR 基础软件应尽可能进行模块本地错误恢复 | SRS_Mem_00038 |
| RS_BRF_01096 | AUTOSAR 应支持 ECU 的启动和关机 | SRS_Mem_00137, 08540 |
| RS_BRF_01416 | AUTOSAR 服务应支持非易失存储器数据的标准化处理 | SRS_Mem_00013, 00016, 00017, 00136, 00138, 08544, 08554 |
| RS_BRF_01800 | AUTOSAR 非易失存储器功能应划分为硬件相关层和硬件无关层 | SRS_Mem_00011 |
| RS_BRF_01808 | AUTOSAR 非易失存储器处理应支持不同种类的存储器硬件 | SRS_Mem_08000 |
| RS_BRF_01812 | AUTOSAR 非易失存储器功能应支持作业的优先级化和异步执行 | SRS_Mem_00034, 08543, 08558 |
| RS_BRF_01816 | AUTOSAR 非易失存储器功能应基于逻辑内存块组织持久数据 | SRS_Mem_00041, 08001, 08009, 08528, 08529, 08531, 08533, 08534, 08538, 08543, 08549, 08560 |
| RS_BRF_01824 | AUTOSAR 非易失存储器功能应提供非易失存储器到 RAM 的映射 | SRS_Mem_00027, 08014, 08533, 08538, 08549 |
| RS_BRF_01832 | AUTOSAR 非易失存储器应独立于物理地址处理逻辑内存块 | SRS_Mem_08007, 08531 |
| RS_BRF_01840 | AUTOSAR 非易失存储器功能应保护内存块的完整性 | SRS_Mem_00018, 00030, 00127, 00129, 00135, 08010, 08011, 08015, 08535, 08541, 08546, 08547, 08548, 08552, 08553, 08556 |
| RS_BRF_01848 | AUTOSAR 非易失存储器功能应提供增强硬件可靠性的机制 | SRS_Mem_00018, 08529, 08531, 08548, 08551, 08554 |
---
## 6 需求规范
### 6.1 功能性需求
#### 6.1.1 配置
##### 6.1.1.1 [SRS_Mem_00041] 每个应用应能在配置时声明内存需求
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 通过使用配置技术,每个应用应能在配置时声明内存需求。此信息应可用于分配内存区域并生成适当的接口。错误的内存分配和需求冲突(没有足够内存可用)应在配置时被检测到。 |
| 理由 | 实现更高的可靠性、互操作性 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01816)
##### 6.1.1.2 [SRS_Mem_08534] NVRAM 管理器应支持两类 RAM 数据块
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应支持两类 RAM 数据块。这些 RAM 数据块对于 NVRAM 管理器和 SW 组件之间的数据交换是强制的。它们必须由 SW 组件或 BSW 模块提供。对特定 NVRAM 块的分配可以是:<br><br>- **永久**:即 RAM 数据块在配置时分配给恰好一个 NVRAM 块<br>- **临时**:即 RAM 数据块可在运行时分配给任何 NVRAM 块 |
| 理由 | 减少 RAM 消耗。 |
| 用例 | 1) 某些 NVRAM 块不经常使用,其数据无需永久驻留在 RAM 中。例如,应用希望对其所有互斥使用的 NVRAM 块使用一个共享 RAM 块。<br>2) 诊断服务希望从 NV 中读取某些应用使用的数据,而不危及应用的 RAM 块。它使用一个 RAM 块(必须足够大)来读取任何请求的 NV 数据块。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01816)
##### 6.1.1.3 [SRS_Mem_08528] NVRAM 管理器应允许配置原生块管理类型
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应允许配置原生块管理类型。<br><br>- 原生 NVRAM 块应提供数据的基本存储和 ROM 可配置 ROM 默认值。 |
| 理由 | 基本块类型 |
| 用例 | 无特殊要求的常规 NVRAM 数据。 |
| 依赖 | [SRS_LIBS_08534] RAM 数据块类别 |
| 支持材料 | -- |
⌋(RS_BRF_01816)
##### 6.1.1.4 [SRS_Mem_08529] NVRAM 管理器应允许配置冗余块管理类型
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应允许配置冗余块管理类型。冗余 NVRAM 块应对应用透明,并应在发生不一致时(如不完整写入)能提供数据。<br><br>冗余 NVRAM 块应可配置以包含默认值。<br><br>注:冗余不一定意味着双重(或多重)存储。 |
| 理由 | 安全性、增强数据可用性、完整性 |
| 用例 | 用于保存安全相关数据(如防盗器数据) |
| 依赖 | [SRS_Mem_00038] 可处理的错误不应影响应用; [SRS_Mem_00129] 自动数据修复; [SRS_LIBS_08534] RAM 数据块类别 |
| 支持材料 | -- |
⌋(RS_BRF_01816, RS_BRF_01848)
##### 6.1.1.5 [SRS_Mem_08531] NVRAM 管理器应允许配置数据集块管理类型
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应允许配置数据集块管理类型。此类 NVRAM 块应在 NV 中提供可配置数量的可选元素。<br>- 数据集 NVRAM 块应可配置以包含默认值。 |
| 理由 | 使运行时选择 ROM/NVRAM 中不同数据集成为可能。 |
| 用例 | 一个 ECU 在一辆汽车的多个型号/国家变体中使用。根据车辆变体,选择 NVRAM 或 ROM 中对应的数据集。 |
| 依赖 | [SRS_Mem_08007] 数据集选择; [SRS_LIBS_08534] RAM 数据块类别 |
| 支持材料 | -- |
⌋(RS_BRF_01816, RS_BRF_01848, RS_BRF_01832)
##### 6.1.1.6 [SRS_Mem_08543] 每个 NVRAM 块的优先级应可在不同级别静态配置
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 每个 NVRAM 块的优先级应可在不同级别静态(预编译时)配置。<br><br>其中一个级别应为"立即(immediate)",对于这些块应适用 [SRS_Mem_08542]。 |
| 理由 | 灵活性 |
| 用例 | 崩溃数据写入和常规数据写入 |
| 依赖 | [SRS_Mem_08542] 作业顺序优先级化 |
| 支持材料 | -- |
⌋(RS_BRF_01816, RS_BRF_01812)
##### 6.1.1.7 [SRS_Mem_08009] NVRAM 管理器应允许为每个 NVRAM 块静态配置默认写保护(开/关)
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应允许为每个 NVRAM 块静态配置默认写保护(开/关)。 |
| 理由 | 某些数据是只读的 |
| 用例 | 写保护关:由应用本身生成的数据(如自适应数据、错误存储器);写保护开:外部赋予 ECU 的数据(如 EOL 数据、变体编码、参数) |
| 依赖 | [SRS_Mem_00127] 写保护/解除保护功能 |
| 支持材料 | -- |
⌋(RS_BRF_01816)
##### 6.1.1.8 [SRS_Mem_00135] NVRAM 管理器应有唯一的配置标识符
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应有一个配置标识符,它是非易失存储器配置的唯一属性。ID 可以静态分配给配置,或可以从配置属性计算得出。如果块配置改变(即添加或移除块,或更改其大小或类型),ID 必须改变。ID 应单独存储并应用于确定 NVRAM 内容的有效性。该机制在生产期间应是健壮的(如断电)。 |
| 理由 | NVRAM 数据配置可能在不同应用软件版本之间变化。必须有一种方式来知道 NVRAM 的内容是否与应用期望的配置匹配。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01840)
##### 6.1.1.9 [SRS_Mem_08549] NVRAM 管理器应提供软件更新后自动初始化 RAM 数据块的功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供功能,在软件更新后用 ROM 默认值自动初始化 RAM 数据块。此功能应可按 NVRAM 块配置。整个功能应可静态配置。 |
| 理由 | 灵活性。因此 ECU 重编程期间无需更新 NV 存储器。 |
| 用例 | ECU 重编程后(配置 ID 不匹配),NVRAM 块用(新)ROM 默认值初始化,但防盗器数据除外,不应被更新。 |
| 依赖 | [SRS_Mem_00135] NVRAM 配置 ID |
| 支持材料 | -- |
⌋(RS_BRF_01816, RS_BRF_01824)
##### 6.1.1.10 [SRS_Mem_00125] 每个块应可配置通知
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 每个块应可配置通知(在读/写作业完成时启动)。 |
| 理由 | 灵活性,与应用软件集成 |
⌋(RS_BRF_01064)
##### 6.1.1.11 [SRS_Mem_08000] NVRAM 管理器应能访问多个非易失存储器设备
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应能访问多个非易失存储器设备。非易失存储器设备可以是不同类型。 |
| 理由 | 灵活性,与应用软件集成 |
| 用例 | 一个 ECU 中的多个非易失存储器,如外部 EEPROM 和内部 Flash 中的 EEPROM 仿真 |
| 依赖 | [SRS_Mem_00011] (存储器)硬件独立性 |
| 支持材料 | -- |
⌋(RS_BRF_01808)
##### 6.1.1.12 [SRS_Mem_08001] NVRAM 管理器应为每个块提供可配置的一致性检查
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应为每个块提供可配置的一致性检查。 |
| 理由 | 一致性检查可能并非用于所有块 |
| 用例 | 读取或写入的数据可通过校验和重新计算和比较立即检查。 |
| 依赖 | [SRS_Mem_00030] 数据一致性/完整性检查;[BSW023] 不完整写操作的检测 |
| 支持材料 | -- |
⌋(RS_BRF_01816, RS_BRF_00129)
##### 6.1.1.13 [SRS_Mem_08551] 错误情况下最大重试次数应可单独配置
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 对于 NVRAM 管理器的读和写操作,错误情况下的最大重试次数应可单独配置。 |
| 理由 | 从临时错误情况中恢复 |
| 用例 | 错误条件下的数据读写。 |
| 依赖 | [SRS_Mem_08554] 读和写操作的重试 |
| 支持材料 | -- |
⌋(RS_BRF_01848)
##### 6.1.1.14 [SRS_Mem_08552] NVRAM 管理器应提供唯一块标识符的可配置验证
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供在读取 NVRAM 块时唯一块标识符的可配置验证。 |
| 理由 | 必要时防止块错误寻址 |
| 用例 | 必要时可检测硬件寻址错误 |
| 依赖 | [SRS_Mem_08555] 唯一块标识符的验证 |
| 支持材料 | -- |
⌋(RS_BRF_01840, RS_BRF_00129)
##### 6.1.1.15 [SRS_Mem_08553] NVRAM 管理器应提供可配置的数据写验证
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应通过重新读取先前写入的数据并比较,提供可配置的数据写验证。写验证应可按 NVRAM 块配置。 |
| 理由 | 必要时验证正确存储的数据 |
| 用例 | 必要时可检测硬件写错误 |
| 依赖 | [SRS_Mem_08556] 数据写验证 |
| 支持材料 | -- |
⌋(RS_BRF_01840, RS_BRF_00129)
##### 6.1.1.16 [SRS_Mem_08538] 在 NVRAM 管理器启动期间自动加载的块应可静态配置
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 在 NVRAM 管理器启动期间自动加载的块应可静态配置。 |
| 理由 | 允许灵活性 – 启动期间加载内容 |
| 用例 | 仅加载在严格时序约束内通过 CAN 启动通信所需的块。 |
| 支持材料 | 仅适用于配置为永久 RAM 块的 NVRAM 块 SRS_LIBS_08534 |
⌋(RS_BRF_01816, RS_BRF_01824)
##### 6.1.1.17 [SRS_Mem_08546] 应可保护永久 RAM 数据块免于因复位造成的数据丢失
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 对于每个具有永久 RAM 数据块的 NVRAM 块,应有可配置选项以强制执行增加 RAM 数据完整性的机制(发生复位时)。 |
| 理由 | 由于电压下降引起的复位,RAM 内容可能仍然有效。这不能被所有平台检测(或保证)。如果可以在启动时交付最新数据(来自 RAM),则会增加健壮性。 |
| 用例 | 当前移动的天窗控制在复位发生后不能用过时的位置数据驱动(参见 [SRS_Mem_08011]),每次电压下降都丢失位置也是不可接受的。 |
| 依赖 | [SRS_Mem_08545] RAM 数据验证和完整性信息更新 |
| 支持材料 | -- |
⌋(RS_BRF_01840, RS_BRF_00129)
##### 6.1.1.18 [SRS_Mem_08560] 每个 NVRAM 块应可配置为共享访问
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 每个 NVRAM 块应可配置为共享访问。 |
| 理由 | 这是按块进行的,以保持内存消耗低。 |
⌋(RS_BRF_01816)
#### 6.1.2 初始化
##### 6.1.2.1 [SRS_Mem_08533] NVRAM 管理器应提供检查和加载配置为具有永久 RAM 数据块的 NVRAM 块到 RAM 的服务
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供服务,检查并加载配置为具有永久 RAM 数据块的 NVRAM 块到 RAM。<br><br>此服务必须由 ECU 状态管理器在启动期间应用运行之前调用一次。 |
| 理由 | 应用在 ECU 启动后需要带有效数据的 RAM 块。 |
| 用例 | ECU 启动:为应用提供 NV 数据。 |
| 依赖 | [SRS_LIBS_08534] RAM 数据块类别; [SRS_Mem_08538] 启动期间加载的 NVRAM 块的静态配置 |
| 支持材料 | -- |
⌋(RS_BRF_01816, RS_BRF_01824)
#### 6.1.3 正常运行
**注**:只有 NVRAM 管理器应访问非易失存储器。所有其他软件应专门使用 NVRAM 管理器访问非易失存储器中的数据。但这不是对内存服务的需求,而是对使用的需求。因此,先前的需求 [BSW176]("仅通过 NVRAM 管理器访问非易失存储器")已被移除。
##### 6.1.3.1 [SRS_Mem_00027] NVRAM 管理器应提供隐式访问 NVRAM 和共享内存(RAM)中块的方式
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器仅提供隐式访问 NVRAM 和共享内存(RAM)中块的方式。这意味着 NVRAM 管理器将一个或多个块从 NV 存储器复制到 RAM 块,反之亦然。<br><br>RAM 块内变量的显式读写访问必须由应用提供(访问宏……)。 |
| 理由 | NVRAM 管理器的基本功能 |
| 用例 | 参数访问 |
⌋(RS_BRF_01824)
##### 6.1.3.2 [SRS_Mem_08014] NVRAM 管理器应允许在全局 RAM 区域中非连续地分配 RAM 块
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | RAM 块分配可在全局 RAM 区域中定义为非连续。 |
| 用例 | 每个 RAM 块可在全局 RAM 区域中无地址约束地分配 |
⌋(RS_BRF_01824)
##### 6.1.3.3 [SRS_Mem_00013] NVRAM 管理器应提供处理多个并发读/写请求的机制
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供处理多个并发读/写命令的机制,如排队。<br><br>实现需求:如果使用排队,仅缓冲读/写命令,而非要写入的数据! |
| 理由 | NVRAM 管理器处理整个 SW 系统中对 NVRAM 的所有访问。因此并发访问极有可能发生。由于资源限制,NVRAM 管理器必须以串行方式处理这些并行访问。 |
⌋(RS_BRF_01416)
##### 6.1.3.4 [SRS_Mem_00016] NVRAM 管理器应提供从非易失存储器读出与 NVRAM 块关联数据的功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供从非易失存储器读出与 NVRAM 块关联数据的功能。NVRAM 块由唯一标识符引用。NVRAM 数据被复制到相应的 RAM 块。<br><br>此服务的可用性应可配置。 |
| 理由 | NVRAM 管理器的基本功能 |
| 用例 | 从 NV 读取应用数据。 |
⌋(RS_BRF_01416)
##### 6.1.3.5 [SRS_Mem_00017] NVRAM 管理器应提供在非易失存储器中存储与 NVRAM 块关联数据的功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供在非易失存储器中存储与 NVRAM 块关联数据的功能。NVRAM 块由唯一标识符引用。<br><br>数据从 RAM 块复制到相应的 NV 块。此服务的可用性应可配置。 |
| 理由 | NVRAM 管理器的基本功能 |
| 用例 | 在 ECU 电源关闭前非易失存储数据 |
⌋(RS_BRF_01416)
##### 6.1.3.6 [SRS_Mem_08554] 如果 NVRAM 块的读和写操作未成功,NVRAM 管理器应重试最多可配置的次数
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 如果 NVRAM 块的读和写操作未成功,NVRAM 管理器应重试最多可配置的次数。 |
| 理由 | 从临时错误情况中恢复 |
| 用例 | 电磁脉冲已改变刚读取的数据,因此校验和检查失败。再次读取数据可从此错误情况中恢复。 |
| 依赖 | [SRS_Mem_08551] 最大读写重试次数配置 |
⌋(RS_BRF_01416, RS_BRF_01848)
##### 6.1.3.7 [SRS_Mem_08541] NVRAM 管理器应保证已接受的写请求将被处理
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应保证已接受的写请求将被处理。 |
| 理由 | 发出写请求的应用期望数据被写入。 |
| 用例 | 1) 源自应用的排队写作业不应受关机过程或其取消影响。2) 在小幅崩溃时 ECU 保持可操作,NVRAM 管理器应表现得像没有此崩溃一样。因此,写相应崩溃数据的请求不应中止任何已接受的写作业。 |
| 依赖 | [SRS_Mem_00017], [SRS_Mem_08535], [SRS_Mem_08540], [SRS_Mem_08542] |
⌋(RS_BRF_01840)
##### 6.1.3.8 [SRS_Mem_00018] NVRAM 管理器应提供从 ROM 默认值恢复 NVRAM 块关联数据的功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供从 ROM 默认值恢复 NVRAM 块关联数据的功能。此服务的可用性应可配置。 |
| 用例 | 收音机出厂设置 |
⌋(RS_BRF_01840, RS_BRF_01848)
##### 6.1.3.9 [SRS_Mem_08548] NVRAM 管理器应从应用请求默认数据
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 如果配置时没有 ROM 块可用,NVRAM 管理器应从应用请求默认数据。这应可配置。 |
| 理由 | 灵活性 |
| 用例 | 校准数据无法由常量数据提供。 |
⌋(RS_BRF_01840, RS_BRF_01848)
##### 6.1.3.10 [SRS_Mem_08547] NVRAM 管理器应能区分显式无效和不一致数据
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应能区分显式无效和不一致数据。 |
| 理由 | 显式无效(甚至空白)数据块不应表示要报告给 DEM 的错误情况。 |
| 用例 | 如果 NVRAM 管理器检测到不一致数据,如由于中止的写操作或 CRC 错误,应报告错误。对于无效数据,不报告错误。 |
| 支持材料 | SRS_MemHwAb_14014, SRS_MemHwAb_14015, SRS_MemHwAb_14016 |
⌋(RS_BRF_01840, RS_BRF_00129)
##### 6.1.3.11 [SRS_Mem_08550] NVRAM 管理器应提供将永久 RAM 数据块标记为已修改/未修改的服务
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供将永久 RAM 数据块标记为已修改/未修改的服务。关机时仅保存已标记为已修改的数据到 NV。此服务的可用性应可配置。 |
| 理由 | 减少写周期,加快关机。 |
| 用例 | 应用最清楚何时将数据写回 NV 存储器。使用此功能将减少所需写周期数,从而减少漫游块和 NV 存储器消耗的需求,并由于底层 HW 引起的相当大的开销(提供预擦除存储器)而可能的缓慢写入而加快关机操作。 |
| 依赖 | [SRS_Mem_08546] RAM 数据块免于数据丢失的保护 |
⌋(RS_BRF_00129)
##### 6.1.3.12 [SRS_Mem_08545] NVRAM 管理器应提供将 NVRAM 块的永久 RAM 数据块标记为有效的服务
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供将 NVRAM 块的永久 RAM 数据块标记为有效的服务。<br>此外,该服务应更新完整性信息(如果已配置)。<br>此服务的可用性应可配置。 |
| 理由 | 仅保存有效数据到 NV。在启动时增加使用 RAM 中最新数据(而非从 NV 重新加载旧数据)的可能性。 |
| 用例 | 读取失败可能导致 RAM 内容无效。此内容不应保存到 NV 存储器。在这种情况下,应用负责通过呈现数据并调用此服务将其标记为有效来处理此情况。 |
| 依赖 | [SRS_Mem_08546] RAM 数据块免于数据丢失的保护 |
⌋(RS_BRF_00129)
##### 6.1.3.13 [SRS_Mem_08011] NVRAM 管理器应提供在非易失存储器中使数据块无效的服务
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供在非易失存储器中使数据块无效的服务。块由唯一标识符引用。<br><br>此服务的可用性应可配置。 |
| 理由 | 避免加载过时数据,特别是位置信息。 |
| 用例 | 天窗位置(增量电机位置)必须在每次移动后保存到 NVRAM 块。在天窗每次新移动之前,此位置必须被标记为无效。否则,天窗操作期间的复位将导致无效的天窗位置(因为加载来自 NVRAM 的旧位置)。这可能导致天窗机械结构损坏(撞击末端位置时)或严重伤害。 |
⌋(RS_BRF_01840)
##### 6.1.3.14 [SRS_Mem_08544] NVRAM 管理器应提供擦除与 NVRAM 块关联的 NV 块的服务
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供擦除与 NVRAM 块关联的 NV 块的服务。NVRAM 块由唯一标识符引用。此服务的可用性应可配置。 |
| 理由 | 显式擦除以支持下方列出的用例。 |
| 用例 | 崩溃数据写入:无写前擦除的延迟,因此预擦除 NV 块必须在应用定义的点(如通过诊断服务)完成。这不能自动完成。 |
⌋(RS_BRF_01416)
##### 6.1.3.15 [SRS_Mem_08007] NVRAM 管理器应提供选择有效数据集 NV 块的服务
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供选择有效数据集 NV 块的服务。此服务应将数据集编号(ROM 或 NVRAM)关联到相应的 RAM 块。 |
| 理由 | 使运行时选择 ROM/NVRAM 中不同数据集成为可能。 |
| 用例 | 一个 ECU 用于一辆汽车的多个型号/国家变体。根据车辆变体,选择 NVRAM 或 ROM 中对应的数据集。 |
| 支持材料 | BSW08006,块管理类型 — 数据集 |
⌋(RS_BRF_01832)
##### 6.1.3.16 [SRS_Mem_08542] NVRAM 管理器应提供作业处理顺序的优先级化
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供作业处理顺序的优先级化。最高优先级作业应首先处理;具有相同优先级的作业应以 FIFO 顺序执行。<br><br>此优先级化应可配置。如果禁用,作业应以 FIFO 顺序执行。 |
| 理由 | 某些数据必须比其他数据写入得更快。因此处理它们应优先。立即数据应抢占正在运行的较低优先级操作。 |
| 用例 | 崩溃数据写入;基于优先级的数据保存(如 SiemensVDO 的 NVRAM 管理器) |
| 依赖 | [SRS_Mem_08543], [SRS_Mem_08541] |
⌋(RS_BRF_01048)
##### 6.1.3.17 [SRS_Mem_00020] NVRAM 管理器应提供读出读/写操作状态的功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供读出读/写操作状态的功能。 |
| 理由 | NVRAM 管理器应支持各种非易失存储器设备。某些设备的访问时间与 ECU 的实时需求相比较长。因此 NVRAM 管理器应提供具有确定操作当前状态功能的异步 API。 |
| 用例 | 串行 EEPROM 的读/写 |
⌋()
##### 6.1.3.18 [SRS_Mem_00127] NVRAM 管理器应允许单独启用/禁用每个 NVRAM 块的写保护
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应允许单独启用/禁用每个 NVRAM 块的写保护。<br><br>写保护块的 RAM 块数据区域可无限制地更改。<br><br>如果 NV 块受保护,对此块的后续写访问作业将被拒绝。启用写保护的 NVRAM 块不能保存到 NV 存储器。复位后,写保护应根据初始写保护设置。<br><br>此服务的可用性应可配置。 |
| 理由 | 某些数据块不被应用更改,仅由特殊的 EOL(下线)/诊断服务更改 |
| 用例 | 编码数据,EOL(下线)数据。 |
| 依赖 | [SRS_Mem_08009] 块的默认写保护 |
⌋(RS_BRF_01840)
##### 6.1.3.19 [SRS_Mem_00030] NVRAM 管理器应实现保存在 NVRAM 中数据的一致性/完整性检查机制
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应实现操作期间保存在 NVRAM 中数据的一致性/完整性检查机制,即使在异步复位或断电的情况下。位翻转也应涵盖。<br><br>实现提示:校验和是一种可能性;此外,可使用写访问字节(有效/无效)。 |
| 理由 | 错误检测。 |
| 用例 | 用于检测位翻转的签名。 |
| 依赖 | [SRS_Mem_08001] 数据一致性检查配置 |
⌋(RS_BRF_01840, RS_BRF_00129)
##### 6.1.3.20 [SRS_Mem_08555] NVRAM 管理器应提供在读取 NVRAM 块时静态验证块标识符的机制
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供在读取 NVRAM 块时静态验证块标识符的机制。 |
| 理由 | 防止块错误寻址 |
| 用例 | 可检测硬件寻址错误 |
| 依赖 | [SRS_Mem_00030] 数据一致性/完整性检查 |
⌋(RS_BRF_00129)
##### 6.1.3.21 [SRS_Mem_08556] NVRAM 管理器应提供通过再次读取和比较来验证已写入块数据的机制
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应通过再次读取和比较来提供验证已写入块数据的机制。 |
| 理由 | 防止错误写入的数据 |
| 用例 | 可检测硬件写错误 |
| 依赖 | [SRS_Mem_08553] 数据写验证配置 |
⌋(RS_BRF_01840, RS_BRF_00129)
##### 6.1.3.22 [SRS_Mem_00034] NVRAM 管理器对持久存储器的写访问应与 ECU 正常运行准并行执行
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器对持久存储器的写访问应与 ECU 正常运行准并行(并发)执行。数据一致性不得受到威胁。 |
| 理由 | 某些类型存储器的写访问比处理器寄存器访问慢几个数量级。 |
| 用例 | EEPROM 写访问。 |
⌋(RS_BRF_01048, RS_BRF_01812)
##### 6.1.3.23 [SRS_Mem_08558] NVRAM 管理器应提供机制以移除与 NVRAM 块关联的所有未处理请求
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供机制以移除与 NVRAM 块关联的所有未处理请求 |
| 理由 | 在分区终止和随后重启之前源自该分区(如来自属于该分区的 SW-C)的请求不应被处理(因此不应报告完成)。 |
| 用例 | 处理分区的终止和重启。 |
⌋(RS_BRF_01048, RS_BRF_01812)
##### 6.1.3.24 [SRS_Mem_00136] NVRAM 管理器应提供运行时确定与 NVRAM 块关联数据更新的功能
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供运行时确定与 NVRAM 块关联数据更新的功能。NVRAM 块由唯一标识符引用。<br><br>此功能将允许在 RAM 块自上次读或写操作以来未更新的情况下跳过对 NV 存储器的写操作。<br><br>此功能的可用性应可配置。 |
| 理由 | 确定 RAM 块中非易失数据的更新。 |
| 用例 | 避免多余的存储操作。 |
⌋(RS_BRF_01416)
##### 6.1.3.25 [SRS_Mem_00138] NVRAM 管理器应提供触发选定块在 RAM 和 NV 存储器上首次或重新初始化的函数
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应有多块操作可用,对具有永久 RAM 或显式同步的选定块执行以下操作:<br>(1) 从 ROM 块和/或初始化回调执行显式恢复<br>(2) 将这些内容写回 NV 存储器介质。<br><br>如果这些选定块没有恢复数据源(即 ROM 块和/或初始化回调),应执行此 NV 块的无效化,而不是写入恢复数据。在 DATASET 块的情况下,如果选择用于首次初始化,此 NvM 块的所有 NV 块实例应被无效化。 |
| 理由 | 不要让应用或单独管理的工厂程序完成整个工作。 |
| 用例 | (1) 工厂(重新)初始化<br>(2) 开发时清除 NV 存储器<br>(3) 通过测试仪访问重新初始化 |
⌋(RS_BRF_01416)
#### 6.1.4 关机操作
##### 6.1.4.1 [SRS_Mem_08535] NVRAM 管理器应提供触发完整性信息更新和保存 RAM 数据块到 NV 存储器的函数
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供触发完整性信息更新(重新计算校验和,如 CRC)和保存 RAM 数据块到 NV 存储器的函数。此函数仅可影响永久 RAM 数据块,因为临时 RAM 数据块不能自动写回(如由 ECU 状态管理器触发)。<br><br>信息:<br>- 此函数必须由 ECU 状态管理器在关机前调用一次<br>- 此函数可由诊断服务("Save NVRAM")调用 |
| 理由 | 不要让应用完成整个工作。 |
| 用例 | ECU 关机:保存应用的 NV 数据 |
| 支持材料 | [SRS_LIBS_08534] RAM 数据块类别 |
⌋(RS_BRF_01840)
##### 6.1.4.2 [SRS_Mem_08540] NVRAM 管理器应提供中止关机过程的函数
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 如果在 ECU 关机期间检测到 ECU 唤醒条件,NVRAM 管理器应提供函数以中止源自关机过程的写作业。源自应用的队列中的写请求不应受此取消例程影响。<br>此取消不应是破坏性的,即当前正在写入的 NVRAM 块应完成。 |
| 理由 | 允许在 ECU 关机过程中对唤醒条件快速反应。 |
| 用例 | ECU 关机:NVRAM 管理器已开始将所有 RAM 块保存到 NVRAM。在此作业处理期间,发生 ECU 唤醒条件。ECU 必须在给定时限内(如 100ms)可操作。NVRAM 管理器完成所有可能花费如 800ms 的写作业是不可接受的。 |
⌋(RS_BRF_01096)
##### 6.1.4.3 [SRS_Mem_00137] NVRAM 管理器应提供自动验证 NVRAM 块的服务
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应提供自动验证 NVRAM 块的服务。<br><br>此服务必须由 ECU 状态管理器在 ECU 关机的早期阶段调用一次。<br><br>此服务的可用性应可配置。 |
| 理由 | 在 RAM 块数据有效的情况下避免用 ROM 默认数据恢复 RAM 块。 |
| 用例 | ECU 关机:正常关机无法完成(如由于超时、电压下降)。 |
⌋(RS_BRF_01096)
#### 6.1.5 故障操作
##### 6.1.5.1 [SRS_Mem_00038] 可处理的错误不应影响其他软件组件
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器不应将可处理(可治愈或可恢复)的错误报告给其他软件组件。 |
| 理由 | 关注分离,避免不必要的功能降级 |
| 用例 | 数据冗余保存(在两个相同的块中)。如果在一个块中检测到数据损坏,则使用冗余块的内容。应用不受影响。 |
| 依赖 | [SRS_Mem_00129] 自动数据修复 |
| 支持材料 | SRS_LIBS_08529 块管理类型 — 冗余 |
⌋(RS_BRF_01076)
##### 6.1.5.2 [SRS_Mem_00129] NVRAM 管理器应修复管理类型为"NVRAM 冗余"的块中的数据
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 如果检测到数据损坏且可派生有效数据,NVRAM 管理器应修复管理类型为"NVRAM 冗余"的块中的数据。修复周期数应有限,以避免无限循环。 |
| 理由 | 健壮性 |
| 用例 | 冗余 NVRAM 块中的数据损坏(位翻转) |
| 支持材料 | SRS_LIBS_08529 块管理类型 — 冗余 |
⌋(RS_BRF_01840, RS_BRF_00129)
##### 6.1.5.3 [SRS_Mem_08010] 如果无法将 NV 数据读到 RAM,NVRAM 管理器应将 ROM 默认数据复制到对应 RAM 块的数据区域
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 如果 NVRAM 管理器无法将数据从 NV 读到 RAM,它应将 ROM 默认数据复制到对应 RAM 块的数据区域。 |
| 理由 | 健壮性 |
| 用例 | 校准数据集损坏。加载默认校准数据集。 |
| 支持材料 | 见所有块管理类型 |
⌋(RS_BRF_01840, RS_BRF_00129)
##### 6.1.5.4 [SRS_Mem_08015] NVRAM 中的某些 NV 块在首次初始化后永不应被擦除或替换为默认 ROM 数据
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | ECU 重编程后必须保留某些 NVRAM 数据。这意味着 NVRAM 中的某些 NV 块在首次初始化后永远不应被擦除或替换为默认 ROM 数据。 |
| 理由 | 防盗器代码或车辆识别号 |
⌋(RS_BRF_01840)
**注**:这是对配置/引导加载程序的需求。
### 6.2 非功能性需求(质量)
#### 6.2.1 硬件独立性
##### 6.2.1.1 [SRS_Mem_00011] NVRAM 管理器应独立于底层内存硬件
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | NVRAM 管理器应使用现有(标准化)接口访问底层内存硬件。这些接口应抽象出内存硬件。 |
| 理由 | 可移植性、可重用性、通过灵活使用内存设备降低硬件成本 |
⌋(RS_BRF_01800)
#### 6.2.2 易用性
(无具体需求列出)
---
## 7 参考文献
### 7.1 AUTOSAR 交付物
[AUTOSAR_SW_ARCH] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[AUTOSAR_BASIC_SW] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList.pdf
[AUTOSAR_SRS_MEMHW] Requirements on Memory Hardware Abstraction Layer
AUTOSAR_SRS_MemoryHWAbstractionLayer.pdf
[TPS_STDT_0078] SoftwareComponentTemplate
AUTOSAR_TPS_SoftwareComponentTemplate.pdf
---
## 翻译说明
- 本文档完整翻译自 AUTOSAR_SRS_MemoryServices v4.4.0(Document ID 007)。
- 保留所有需求 ID(SRS_Mem_xxxxx、RS_BRF_xxxxx 等)。
- 保留 AUTOSAR 方框符 ⌈⌋。
- 模块缩写(NVRAM、NV、ECU、CRC、EOL 等)保持英文。
Memory/AUTOSAR_SRS_RAMTest.md
+396
View File
@@ -0,0 +1,396 @@
# RAM 测试需求规范
> **文档标题**: Requirements on RAM Test
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 114
> **文档类型**: SRS (Software Requirements Specification)
---
## 文档标识
| 项目 | 内容 |
|------|------|
| Document Title | Requirements on RAM Test |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 114 |
| 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 | 新增第 5 章"需求追溯" |
| 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 | 文档模板与需求追溯的形式化更新;符合 ISO 26262 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 修订 SRS_RamTst_13801;法律免责声明修订 |
| 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 | 移除 [BSW13814] 已被否决的"改良汉明码"测试;法律免责声明修订 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始版本发布 |
---
## 目录
1. [本文档的范围](#1-本文档的范围)
2. [如何阅读本文档](#2-如何阅读本文档)
- 2.1 [使用的约定](#21-使用的约定)
- 2.2 [需求结构](#22-需求结构)
3. [缩略语](#3-缩略语)
4. [功能概述](#4-功能概述)
5. [需求追溯](#5-需求追溯)
6. [需求规范](#6-需求规范)
- 6.1 [功能性需求](#61-功能性需求)
- 6.1.1 [配置](#611-配置)
- 6.1.2 [正常运行](#612-正常运行)
- 6.2 [非功能性需求](#62-非功能性需求)
7. [参考文献](#7-参考文献)
---
## 1 本文档的范围
本文档规定了 RAM Test 模块的需求。
本文档仅涵盖用于检查 RAM 的软件算法的需求。硬件 RAM 检查(如 ECC 校验)不在本文档范围之内。
---
## 2 如何阅读本文档
每条需求都有一个以"BSW"(代表"Basic Software")为前缀的唯一标识符。对于任何评审注释、备注或问题,请引用此唯一 ID,而非章节号或页码!
### 2.1 使用的约定
- AUTOSAR 文档中需求的表示形式遵循 [5] 中规定的表格格式。
- 需求中使用以下特定语义。
本文档中的关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 需按下述方式解读。请注意,使用这些关键字的文档的需求级别会修饰它们的强制性。
- **MUST**:该词或术语 "REQUIRED" 或 "SHALL" 表示该定义是规范的绝对要求。
- **MUST NOT**:该短语或短语 "SHALL NOT" 表示该定义是规范的绝对禁止项。
- **SHOULD**:该词或形容词 "RECOMMENDED" 表示在特定情况下可能存在忽略某项的合理原因,但必须在选择不同方案之前充分理解并慎重权衡所有影响。
- **SHOULD NOT**:该短语或短语 "NOT RECOMMENDED" 表示在特定情况下可能存在该特定行为可接受甚至有用的合理原因,但应在实施任何带有该标签的行为之前充分理解所有影响并慎重权衡。
- **MAY**:该词或形容词 "OPTIONAL" 表示某项是真正可选的。
### 2.2 需求结构
每个模块特定章节包含基础软件模块的简短功能描述。每章中同类需求归类于以下小标题之下(如适用):
**功能性需求**:
- 配置(模块中哪些元素需要可配置)
- 初始化
- 正常运行
- 关机运行
- 故障运行
- ……
**非功能性需求**:
- 时序需求
- 资源使用
- 易用性
- 为其他工作包提供的输出(如描述模板、工具支持等)
- ……
---
## 3 缩略语
| 缩略语 | 描述 |
|--------|------|
| ECU | Electric Control Unit(电子控制单元) |
| EOL | End Of Line(下线)。常用于 "EOL Programming" 或 "EOL Configuration" |
| MAL | Microcontroller Abstraction Layer 旧名称(已由 MCAL 替代,因为 "MAL" 在法语中意为 "差") |
| MCAL | Microcontroller Abstraction Layer(微控制器抽象层) |
| MCU | Microcontroller Unit(微控制器单元) |
| NMI | Non maskable interrupt(不可屏蔽中断) |
| OS | Operating System(操作系统) |
| SPAL | 本工作组的名称 |
| SFR | Special Function Register(特殊功能寄存器) |
| RTE | Runtime environment(运行时环境) |
| WP | Work Package(工作包) |
| 缩写 | 描述 |
|------|------|
| STD | Standard(标准) |
| REQ | Requirement(需求) |
| UNINIT | Uninitialized(未初始化) |
由于本文档由专业人员为专业人员撰写,其他所有术语均假定为读者已知。
---
## 4 功能概述
本模块的任务是通过软件测试 RAM 内存区域。
---
## 5 需求追溯
| 需求 | 描述 | 满足者 |
|------|------|--------|
| RS_BRF_00057 | AUTOSAR 应定义一种内存映射机制 | SRS_RamTst_13802 |
| RS_BRF_00129 | AUTOSAR 应支持数据损坏检测与保护 | SRS_RamTst_13803, SRS_RamTst_13804, SRS_RamTst_13809, SRS_RamTst_13811, SRS_RamTst_13822, SRS_RamTst_13823, SRS_RamTst_13824 |
| RS_BRF_01048 | AUTOSAR 模块设计应支持多任务环境下模块协同工作 | SRS_RamTst_13809 |
| RS_BRF_01056 | AUTOSAR BSW 模块应提供标准化接口 | SRS_RamTst_13810 |
| RS_BRF_01064 | AUTOSAR BSW 应提供回调函数以访问上层模块 | SRS_RamTst_13820 |
| RS_BRF_01472 | AUTOSAR 应支持模式 | SRS_RamTst_13822, SRS_RamTst_13823, SRS_RamTst_13824 |
| RS_BRF_01504 | AUTOSAR 应处理 ECU 睡眠引起的内存损坏 | SRS_RamTst_13804 |
| RS_BRF_02040 | AUTOSAR BSW 与 RTE 应确保数据一致性 | SRS_RamTst_13816 |
| RS_BRF_02048 | AUTOSAR 应支持使用硬件内存保护功能以提升安全性 | SRS_RamTst_13825 |
| RS_BRF_02064 | AUTOSAR 应使用硬件通信数据完整性机制 | SRS_RamTst_13825 |
| RS_BRF_02224 | AUTOSAR 应支持运行时硬件测试 | SRS_RamTst_13800, SRS_RamTst_13801, SRS_RamTst_13804, SRS_RamTst_13809, SRS_RamTst_13811, SRS_RamTst_13812, SRS_RamTst_13822, SRS_RamTst_13823, SRS_RamTst_13824 |
---
## 6 需求规范
### 6.1 功能性需求
#### 6.1.1 配置
##### 6.1.1.1 [SRS_RamTst_13800] 被测单元数量应可在运行时更改
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 为了响应不同需求(睡眠、驾驶循环),用户应有可能"在线"更改每个周期内被测单元的数量。 |
| 理由 | 影响中断禁用时间。 |
| 用例 | 当车辆行驶时,系统中断锁定时间必须远短于睡眠模式下的时间。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_02224)
##### 6.1.1.2 [SRS_RamTst_13801] 测试单元大小应作为已发布参数
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 实现者应根据控制器特性为特定测试实现选择测试单元大小(位、字节、字、长字)。该参数应与具体实现一起发布给集成方。 |
| 理由 | -- |
| 用例 | 实现者根据控制器特性进行运行时优化。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_02224)
##### 6.1.1.3 [SRS_RamTst_13802] 多个 RAM 区域应可在后构建/链接时配置
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应可配置多个 RAM 区域(通过配置其起始与结束地址)。如果两个 RAM 区域重叠,且在测试其中一个块时在重叠区域检测到错误,则驱动不保证更新另一个块的状态。 |
| 理由 | -- |
| 用例 | 用户应有可能配置内存映射。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_00057)
##### 6.1.1.4 [SRS_RamTst_13803] 应可在预编译时选择可用 RAM 测试算法的子集
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 用户应在预编译时选择与项目安全需求匹配的可用算法。 |
| 理由 | 避免未使用代码。 |
| 用例 | 取决于 ECU 安全分析,应可选择不同的 RAM 测试算法。为节省 ROM 空间,算法应可在编译时选择。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_00129)
##### 6.1.1.5 [SRS_RamTst_13804] 应可在运行时从预编译选定的 RAM 检查测试算法的子集中进一步选择
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 用户应在运行时从可用算法中选择测试算法,以符合项目安全需求。 |
| 理由 | 提供不同级别的测试。 |
| 用例 | 正常运行期间执行简单测试,而在进入睡眠模式前将执行更复杂的 RAM 测试算法。由于中断延迟需求更严格,复杂的 RAM 测试无法在正常运行期间执行。 |
| 依赖 | [SRS_RamTst_13803] |
| 支持材料 | -- |
⌋(RS_BRF_00129, RS_BRF_02224, RS_BRF_01504)
#### 6.1.2 正常运行
##### 6.1.2.1 [SRS_RamTst_13822] 应提供具有低覆盖率的安全机制
⌈
| 字段 | 内容 |
|------|------|
| 类型 | New |
| 描述 | 应提供满足 60% 诊断覆盖率的安全度量。它可以由硬件方式、适当的测试算法或两者提供。 |
| 理由 | 检测 RAM 中的永久性故障。 |
| 用例 | 支持 EOL、快速启动测试以及需要低诊断覆盖率测试的场景,例如,如果系统仅具有低 ISO 26262 ASIL 等级的安全目标。 |
| 依赖 | -- |
| 支持材料 | ISO 26262-5:2011, Tables 4, 5, D.1 and D.6, sections D.2.5.1, D.2.5.2 and D.2.5.3 |
⌋(RS_BRF_00129, RS_BRF_02224, RS_BRF_01472)
##### 6.1.2.2 [SRS_RamTst_13823] 应提供具有中等覆盖率的测试算法
⌈
| 字段 | 内容 |
|------|------|
| 类型 | New |
| 描述 | 应提供满足 90% 诊断覆盖率的安全度量。它可以由硬件方式、适当的测试算法或两者提供。 |
| 理由 | 检测 RAM 中的永久性故障。 |
| 用例 | 支持 EOL、启动测试以及需要中等诊断覆盖率测试的场景,例如,如果系统安全目标的 ASIL 等级的 ISO 26262 潜在故障度量可以通过中等覆盖率实现。 |
| 依赖 | -- |
| 支持材料 | ISO 26262-5:2011, Tables 4, 5, D.1 and D.6, sections D.2.5.1, D.2.5.2 and D.2.5.3 |
⌋(RS_BRF_00129, RS_BRF_02224, RS_BRF_01472)
##### 6.1.2.3 [SRS_RamTst_13824] 应提供具有高覆盖率的测试算法
⌈
| 字段 | 内容 |
|------|------|
| 类型 | New |
| 描述 | 应提供满足 99% 诊断覆盖率的安全度量。它可以由硬件方式、适当的测试算法或两者提供。 |
| 理由 | 检测 RAM 中的永久性故障。 |
| 用例 | 支持 EOL、严谨的启动、关机或运行时测试,以及需要高诊断覆盖率测试的场景,例如,如果系统具有高 ISO 26262 ASIL 等级的安全目标。 |
| 依赖 | -- |
| 支持材料 | ISO 26262-5:2011, Tables 4, 5, D.1 and D.6, sections D.2.5.1, D.2.5.2 and D.2.5.3 |
⌋(RS_BRF_00129, RS_BRF_02224, RS_BRF_01472)
##### 6.1.2.4 [SRS_RamTst_13809] 应可将 RAM 测试执行划分为更小的部分
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 应可将 RAM 测试执行划分为更小的部分。每次调用 RAM 测试时,应仅可执行整个 RAM 测试的一部分。 |
| 理由 | 避免长时间中断禁用。 |
| 用例 | 需要短中断延迟时间的驱动程序。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_00129, RS_BRF_02224, RS_BRF_01048)
##### 6.1.2.5 [SRS_RamTst_13810] 每块的 RAM 测试执行当前状态应通过 get status 接口可用
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | RAM 测试每块的执行状态(RESULT_NOT_TESTED、RESULT_OK、RESULT_NOT_OK 和 RESULT_UNDEFINED)应提供给用户。用户应有可能随时获取 RAM 测试的状态。这应实现为 get status 接口,并可在编译时进行配置。此功能应为可选。 |
| 理由 | -- |
| 用例 | 诊断可能需要知道是否发生了错误。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01056)
##### 6.1.2.6 [SRS_RamTst_13820] RAM 测试执行状态应通过通知机制提供
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 关于何时检测到错误或测试完成的信息应通过通知机制提供给用户。此功能应为可选。 |
| 理由 | -- |
| 用例 | 诊断可能需要立即知道是否检测到错误。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_01064)
##### 6.1.2.7 [SRS_RamTst_13811] RAM 测试模块应能够以非破坏性方式执行其测试
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | RAM 测试模块应能够以非破坏性方式执行其测试。 |
| 理由 | 原始数据应被保留。 |
| 用例 | 销毁所有 RAM 数据可能导致更长的反应时间(如唤醒)、更高的资源消耗(如:EEPROM)。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_02224, RS_BRF_00129)
##### 6.1.2.8 [SRS_RamTst_13812] RAM 测试模块应能够以破坏性方式执行其测试
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | RAM 测试模块应能够以破坏性方式执行其测试。测试后 RAM 的状态应为定义的。 |
| 理由 | 原始数据无需保留。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_02224)
### 6.2 非功能性需求
#### 6.2.1 [SRS_RamTst_13816] 应考虑指令/数据队列的影响
⌈
| 字段 | 内容 |
|------|------|
| 类型 | Valid |
| 描述 | 写入一个单元后再读回,可能导致读回的值来自数据队列而非待测试 RAM 单元的问题。此时,需要注入指令以消除此类影响。 |
| 理由 | 从已测试单元读回值。 |
| 用例 | 带有指令或数据队列的控制器可能有此类影响。 |
| 依赖 | -- |
| 支持材料 | -- |
⌋(RS_BRF_02040)
#### 6.2.2 [SRS_RamTst_13825] RAM 测试模块应可用于符合 ISO 26262 不同 ASIL 等级的需求
⌈
| 字段 | 内容 |
|------|------|
| 类型 | New |
| 描述 | RAM 测试模块应为 RAM 中的永久性故障提供并记录(故障模型与故障覆盖率)诊断能力,以便实现 ISO 26262 不同 ASIL 等级的潜在故障度量目标。 |
| 理由 | AUTOSAR 适用于需要符合 ISO 26262 的系统。 |
| 用例 | -- |
| 依赖 | -- |
| 支持材料 | ISO 26262-5:2011, Tables 4, 5, D.1 and D.6, sections D.2.5.1, D.2.5.2 and D.2.5.3 |
⌋(RS_BRF_02048, RS_BRF_02064)
---
## 7 参考文献
### 7.1 AUTOSAR 交付物
[1] Glossary
AUTOSAR_TR_Glossary.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 相关标准与规范
[6] CEI/IEC 61508-2:2000: 关于电气/电子/可编程电子安全相关系统的需求
---
## 翻译说明
- 本文档完整翻译自 AUTOSAR_SRS_RAMTest v4.4.0(Document ID 114)。
- 保留所有需求 ID(如 SRS_RamTst_xxxxx、RS_BRF_xxxxx)。
- 保留 AUTOSAR 方框符 ⌈⌋。
- 保留 ISO 26262 等标准引用。
- 模块缩写(RamTst、ECU 等)保持英文。
Memory/AUTOSAR_SWS_EEPROMAbstraction.md
+554
View File
@@ -0,0 +1,554 @@
# EEPROM 抽象规范
> **文档标题**: Specification of EEPROM Abstraction
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 287
> **文档类型**: SWS (Software Specification)
---
## 文档标识
| 项目 | 内容 |
|------|------|
| Document Title | Specification of EEPROM Abstraction |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 287 |
| 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 | 引入运行时错误;在 Ea_InvalidateBlock 和 Ea_EraseImmediateBlock 中设置 MEMIF_BUSY |
| 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 | 需求与 BSW 特性、通用和模块特定需求关联 |
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 编辑性修订 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 移除模块主函数的时序需求;为 Ea_Write 增加 const 限定符;新增 EaMainFunctionPeriod 配置参数;Fls_GetStatus 在模块未初始化时返回 MEMIF_UNINIT |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 按新的 SWS_BSWGeneral 重做;已发布参数 EaMaximumBlockingTime 弃用;配置参数 EaIndex 弃用 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 引入参数检查和相应 DET 错误;细化内部管理操作处理;模块短名变更 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 新增 NULL 指针检查;模块间检查细化;澄清返回值描述 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 澄清配置变体;通知例程多重性更正;重新表述作业结果处理;文件包含结构变更 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | EA_MAXIMUM_BLOCKING_TIME 作为已发布参数 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | 文件包含结构更新;初始化函数 API 适配;EA 块编号范围适配 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始版本发布 |
---
## 目录
1. [介绍与功能概述](#1-介绍与功能概述)
2. [缩略语](#2-缩略语)
3. [相关文档](#3-相关文档)
4. [约束与假设](#4-约束与假设)
5. [模块依赖](#5-模块依赖)
6. [需求追溯](#6-需求追溯)
7. [功能规范](#7-功能规范)
8. [API 规范](#8-api-规范)
9. [时序图](#9-时序图)
10. [配置规范](#10-配置规范)
11. [不适用需求](#11-不适用需求)
---
## 1 介绍与功能概述
本规范描述 AUTOSAR 基础软件模块 EEPROM Abstraction (EA) 的功能、API 和配置。
EEPROM Abstraction (EA) 模块抽象 EEPROM 驱动的寻址方案,并为上层提供统一的(虚拟)寻址方案以及虚拟无限的擦/写周期数。
EA 模块属于 ECU 抽象层,使上层(NVRAM 管理器)与底层 EEPROM 驱动和器件解耦。
---
## 2 缩略语
| 缩略语 | 描述 |
|--------|------|
| EA | EEPROM Abstraction |
| EEPROM | 电可擦可编程只读存储器 |
| FEE | Flash EEPROM Emulation |
| NV | Non Volatile(非易失) |
| NvM | NVRAM Manager |
| MemIf | Memory Abstraction Interface |
| (Logical) Block(逻辑块) | 模块用户可单独寻址的连续内存区域 |
| Page(页) | 一次可写入的最小内存量 |
| Sector(扇区) | 一次可擦除的最小内存量 |
| Virtual Page(虚拟页) | EA 模块用于内部地址计算的可配置最小寻址单元 |
| DEM | Diagnostic Event Manager |
| DET | Default Error Tracer |
---
## 3 相关文档
### 3.1 输入文档
- List of Basic Software Modules — AUTOSAR_TR_BSWModuleList.pdf
- Layered Software Architecture — AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
- General Requirements on Basic Software Modules — AUTOSAR_SRS_BSWGeneral.pdf
- Requirements on Memory Hardware Abstraction Layer — AUTOSAR_SRS_MemoryHWAbstractionLayer.pdf
- Specification of EEPROM Driver — AUTOSAR_SWS_EEPROMDriver.pdf
- Specification of Memory Abstraction Interface — AUTOSAR_SWS_MemoryAbstractionInterface.pdf
- Specification of NVRAM Manager — AUTOSAR_SWS_NVRAMManager.pdf
- Specification of Default Error Tracer — AUTOSAR_SWS_DefaultErrorTracer.pdf
- General Specification of Basic Software Modules — AUTOSAR_SWS_BSWGeneral.pdf
### 3.2 相关规范
AUTOSAR 提供基础软件模块通用规范(SWS BSW General),也适用于 EEPROM Abstraction。
---
## 4 约束与假设
### 4.1 限制
无限制。
### 4.2 适用车型领域
无限制。
---
## 5 模块依赖
EA 模块依赖于底层 EEPROM 驱动并实现内存抽象架构。
---
## 6 需求追溯
(主要追溯关系,完整表见原文 PDF)
| 需求 | 满足者 |
|------|--------|
| SRS_BSW_00101 | SWS_Ea_00084, 00017 |
| SRS_BSW_00392 | SWS_Ea_00083, 00117, 00190 |
| SRS_BSW_00406 | SWS_Ea_00128 |
| SRS_BSW_00414 | SWS_Ea_00190, 00191 |
| SRS_MemHwAb_14001 (起止地址对齐) | SWS_Ea_00005, 00068, 00075, 00137 |
| SRS_MemHwAb_14002 (写周期配置) | SWS_Ea_00080 |
| SRS_MemHwAb_14005 (32位虚拟地址) | SWS_Ea_00066, 00075 |
| SRS_MemHwAb_14006 (64K 边界对齐) | SWS_Ea_00024 |
| SRS_MemHwAb_14007 (读对齐限制) | SWS_Ea_00021 |
| SRS_MemHwAb_14009 (地址转换) | SWS_Ea_00007, 00021, 00024, 00036, 00063 |
| SRS_MemHwAb_14010 (完整块写) | SWS_Ea_00087, 00151, 00159, 00181 |
| SRS_MemHwAb_14012 (写访问分散) | SWS_Ea_00079 |
| SRS_MemHwAb_14013 (立即数据不延迟) | SWS_Ea_00025 |
| SRS_MemHwAb_14014 (数据不一致检测) | SWS_Ea_00046, 00047, 00188, 00189 |
| SRS_MemHwAb_14015 (报告不一致) | SWS_Ea_00104 |
| SRS_MemHwAb_14016 (不返回不一致数据) | SWS_Ea_00104 |
| SRS_MemHwAb_14017 (扩展 EEPROM 驱动) | SWS_Ea_00150 |
| SRS_MemHwAb_14026 (不使用 0x0000/0xFFFF) | SWS_Ea_00006 |
| SRS_MemHwAb_14028 (无效化块) | SWS_Ea_00037, 00074, 00091, 00194 |
| SRS_MemHwAb_14029 (部分读取) | SWS_Ea_00022, 00086, 00158, 00179 |
| SRS_MemHwAb_14031 (取消异步操作) | SWS_Ea_00077, 00078, 00088, 00160 |
| SRS_MemHwAb_14032 (擦除立即数据) | SWS_Ea_00063, 00064, 00065, 00093, 00104 |
完整追溯表见原文 PDF。
---
## 7 功能规范
### 7.1 总体行为
[SWS_Ea_00137] ⌈EEPROM Abstraction (EA) 一次只接受一个作业,即模块不应为待处理作业提供队列(这是 NVRAM 管理器的职责)。⌋
**注**:由于 NvM 是本模块的唯一调用者,为保持本模块合理小巧,模块函数不应检查模块当前是否忙。NvM 负责将待处理作业串行化,只在前一作业完成或取消后开始新作业。
#### 7.1.1 寻址方案与分段
EEPROM Abstraction (EA) 为上层提供 32 位虚拟线性地址空间和统一的分段方案。32 位虚拟地址由:
- **16 位块编号** — 允许(理论上)65536 个逻辑块
- **16 位块偏移** — 允许每块(理论上)64 KB 的块大小
组成。
16 位块编号表示可配置的(虚拟)分页机制。此地址对齐的值可从底层 EEPROM 驱动和器件派生。虚拟分页可通过参数 `EA_VIRTUAL_PAGE_SIZE` 配置。
[SWS_Ea_00075] ⌈Ea 模块配置应使虚拟页大小(`EA_VIRTUAL_PAGE_SIZE` 中定义)为物理页大小的整数倍,即不允许配置小于实际物理页大小的虚拟页。⌋
**示例**:虚拟页大小配置为 8 字节,因此地址对齐为 8 字节。逻辑块编号 1 放在物理地址 x,逻辑块编号 2 放在 x+8,逻辑块编号 3 放在 x+16。
[SWS_Ea_00005] ⌈每个已配置逻辑块应占用配置虚拟页大小的整数倍。⌋
**示例**:如虚拟页大小为 8 字节,逻辑块可为 8、16、24、32 字节等,但不能为 10、20、50 字节等。
[SWS_Ea_00068] ⌈逻辑块不应相互重叠且不应相互包含。⌋
[SWS_Ea_00006] ⌈块编号 0x0000 和 0xFFFF 不应配置为逻辑块。⌋ (SRS_MemHwAb_14026)
#### 7.1.2 地址计算
[SWS_Ea_00007] ⌈根据 EA 模块的实现和使用的具体地址格式,EA 模块的函数应将 16 位块编号和 16 位块偏移组合,以派生底层 EEPROM 驱动所需的物理 EEPROM 地址。⌋
[SWS_Ea_00066] ⌈仅 16 位块编号中不表示特定数据集或冗余副本的那些位应用于地址计算。⌋
**示例**:数据集信息配置为编码在 16 位块编号的 4 个 LSB 中(允许每 NVRAM 块最多 16 个数据集,共 4094 个 NVRAM 块)。实现者将逻辑块所有数据集直接相邻存储,使用块长度和指针访问每个数据集。
#### 7.1.3 擦/写周期限制
[SWS_Ea_00079] ⌈Ea 模块配置应在配置参数 `EaNumberOfWriteCycles` 中定义每个逻辑块预期的擦/写周期数。⌋
[SWS_Ea_00080] ⌈如果底层 EEPROM 器件或器件驱动每物理内存单元未提供至少已配置的擦/写周期数(在参数 `EepAllowedWriteCycles` 中给出),EA 模块应提供机制以分散擦/写访问,使物理器件不被过度使用。这也适用于 EA 模块内部使用的所有管理数据。⌋
**示例**:逻辑块 1 预期 500,000 写周期,而底层 EEPROM 器件和驱动仅规定 100,000 擦除周期。EA 模块必须提供(至少)5 个独立内存区域,在它们之间交替访问。
#### 7.1.4 "立即"数据处理
包含立即数据的块必须瞬时写入,即此类块应可在无需首先擦除相应内存区域(如使用预擦除内存)的情况下写入。NVRAM 管理器应在写入立即数据前取消正在进行的较低优先级读/擦/写或比较作业。
**注**:正在硬件上运行的操作(如写入一页或擦除一个扇区)通常一旦开始就不能中止。因此即使对立即数据,最长硬件操作的最大时间也必须接受为延迟。
#### 7.1.5 管理块一致性信息
[SWS_Ea_00046] ⌈Ea 模块应为每个块管理该块从 EA 模块的角度是否"正确"的信息。此一致性信息应仅涉及块的内部处理,而非块的内容。⌋
[SWS_Ea_00047] ⌈当块写操作开始时,EA 模块应将相应块标记为不一致。块写操作成功结束时,EA 模块应将块标记为(再次)一致。⌋
### 7.2 错误分类
#### 7.2.1 开发错误
[SWS_Ea_00196] ⌈
| 错误类型 | 相关性 | 相关错误代码 | 值[hex] |
|----------|--------|--------------|---------|
| 模块未初始化即调用 API 服务 | Development | EA_E_UNINIT | 0x01 |
| 以无效块编号调用 API 服务 | Development | EA_E_INVALID_BLOCK_NO | 0x02 |
| 以无效块偏移调用 API 服务 | Development | EA_E_INVALID_BLOCK_OFS | 0x03 |
| 以无效指针参数调用 API 服务 | Development | EA_E_PARAM_POINTER | 0x04 |
| 以无效块长度信息调用 API 服务 | Development | EA_E_INVALID_BLOCK_LEN | 0x05 |
| Ea_Init 失败 | Development | EA_E_INIT_FAILED | 0x09 |
⌋
#### 7.2.2 运行时错误
| 错误类型 | 相关错误代码 | 值[hex] |
|----------|--------------|---------|
| 模块忙时调用 API 服务 | EA_E_BUSY | 0x06 |
| Ea_Cancel 调用时无待处理作业 | EA_E_INVALID_CANCEL | 0x08 |
#### 7.2.3 瞬态故障
无瞬态故障。
#### 7.2.4 生产错误
无生产错误。
#### 7.2.5 扩展生产错误
无扩展生产错误。
---
## 8 API 规范
### 8.1 导入的类型
[SWS_Ea_00083] ⌈
| 模块 | 头文件 | 导入类型 |
|------|--------|----------|
| Eep | Eep.h | Eep_AddressType, Eep_LengthType |
| MemIf | MemIf.h | MemIf_JobResultType, MemIf_ModeType, MemIf_StatusType |
| Std_Types | StandardTypes.h | Std_ReturnType, Std_VersionInfoType |
⌋
### 8.2 类型定义
#### Ea_ConfigType
| 项 | 内容 |
|-----|------|
| Name | Ea_ConfigType |
| Type | Structure |
| Range | 实现特定 |
| Description | Ea 模块的配置数据结构。 |
| Available via | Ea.h |
### 8.3 函数定义
#### 8.3.1 Ea_Init
```c
void Ea_Init(const Ea_ConfigType* ConfigPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x00 |
| Sync/Async | Synchronous |
| Description | 初始化 EEPROM 抽象模块。 |
[SWS_Ea_00191] ⌈配置指针 `ConfigPtr` 应始终为 NULL_PTR 值。⌋
[SWS_Ea_00017] ⌈应在模块初始化开始时将模块状态从 MEMIF_UNINIT 设为 MEMIF_BUSY_INTERNAL。⌋
[SWS_Ea_00128] ⌈如初始化在 Ea_Init 内完成,成功完成后应将模块状态从 MEMIF_BUSY_INTERNAL 设为 MEMIF_IDLE。⌋
#### 8.3.2 Ea_SetMode
```c
void Ea_SetMode(MemIf_ModeType Mode)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x01 |
| Description | 切换底层 EEPROM 驱动的模式。 |
将调用映射到底层 EEPROM 驱动的 `Eep_SetMode` 函数。
#### 8.3.3 Ea_Read
```c
Std_ReturnType Ea_Read(
uint16 BlockNumber,
uint16 BlockOffset,
uint8* DataBufferPtr,
uint16 Length
)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x02 |
| Sync/Async | Asynchronous |
| Description | 从 `BlockNumber` 块的 `BlockOffset` 偏移开始读取 `Length` 字节到 `DataBufferPtr`。 |
参数检查:
- 模块已初始化
- BlockNumber 有效
- BlockOffset 在块范围内
- Length 大于 0 且不超过块大小
[SWS_Ea_00022] / [SWS_Ea_00086] ⌈接受读取请求,设状态 MEMIF_BUSY,作业结果 MEMIF_JOB_PENDING。⌋
[SWS_Ea_00158] / [SWS_Ea_00179] ⌈在主函数内异步处理读取。⌋
#### 8.3.4 Ea_Write
```c
Std_ReturnType Ea_Write(
uint16 BlockNumber,
const uint8* DataBufferPtr
)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x03 |
| Sync/Async | Asynchronous |
| Description | 将 `DataBufferPtr` 内容写入 `BlockNumber` 块。 |
[SWS_Ea_00087] / [SWS_Ea_00151] ⌈写整个块。⌋
[SWS_Ea_00159] / [SWS_Ea_00181] ⌈异步处理写入。⌋
#### 8.3.5 Ea_Cancel
```c
void Ea_Cancel(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x04 |
| Sync/Async | Synchronous |
| Description | 取消正在进行的异步操作。 |
[SWS_Ea_00077] / [SWS_Ea_00078] ⌈同步取消正在进行的作业,调用底层 `Eep_Cancel`。⌋
[SWS_Ea_00088] ⌈模块状态设为 MEMIF_IDLE,作业结果设为 MEMIF_JOB_CANCELED。⌋
#### 8.3.6 Ea_GetStatus
```c
MemIf_StatusType Ea_GetStatus(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x05 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant |
| Description | 返回状态的服务。 |
#### 8.3.7 Ea_GetJobResult
```c
MemIf_JobResultType Ea_GetJobResult(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x06 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant |
| Description | 返回上次作业结果的服务。 |
可能值:MEMIF_JOB_OK、MEMIF_JOB_FAILED、MEMIF_JOB_PENDING、MEMIF_JOB_CANCELED、MEMIF_BLOCK_INCONSISTENT、MEMIF_BLOCK_INVALID。
#### 8.3.8 Ea_InvalidateBlock
```c
Std_ReturnType Ea_InvalidateBlock(uint16 BlockNumber)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x07 |
| Sync/Async | Asynchronous |
| Description | 使 `BlockNumber` 块无效。 |
[SWS_Ea_00037] / [SWS_Ea_00074] / [SWS_Ea_00091] / [SWS_Ea_00194] ⌈通过设置块管理数据使块无效化,非必需擦除物理内存内容。⌋
#### 8.3.9 Ea_GetVersionInfo
```c
void Ea_GetVersionInfo(Std_VersionInfoType* VersionInfoPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x08 |
| Reentrancy | Reentrant |
| Description | 获取本模块版本信息。 |
#### 8.3.10 Ea_EraseImmediateBlock
```c
Std_ReturnType Ea_EraseImmediateBlock(uint16 BlockNumber)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x09 |
| Sync/Async | Asynchronous |
| Description | 擦除 `BlockNumber` 块(立即数据)。 |
[SWS_Ea_00063] / [SWS_Ea_00064] / [SWS_Ea_00065] / [SWS_Ea_00093] / [SWS_Ea_00104] ⌈仅对包含立即数据的块。⌋
### 8.4 回调通知
由模块用户提供:
- `Ea_JobEndNotification`:作业成功完成时调用
- `Ea_JobErrorNotification`:作业以错误结束时调用
### 8.5 调度函数
#### Ea_MainFunction
```c
void Ea_MainFunction(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0a |
| Description | 执行 EA 模块作业处理的服务。 |
| Available via | SchM_Ea.h |
调用底层 EEPROM 驱动处理读、写、擦除、比较请求。
### 8.6 期望接口
#### 强制接口
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| Eep_Cancel | Eep.h | 取消正在进行的异步操作 |
| Eep_Compare | Eep.h | 比较 EEPROM 与内存数据 |
| Eep_Erase | Eep.h | 擦除 EEPROM 数据 |
| Eep_GetJobResult | Eep.h | 返回作业结果 |
| Eep_GetStatus | Eep.h | 返回状态 |
| Eep_Read | Eep.h | 从 EEPROM 读取 |
| Eep_SetMode | Eep.h | 切换 EEPROM 驱动模式 |
| Eep_Write | Eep.h | 写入 EEPROM |
#### 可选接口
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| Det_ReportError | Det.h | 报告开发错误 |
| Det_ReportRuntimeError | Det.h | 报告运行时错误 |
#### 可配置接口
回调函数(由 NvM 提供):
- `Ea_JobEndNotification` (typically NvM_JobEndNotification)
- `Ea_JobErrorNotification` (typically NvM_JobErrorNotification)
---
## 9 时序图
类似 MemIf:NvM → Ea → Eep 链路上的请求传播,带异步主函数处理。
---
## 10 配置规范
### 10.1 容器与配置参数
#### 10.1.1 Ea
| 项 | 内容 |
|-----|------|
| SWS Item | ECUC_Ea_00100 |
| Module Name | Ea |
| Module Description | EA(EEPROM Abstraction)模块配置 |
| Post-Build Variant Support | true |
#### 10.1.2 EaGeneral
| 参数 | 描述 |
|------|------|
| EaDevErrorDetect | 开发错误检测开关 |
| EaVersionInfoApi | 版本信息 API 启用 |
| EaSetModeApi | SetMode API 启用 |
| EaMainFunctionPeriod | 主函数周期(秒) |
| EaVirtualPageSize | 虚拟页大小 |
#### 10.1.3 EaBlockConfiguration
每个逻辑块配置:
| 参数 | 描述 |
|------|------|
| EaBlockNumber | 块编号(不可为 0x0000 或 0xFFFF) |
| EaBlockSize | 块大小 |
| EaDeviceIndex | 设备索引 |
| EaImmediateData | 是否为立即数据 |
| EaNumberOfWriteCycles | 期望写周期数 |
| EaJobEndNotification | 作业结束通知回调 |
| EaJobErrorNotification | 作业错误通知回调 |
#### 10.1.4 EaPublishedInformation
已发布参数:
- 物理写块大小
---
## 11 不适用需求
[SWS_Ea_00999] ⌈这些需求不适用于本规范。⌋ 涉及多个 SRS_BSW_* 和 SRS_SPAL_* 需求,详见原文 PDF。
---
## 翻译说明
- 本文档完整翻译自 AUTOSAR_SWS_EEPROMAbstraction v4.4.0(Document ID 287,58 页)。
- 保留所有需求 ID(SWS_Ea_xxxxx、SRS_MemHwAb_xxxxx、ECUC_Ea_xxxxx)。
- 保留 AUTOSAR 方框符 ⌈⌋。
- 模块缩写(Ea、Eep、NvM、MemIf、FEE 等)和 API 函数名保持英文。
- 详细配置参数和示例请参考原文 PDF 第 10 章。
Memory/AUTOSAR_SWS_EEPROMDriver.md
+757
View File
@@ -0,0 +1,757 @@
# EEPROM 驱动规范
> **文档标题**: Specification of EEPROM Driver
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 021
> **文档类型**: SWS (Software Specification)
---
## 文档标识
| 项目 | 内容 |
|------|------|
| Document Title | Specification of EEPROM Driver |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 021 |
| 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 | MCAL 多核分发 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 将 EEP_E_TIMEOUT 和 EEP_E_BUSY 从开发错误改为运行时错误;更改 ECUC_Eep_00189 描述 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 删除过时的 7.11 "调试支持"章节和 10.2.1 "变体"子章节;按字节读/写/擦除访问适配;传递给函数的 DataBuffers 对齐 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | DET 重命名和适配;第 7 章错误分类适配 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 为扩展生产错误增加通过/失败标准和额外属性;移除 Eep_Init() 关于 NULL_PTR 检查的冗余 SWS ID |
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 修正 SWS_Eep_00102、SWS_Eep_00068 和 SWS_Eep_00137 的格式 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 从 Eep_MainFunction API 表中移除 'Timing' 行;编辑性修订 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | MemMap.h 改为 Eep_MemMap.h;新增扩展生产错误 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | EEP178 & EEP185 增加 FloatParamDef 参数最小最大值;模块短名称替换为模块缩写 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 新增 DET 错误 EEP_E_PARAM_POINTER、EEP_E_TIMEOUT;版本检查章节(7.10)修订 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 使 SWS_Eep_00003、SWS_Eep_00030、SWS_Eep_00128 中隐藏文本可见;澄清可选回调通知;重做外部 SPI EEPROM 配置示例;改用 VARIANT-POST-BUILD 替代 VARIANT-LINK-TIME;澄清 Eep_Cancel() 同步行为;添加调试支持;新增 HW 故障 DEM 错误代码 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | SWS_Eep_00005 措辞微调;新增 NULL_PTR 检查需求(SWS_Eep_00161, 00162);更新 SWS_Eep_00028 和图 4 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | 常量名修正;擦写周期限制;链接时配置 vs 配置指针检查;比较作业的作业结果未规定 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 文档结构适配 Release 2.0 SWS 模板;适配新的内存抽象架构;取消功能改为异步 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 初始发布 |
---
## 目录
1. [介绍与功能概述](#1-介绍与功能概述)
2. [缩略语](#2-缩略语)
3. [相关文档](#3-相关文档)
4. [约束与假设](#4-约束与假设)
5. [模块依赖](#5-模块依赖)
6. [需求追溯](#6-需求追溯)
7. [功能规范](#7-功能规范)
8. [API 规范](#8-api-规范)
9. [时序图](#9-时序图)
10. [配置规范](#10-配置规范)
11. [不适用需求](#11-不适用需求)
---
## 1 介绍与功能概述
本规范描述 EEPROM 驱动的功能和 API。本规范同时适用于内部和外部 EEPROM 驱动。
EEPROM 驱动提供对 EEPROM 进行读、写、擦除的服务。它还提供将 EEPROM 中数据块与内存(如 RAM)中数据块进行比较的服务。
这些服务的行为是异步的。
内部 EEPROM 驱动直接访问微控制器硬件,位于微控制器抽象层(MCAL)。外部 EEPROM 驱动使用处理程序(大多数情况下为 SPI)或驱动访问外部 EEPROM 设备,位于 ECU 抽象层。
两类驱动的功能需求和功能范围相同,因此 API 在语义上相同。
---
## 2 缩略语
| 缩略语 | 描述 |
|--------|------|
| Data block(数据块) | 一个数据块可包含 1..n 字节,在 EEPROM 驱动 API 中使用。数据块以 EEPROM 中的地址偏移、指向内存位置的指针、长度传递给 EEPROM 驱动。 |
| Data unit(数据单元) | EEPROM 中最小数据实体。对读/写/擦除操作可能不同。<br>**示例 1**:Motorola STAR12 — 读:1 字节;写:2 字节;擦:4 字节<br>**示例 2**:外部 SPI EEPROM 设备 — 读/写/擦:1 字节 |
| Normal mode(普通模式) | 通过 SPI 与 EEPROM 设备的数据交换按字节进行,允许与其他 SPI 设备(如 I/O ASIC、外部看门狗等)协作使用 SPI。 |
| Burst mode(突发模式) | 通过 SPI 与 EEPROM 设备的数据交换按块进行。块大小取决于 EEPROM 属性,例如 64 字节。由于传输大块,SPI 在突发模式下被 EEPROM 访问阻塞。此模式用于 ECU 启动和关机阶段,需要快速数据读写。 |
| EEPROM cell | 持有数据的 EEPROM 设备最小物理单元。通常为 1 字节。 |
| 缩写 | 描述 |
|------|------|
| EEPROM | 电可擦可编程只读存储器 |
| NVRAM | 非易失随机存取存储器 |
| NvM | NVRAM Manager 模块名 |
| EcuM | ECU State Manager 模块名 |
| DEM | Diagnostic Event Manager 模块名 |
| DET | Default Error Tracer 模块名 |
---
## 3 相关文档
### 3.1 输入文档
- [1] Layered Software Architecture — AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
- [2] General Requirements on Basic Software Modules — AUTOSAR_SRS_BSWGeneral.pdf
- [3] Specification of Memory Abstraction Interface — AUTOSAR_SWS_MemoryAbstractionInterface.pdf
- [4] Specification of SPI Handler/Driver — AUTOSAR_SWS_SPIHandlerDriver.pdf
- [5] Specification of ECU Configuration — AUTOSAR_TPS_ECUConfiguration.pdf
- [6] Requirements on EEPROM Driver — AUTOSAR_SRS_EEPROMDriver.pdf
- [7] Specification of Default Error Tracer — AUTOSAR_SWS_DefaultErrorTracer.pdf
- [8] Specification of Diagnostics Event Manager — AUTOSAR_SWS_DiagnosticEventManager.pdf
- [9] AUTOSAR Glossary — AUTOSAR_TR_Glossary.pdf
- [10] Specification of MCU Driver — AUTOSAR_SWS_MCUDriver.pdf
- [11] Basic Software Module Description Template — AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
- [12] List of Basic Software Modules — AUTOSAR_TR_BSWModuleList.pdf
- [13] General Specification of Basic Software Modules — AUTOSAR_SWS_BSWGeneral.pdf
### 3.2 相关规范
AUTOSAR 提供基础软件模块通用规范 [13](SWS BSW General),也适用于 EEPROM 驱动。因此,SWS BSW General 规范应被视为 EEPROM 驱动的附加和必需规范。
---
## 4 约束与假设
### 4.1 限制
EEPROM 驱动不提供数据完整性机制(如校验和、冗余存储等)。
不提供 EEPROM 写保护设置。
### 4.2 适用车型领域
无限制。
### 4.3 适用安全相关环境
如果上层软件为安全相关数据提供以下机制,本模块可在安全相关系统中使用:
- 校验和保护
- 使用数据前检查完整性
- 冗余存储
- 写入 EEPROM 后验证数据。可使用 EEPROM 驱动的比较函数。
---
## 5 模块依赖
EEPROM 驱动有两类:
1. **片上 EEPROM 驱动**:微控制器抽象层(MCAL)的一部分。
2. **外部 EEPROM 设备驱动**:ECU 抽象层的一部分。
[SWS_Eep_00082] ⌈外部 EEPROM 驱动的源代码应独立于微控制器平台。⌋ ()
内部 EEPROM 可能依赖系统时钟、预分频器和 PLL。因此,系统时钟的变更(如 PLL 开 → PLL 关)也可能影响 EEPROM 硬件的时钟设置。EEPROM Driver 模块在其 init 函数中不处理配置时钟、预分频器和 PLL 的寄存器。这必须由 MCU 模块 [10] 完成。
外部 EEPROM 驱动依赖所使用板载通信处理程序(如 SPI Handler/Driver)的 API 和能力。
EEPROM 驱动是内存抽象架构的一部分,因此某些类型依赖 Memory Interface (MemIf) 模块。
### 5.1 文件结构
[SWS_Eep_00228] ⌈如果模块实现使用自定义中断处理,中断服务例程应放在 Eep_Irq.c。⌋ ()
---
## 6 需求追溯
(详细需求追溯表请参考原文 PDF 第 6 章。涉及 SRS_BSW_*、SRS_Eep_*、SRS_SPAL_* 等多个需求类别。主要部分:)
| 需求 | 满足者 |
|------|--------|
| SRS_BSW_00101 | SWS_Eep_00004 |
| SRS_BSW_00323 | SWS_Eep_00016, 00017, 00018 |
| SRS_BSW_00335 | SWS_Eep_00138 |
| SRS_BSW_00337 | SWS_Eep_00000, 00200-00203 |
| SRS_BSW_00406 | SWS_Eep_00006, 00033 |
| SRS_Eep_00087 (异步读) | SWS_Eep_00009, 00013, 00256 |
| SRS_Eep_00088 (异步写) | SWS_Eep_00014, 00015, 00063, 00090, 00256 |
| SRS_Eep_00089 (异步擦除) | SWS_Eep_00019, 00020, 00070, 00072 |
| SRS_Eep_00090 (同步取消) | SWS_Eep_00021, 00027, 00028, 00215, 00216 |
| SRS_Eep_00091 (状态返回) | SWS_Eep_00029 |
| SRS_Eep_00092 (写周期减少) | SWS_Eep_00060, 00064 |
| SRS_Eep_00094 (内存分段) | SWS_Eep_00063, 00070, 00072, 00090 |
| SRS_Eep_00095 (单作业处理) | SWS_Eep_00033, 00036 |
| SRS_Eep_12047 (作业处理函数) | SWS_Eep_00030, 00032 |
| SRS_Eep_12050 (硬件能力限制) | SWS_Eep_00051, 00054, 00057, 00069 |
| SRS_Eep_12091 (异步比较) | SWS_Eep_00025, 00026, 00256 |
| SRS_Eep_12124 (SPI 模式访问) | SWS_Eep_00052, 00053, 00055, 00073 |
| SRS_Eep_12156 (模式切换) | SWS_Eep_00042, 00130, 00132 |
| SRS_Eep_12157 (普通模式读) | SWS_Eep_00051, 00052, 00053 |
| SRS_SPAL_12448 | SWS_Eep_00016, 00017, 00018, 00033 |
完整追溯表见原文 PDF。
---
## 7 功能规范
### 7.1 总体行为
[SWS_Eep_00088] ⌈Eep SWS 应同时适用于内部和外部 EEPROM。Eep SWS 定义 EEPROM 操作(读/写/擦除/比较)的异步服务。⌋ (SRS_Eep_12051)
[SWS_Eep_00036] ⌈Eep 模块不应缓存作业。Eep 模块一次只接受一个作业。作业处理期间,Eep 模块不应接受其他作业。⌋ (SRS_Eep_00095)
[SWS_Eep_00037] ⌈Eep 模块不应缓存要读取或写入的数据。Eep 模块应使用通过 API 传递的指针引用的应用数据缓冲区。⌋ (SRS_SPAL_12075)
[SWS_Eep_00256] ⌈Eep 驱动应在内部处理数据缓冲区对齐。它不应对 RAM 缓冲区的对齐(因其为 uint8*)提出任何要求,而应将传入的指针视为仅按字节对齐。⌋
### 7.2 错误分类
#### 7.2.1 开发错误
[SWS_Eep_00000] ⌈Eep 模块应根据其构建选项(开发/生产模式)检测以下错误:
| 错误类型 | 相关性 | 相关错误代码 | 值[hex] |
|----------|--------|--------------|---------|
| 无效配置集选择 | Development | EEP_E_INIT_FAILED | 0x10 |
| | | EEP_E_PARAM_ADDRESS | 0x11 |
| | | EEP_E_PARAM_DATA | 0x12 |
| | | EEP_E_PARAM_LENGTH | 0x13 |
| 用 NULL 指针调用 API 服务 | Development | EEP_E_PARAM_POINTER | 0x23 |
| 模块未初始化即调用 API 服务 | Development | EEP_E_UNINIT | 0x20 |
⌋ (SRS_BSW_00337, SRS_BSW_00385)
#### 7.2.2 运行时错误
[SWS_Eep_00251] ⌈
| 错误类型 | 相关性 | 相关错误代码 | 值[hex] |
|----------|--------|--------------|---------|
| 驱动繁忙时调用 API 服务 | Runtime | EEP_E_BUSY | 0x21 |
| 超时 | Runtime | EEP_E_TIMEOUT | 0x22 |
⌋ ()
#### 7.2.3 瞬态故障
无瞬态故障。
#### 7.2.4 生产错误
无生产错误。
#### 7.2.5 扩展生产错误
包括以下扩展生产错误:
##### EEP_E_ERASE_FAILED
| 项 | 内容 |
|-----|------|
| Error Name | EEP_E_ERASE_FAILED |
| Short Description | EEPROM 擦除失败(HW) |
| Long Description | Eeprom 模块在 EEPROM 擦除作业因硬件错误失败时报告此错误。 |
| Detection Criteria | Fail: EEPROM 擦除作业失败;Pass: EEPROM 擦除作业成功完成 |
##### EEP_E_WRITE_FAILED
| 项 | 内容 |
|-----|------|
| Error Name | EEP_E_WRITE_FAILED |
| Short Description | EEPROM 写失败(HW) |
| Long Description | Eeprom 模块在 EEPROM 写作业因硬件错误失败时报告此错误。 |
##### EEP_E_READ_FAILED
EEPROM 读作业因硬件错误失败。
##### EEP_E_COMPARE_FAILED
EEPROM 比较作业因硬件错误失败。
### 7.3 错误检测
#### 7.3.1 API 参数检查
[SWS_Eep_00016] ⌈如果 Eep 模块的开发错误检测启用:`Eep_Read()`、`Eep_Write()`、`Eep_Compare()` 和 `Eep_Erase()` 函数应检查 `DataBufferPtr` 不为 NULL。如果 `DataBufferPtr` 为 NULL,它们应引发开发错误 `EEP_E_PARAM_DATA`,否则(如未启用开发错误检测)应返回 E_NOT_OK。⌋ (SRS_BSW_00323, SRS_SPAL_12448)
[SWS_Eep_00017] ⌈如果开发错误检测启用:函数应检查 `EepromAddress` 是否有效。如果不在有效 EEPROM 地址范围内,应引发开发错误 `EEP_E_PARAM_ADDRESS`,否则返回 E_NOT_OK。⌋
[SWS_Eep_00018] ⌈如果开发错误检测启用:函数应检查参数 `Length` 是否在最小值(1)和最大值(`EepSize - EepromAddress`)之间。如不在,引发 `EEP_E_PARAM_LENGTH`,否则返回 E_NOT_OK。⌋
#### 7.3.2 EEPROM 状态检查
[SWS_Eep_00033] ⌈`Eep_SetMode()`、`Eep_Read()`、`Eep_Write()`、`Eep_Compare()` 和 `Eep_Erase()` 函数应检查 EEPROM 状态是否为 MEMIF_IDLE。如果不是:
- 如果模块尚未初始化且开发错误检测启用,引发开发错误 `EEP_E_UNINIT`
- 根据 EEPROM 状态引发运行时错误 `EEP_E_BUSY`
- 以 E_NOT_OK 拒绝服务(除 `Eep_SetMode()` 外,因其无返回值)
⌋
#### 7.3.3 EEPROM 作业遇到硬件故障
- [SWS_Eep_00200] EEP_E_ERASE_FAILED:EEPROM 擦除函数失败时报告
- [SWS_Eep_00201] EEP_E_WRITE_FAILED:EEPROM 写函数失败时报告
- [SWS_Eep_00202] EEP_E_READ_FAILED:EEPROM 读函数失败时报告
- [SWS_Eep_00203] EEP_E_COMPARE_FAILED:EEPROM 比较函数失败时报告
#### 7.3.4 超时监视
[SWS_Eep_00234] ⌈当读、写、擦或比较作业的超时监视失败时,应报告运行时错误代码 `EEP_E_TIMEOUT`。⌋
### 7.4 错误通知
详见 SWS_BSWGeneral 第 7.2 章。
### 7.5 作业处理 — 通用需求
[SWS_Eep_00128] ⌈Eep 模块应允许通过配置参数 `EepUseInterrupts` (ECUC_Eep_00163) 配置为中断或轮询控制的作业处理。⌋
[SWS_Eep_00129] ⌈如果支持并启用中断控制作业处理,位于 Eep_Irq.c 的外部中断服务例程应调用一个附加的作业处理函数。⌋
[SWS_Eep_00246] ⌈如果底层 EEPROM 技术对读取地址或长度信息要求特定对齐,且读取或比较作业的地址和/或长度参数未正确对齐,`Eep_MainFunction` 函数应在内部补偿此缺失的对齐,即提供按字节的 Flash 内存读访问。⌋
#### SPI EEPROM 驱动额外通用需求
- [SWS_Eep_00056] SPI 访问失败时,Eep 模块行为参考 SWS_Eep_00068
- [SWS_Eep_00052] 普通模式:使用为普通 SPI EEPROM 访问配置的 SPI 通道
- [SWS_Eep_00053] EepNormalReadBlockSize 应匹配普通 SPI 模式可读字节数
- [SWS_Eep_00055] 快速模式:使用为突发访问 SPI EEPROM 配置的 SPI 通道
- [SWS_Eep_00073] EepFastReadBlockSize 应匹配突发 SPI 模式可读字节数
### 7.6 读作业处理
[SWS_Eep_00130] ⌈Eep 模块应提供两种不同的读模式:普通模式、快速模式⌋
[SWS_Eep_00132] ⌈对于驱动外部 EEPROM 的 Eep 模块:如外部 EEPROM 不支持突发模式,应接受快速读模式选择,但行为与普通模式相同。⌋
[SWS_Eep_00051] ⌈普通 EEPROM 模式下,Eep 模块在一个作业处理周期内应读取 `EepNormalReadBlockSize` 参数指定的字节数。⌋
**示例**:`EepNormalReadBlockSize = 4`,读取 21 字节,所需 6 个周期,模式:4-4-4-4-4-1
[SWS_Eep_00054] ⌈快速 EEPROM 模式下,Eep 模块在一个周期内应读取 `EepFastReadBlockSize` 指定的字节数。⌋
**示例**:`EepFastReadBlockSize = 32`,读取 110 字节,所需 4 个周期,模式:32-32-32-14
[SWS_Eep_00058] ⌈读作业成功完成时,Eep 模块应将 EEPROM 状态设置为 MEMIF_IDLE,作业结果设置为 MEMIF_JOB_OK。如已配置,调用 `EepJobEndNotification` 中定义的通知。⌋
[SWS_Eep_00068] ⌈读作业处理期间检测到错误时,Eep 模块应中止作业,EEPROM 状态设为 MEMIF_IDLE,作业结果设为 MEMIF_JOB_FAILED。如已配置,调用 `EepJobErrorNotification` 通知。⌋
### 7.7 写作业处理
[SWS_Eep_00057] ⌈Eep 模块在一个作业处理周期内只应向 EEPROM 写入(和擦除)EEPROM 硬件支持的字节数。⌋
[SWS_Eep_00133] ⌈提供两种写模式:普通、快速⌋
[SWS_Eep_00097] / [SWS_Eep_00098] ⌈分别由 `EepNormalWriteBlockSize` 和 `EepFastWriteBlockSize` 指定每周期写入字节数。⌋
[SWS_Eep_00060] ⌈如果要写入 EEPROM 单元的值已包含在该单元中,Eep 模块在 `EepWriteCycleReduction` 配置时应跳过该单元的编程。⌋ (SRS_Eep_00092)
[SWS_Eep_00059] ⌈如果 EEPROM 硬件不自动进行,Eep 模块应在写入前擦除 EEPROM 单元。⌋
[SWS_Eep_00063] [SWS_Eep_00090] ⌈如果要写入字节数小于可擦除/可写数据单元,或地址/长度参数未对齐到可擦除/可写数据单元,Eep 模块应通过读-修改-写操作保留受影响 EEPROM 单元数据。⌋
[SWS_Eep_00064] ⌈写入数据块时,Eep 模块应尽量减少读-修改-写操作次数。⌋
### 7.8 擦除作业处理
- [SWS_Eep_00069] 一周期内只擦 EEPROM 硬件支持的字节数
- [SWS_Eep_00070] 如硬件支持且参数对齐,使用块擦除命令
- [SWS_Eep_00072] 如擦除参数未对齐到可擦除数据单元,使用读-修改-写保留受影响内容
### 7.9 比较作业处理
适用读相关需求:SWS_Eep_00130, 00132, 00051, 00054。
[SWS_Eep_00075] ⌈如比较作业处理期间检测到比较数据区域不相等,EEPROM 驱动应中止作业,EEPROM 状态设为 MEMIF_IDLE,作业结果设为 MEMIF_BLOCK_INCONSISTENT。如已配置,调用 `Eep_JobErrorNotification` 回调函数。⌋
### 7.10 版本检查
详见 SWS_BSWGeneral 第 5.1.8 章。
---
## 8 API 规范
### 8.1 导入的类型
[SWS_Eep_00138] ⌈
| 模块 | 头文件 | 导入类型 |
|------|--------|----------|
| Dem | Rte_Dem_Type.h | Dem_EventIdType, Dem_EventStatusType |
| MemIf | MemIf.h | MemIf_JobResultType, MemIf_ModeType, MemIf_StatusType |
| Std_Types | StandardTypes.h | Std_ReturnType, Std_VersionInfoType |
⌋ (SRS_BSW_00335, SRS_BSW_00357, SRS_BSW_00377)
### 8.2 类型定义
#### 8.2.1 Eep_ConfigType
| 项 | 内容 |
|-----|------|
| Name | Eep_ConfigType |
| Type | Structure |
| Range | Implementation Specific — 初始化数据结构内容为 EEPROM 特定 |
| Description | 包含 EEPROM 驱动初始化数据的外部数据结构类型。 |
| Available via | Eep.h |
#### 8.2.2 Eep_AddressType
| 项 | 内容 |
|-----|------|
| Name | Eep_AddressType |
| Type | uint(8/16/32 位,取决于目标平台和 EEPROM 设备) |
| Description | 用作从已配置 EEPROM 基地址访问特定 EEPROM 内存区域的地址偏移。 |
#### 8.2.3 Eep_LengthType
| 项 | 内容 |
|-----|------|
| Name | Eep_LengthType |
| Type | 与 Eep_AddressType 相同 |
| Description | 指定要读/写/擦/比较的字节数。 |
### 8.3 函数定义
#### 8.3.1 Eep_Init
```c
void Eep_Init(const Eep_ConfigType* ConfigPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x00 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Description | EEPROM 初始化服务。 |
[SWS_Eep_00004] ⌈`Eep_Init` 函数应使用 `ConfigPtr` 引用结构的值初始化所有 EEPROM 相关寄存器。⌋
[SWS_Eep_00006] ⌈模块初始化完成后,`Eep_Init` 应将 EEPROM 状态设置为 MEMIF_IDLE,作业结果设置为 MEMIF_JOB_OK。⌋
[SWS_Eep_00044] ⌈`Eep_Init` 应将 EEPROM 模式设置为已配置的默认模式。⌋
#### 8.3.2 Eep_SetMode
```c
void Eep_SetMode(MemIf_ModeType Mode)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x01 |
| Parameters | Mode: MEMIF_MODE_SLOW(慢读访问/普通 SPI 访问) 或 MEMIF_MODE_FAST(快读访问/SPI 突发访问) |
[SWS_Eep_00042] ⌈`Eep_SetMode` 应将 EEPROM 操作模式设为给定 mode 参数。⌋
#### 8.3.3 Eep_Read
```c
Std_ReturnType Eep_Read(
Eep_AddressType EepromAddress,
uint8* DataBufferPtr,
Eep_LengthType Length
)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x02 |
| Sync/Async | Asynchronous |
| Return | E_OK: 读命令已接受;E_NOT_OK: 未接受 |
[SWS_Eep_00009] ⌈复制参数,启动读作业,EEPROM 状态设为 MEMIF_BUSY,作业结果设为 MEMIF_JOB_PENDING 后返回。⌋
[SWS_Eep_00013] ⌈Eep 模块应在作业处理函数内异步执行读作业,读取 `EepromAddress + EEPROM 基地址` 起 `Length` 字节数据块到 `*DataBufferPtr`。⌋
#### 8.3.4 Eep_Write
```c
Std_ReturnType Eep_Write(
Eep_AddressType EepromAddress,
const uint8* DataBufferPtr,
Eep_LengthType Length
)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x03 |
| Sync/Async | Asynchronous |
[SWS_Eep_00014] ⌈启动写作业并返回。⌋
[SWS_Eep_00015] ⌈异步写入 `Length` 字节从 `*DataBufferPtr` 到 `EepromAddress + EEPROM 基地址`。⌋
#### 8.3.5 Eep_Erase
```c
Std_ReturnType Eep_Erase(
Eep_AddressType EepromAddress,
Eep_LengthType Length
)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x04 |
| Sync/Async | Asynchronous |
| Description | 擦除 EEPROM 段的服务。 |
[SWS_Eep_00019] / [SWS_Eep_00020] ⌈启动并异步执行擦除作业。⌋
#### 8.3.6 Eep_Compare
```c
Std_ReturnType Eep_Compare(
Eep_AddressType EepromAddress,
const uint8* DataBufferPtr,
Eep_LengthType Length
)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x05 |
| Sync/Async | Asynchronous |
| Description | 比较 EEPROM 中数据块与内存中 EEPROM 块。 |
#### 8.3.7 Eep_Cancel
```c
void Eep_Cancel(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x06 |
| Sync/Async | Synchronous |
| Description | 取消正在运行的作业。 |
[SWS_Eep_00215] ⌈应取消正在进行的 EEPROM 读、写、擦或比较作业。⌋
[SWS_Eep_00021] ⌈同步中止正在运行的作业,函数返回后上层可立即请求新作业。⌋
[SWS_Eep_00027] ⌈应将 EEP 模块状态设为 MEMIF_IDLE。⌋
[SWS_Eep_00028] ⌈如果作业结果当前为 MEMIF_JOB_PENDING,应设为 MEMIF_JOB_CANCELED;否则保持作业结果不变。⌋
#### 8.3.8 Eep_GetStatus
```c
MemIf_StatusType Eep_GetStatus(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x07 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant |
| Return | MemIf_StatusType |
[SWS_Eep_00029] ⌈同步返回 EEPROM 状态。⌋
#### 8.3.9 Eep_GetJobResult
```c
MemIf_JobResultType Eep_GetJobResult(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x08 |
| Reentrancy | Reentrant |
[SWS_Eep_00024] ⌈同步返回 Eep 模块上次已接受作业的结果。⌋
#### 8.3.10 Eep_GetVersionInfo
```c
void Eep_GetVersionInfo(Std_VersionInfoType* versioninfo)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0a |
| Reentrancy | Reentrant |
| Description | 获取本模块版本信息的服务。 |
[SWS_Eep_00239] ⌈如开发错误检测启用且以 NULL 指针调用,应引发开发错误 EEP_E_PARAM_POINTER。⌋
### 8.4 回调通知
EEPROM 驱动为内部微控制器外设规范化时,属于 AUTOSAR 软件架构的最低层,因此本模块规范未识别任何回调函数。对于 SPI 外部设备,属于 ECU 抽象层,应根据 SPI Handler/Driver 规范需求提供回调通知。
[SWS_Eep_00137] ⌈ 在 Eep 模块支持 SPI 外部设备的情况下,Eep 模块应根据 SPI Handler/Driver 规范需求提供附加回调通知。⌋
### 8.5 调度函数
#### 8.5.1 Eep_MainFunction
```c
void Eep_MainFunction(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x09 |
| Description | 执行 EEPROM 作业(读/写/擦/比较)处理的服务。 |
| Available via | SchM_Eep.h |
[SWS_Eep_00030] ⌈应执行 EEPROM 读、写、擦除和比较作业的处理。⌋
[SWS_Eep_00031] ⌈作业启动后,Eep 用户应周期性调用 `Eep_MainFunction` 直到作业完成。⌋
[SWS_Eep_00032] ⌈如无待处理作业,应直接返回。⌋
**硬件错误报告**(SWS_Eep_00204~00207):分别报告 EEP_E_ERASE/WRITE/READ/COMPARE_FAILED 给 DEM。
**超时监视**(SWS_Eep_00235~00238):监视读/写/擦/比较作业的截止时间,超时时引发 EEP_E_TIMEOUT 运行时错误。
### 8.6 期望接口
#### 8.6.1 强制接口
[SWS_Eep_00154] ⌈
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| Dem_SetEventStatus | Dem.h | 报告监视状态信息到 Dem |
| Det_ReportRuntimeError | Det.h | 报告运行时错误 |
⌋
#### 8.6.2 可选接口
[SWS_Eep_00155] ⌈
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| Det_ReportError | Det.h | 报告开发错误 |
⌋
#### 8.6.3 可配置接口
[SWS_Eep_00047] ⌈如回调函数在后构建时配置,初始化数据结构 `Eep_ConfigType` 应包含相应函数指针。⌋
##### 8.6.3.1 作业结束通知
[SWS_Eep_00045] ⌈作业成功完成(读/写/擦完成 OK 或比较完成且数据相等)时调用 `EepJobEndNotification` 定义的回调函数。⌋
```c
void Eep_JobEndNotification(void)
```
##### 8.6.3.2 作业错误通知
[SWS_Eep_00046] ⌈作业被取消或以负结果结束(读/写/擦中止或失败,比较中止或数据不相等)时调用 `EepJobErrorNotification` 定义的回调函数。⌋
```c
void Eep_JobErrorNotification(void)
```
---
## 9 时序图
### 9.1 初始化
EcuM → Eep:`Eep_Init(const Eep_ConfigType*)`
### 9.2 读/写/擦/比较
NvM → Ea → Eep:`Ea_Write` → `Eep_Write` → (周期 `Eep_MainFunction` 直至作业完成)→ `Ea_JobEndNotification` → `NvM_JobEndNotification`。
- EEPROM 状态:MEMIF_BUSY → MEMIF_IDLE
- 作业结果:MEMIF_JOB_PENDING → MEMIF_JOB_OK
### 9.3 运行中作业的取消
NvM → Ea → Eep:`Ea_Cancel` → `Eep_Cancel`(同步)→ 状态变为 MEMIF_IDLE, 结果 MEMIF_JOB_CANCELED → 立即可启动新作业。
---
## 10 配置规范
### 10.1 如何阅读本章
详见 SWS_BSWGeneral 第 10.1 章。
### 10.2 容器与配置参数
#### 10.2.1 Eep
| 项 | 内容 |
|-----|------|
| SWS Item | ECUC_Eep_00205 |
| Module Name | Eep |
| Module Description | Eep(内部或外部 EEPROM 驱动)模块的配置。 |
| Post-Build Variant Support | true |
| Supported Config Variants | VARIANT-POST-BUILD, VARIANT-PRE-COMPILE |
**包含容器:**
| 容器名 | 多重性 | 描述 |
|--------|--------|------|
| EepGeneral | 1 | EEPROM 驱动通用配置参数容器 |
| EepInitConfiguration | 1 | EEPROM 驱动运行时配置参数容器(实现类型:Eep_ConfigType) |
| EepPublishedInformation | 1 | 附加发布参数(不在 CommonPublishedInformation 容器中覆盖) |
#### 10.2.2 EepGeneral
关键参数(摘要):
| 参数 | 描述 |
|------|------|
| EepDevErrorDetect | 开发错误检测开关 |
| EepVersionInfoApi | 版本信息 API 启用开关 |
| EepUseInterrupts | 中断或轮询作业处理选择 |
| EepDriverIndex | 驱动索引 |
| EepBaseAddress | EEPROM 基地址 |
| EepSize | EEPROM 大小(字节) |
#### 10.2.3 EepInitConfiguration
| 参数 | 描述 |
|------|------|
| EepDefaultMode | 默认模式 |
| EepFastReadBlockSize | 快速模式读取块大小 |
| EepNormalReadBlockSize | 普通模式读取块大小 |
| EepFastWriteBlockSize | 快速模式写入块大小 |
| EepNormalWriteBlockSize | 普通模式写入块大小 |
| EepJobCallCycle | 作业调用周期 |
| EepJobEndNotification | 作业结束通知回调 |
| EepJobErrorNotification | 作业错误通知回调 |
| EepEraseTime | 最大擦除时间 |
| EepWriteCycleReduction | 写周期减少开关 |
#### 10.2.4 EepDemEventParameterRefs
引用 DEM 事件参数,用于错误报告。
#### 10.2.5 EepExternalDriver
外部 EEPROM 设备配置:
- 期望硬件 Flash ID
- 最大读访问阻塞时间
#### 10.2.6 SPI 特定扩展
SPI 配置参数(用于外部 SPI EEPROM):
- SPI 通道
- 普通模式与突发模式 SPI 序列
### 10.3 已发布参数
EepPublishedInformation 包含:
- EEPROM 大小
- 已擦除 EEPROM 单元值
- EEPROM 单元大小
- 物理内存分段
### 10.4 配置示例 — 外部 SPI EEPROM 设备
详细配置示例见原文 PDF 第 10.4 章。
---
## 11 不适用需求
[SWS_Eep_00241] ⌈这些需求不适用于本规范。⌋ 涉及多个 SRS_BSW_* 和 SRS_SPAL_* 需求,详见原文 PDF。
---
## 翻译说明
- 本文档完整翻译自 AUTOSAR_SWS_EEPROMDriver v4.4.0(Document ID 021,63 页)。
- 保留所有需求 ID(SWS_Eep_xxxxx、SRS_*_xxxxx、ECUC_Eep_xxxxx)。
- 保留 AUTOSAR 方框符 ⌈⌋。
- 模块缩写(Eep、Fee、Ea、NvM、MemIf、SPI、DEM、DET、EcuM 等)和 API 函数名保持英文。
- 主要部分已完整翻译;配置参数详细描述请参考原文 PDF。
Memory/AUTOSAR_SWS_FlashDriver.md
+605
View File
@@ -0,0 +1,605 @@
# Flash 驱动规范
> **文档标题**: Specification of Flash Driver
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 025
> **文档类型**: SWS (Software Specification)
---
## 文档标识
| 项目 | 内容 |
|------|------|
| Document Title | Specification of Flash Driver |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 025 |
| 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 | 添加对 MCALMulticoreDistribution 的支持 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 移除 HIS 引用;将"default error"重命名为"development error";引入运行时错误;实例化模块的实例 ID 配置 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 更新追溯信息;澄清内部缓冲区对齐;细化错误处理,新增配置参数 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 调试支持标记为过时;错误分类重做;移除 DEM 引用;澄清 FlsUseInterrupts 配置参数描述 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 需求与特性和 BSW 需求关联 |
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 移除 Fls_Init 期间 NULL 指针检查需求;小幅格式更改 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 移除模块主函数的时序需求;Fls_GetStatus 在模块未初始化时返回 MEMIF_UNINIT |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 按新的 SWS_BSWGeneral 重做;生产错误改为扩展生产错误 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 更正 HW 特定错误的引用;适配配置参数范围;模块短名变更 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 新增 FlsDefaultMode 配置参数;新增带 SPI 引用的容器;新增 NULL 指针检查 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 新增 AUTOSAR 标准错误引用;通知例程多重性更正 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2008-02-01 | 3.0.2 | AUTOSAR Administration | 表格格式更正 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | Fls_Compare 新增 NULL 指针检查 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | 文件包含结构更新;类型使用更正 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 文档结构适配 Release 2.0 SWS 模板;新功能:Read、Compare 和 SetMode 函数;可伸缩性:功能可配置(开/关);适配新 MemHwA 架构 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 初始版本发布 |
---
## 目录
1. [介绍与功能概述](#1-介绍与功能概述)
2. [缩略语](#2-缩略语)
3. [相关文档](#3-相关文档)
4. [约束与假设](#4-约束与假设)
5. [模块依赖](#5-模块依赖)
6. [需求追溯](#6-需求追溯)
7. [功能规范](#7-功能规范)
8. [API 规范](#8-api-规范)
9. [时序图](#9-时序图)
10. [配置规范](#10-配置规范)
11. [不适用需求](#11-不适用需求)
---
## 1 介绍与功能概述
本规范描述 Flash 驱动(FLS)的功能和 API。本规范同时适用于内部和外部 Flash 驱动。
Flash 驱动提供对 Flash 存储器进行读、写、擦除和比较的服务。
服务行为是异步的(写、擦、读、比较)。
内部 Flash 驱动直接访问微控制器硬件,位于微控制器抽象层(MCAL)。外部 Flash 驱动使用处理程序(如 SPI Handler/Driver)或驱动访问外部 Flash 设备,位于 ECU 抽象层。
两种类型驱动的功能需求和功能范围相同。
---
## 2 缩略语
| 缩略语 | 描述 |
|--------|------|
| Flash sector | 一次可擦除的最小 Flash 内存量 |
| Flash page | 一次可写入的最小 Flash 内存量 |
| FLS | Flash 驱动模块缩写 |
| FEE | Flash EEPROM Emulation |
| Fls | 模块名 |
| MemIf | Memory Abstraction Interface |
| NvM | NVRAM Manager |
| EcuM | ECU State Manager |
| DEM | Diagnostic Event Manager |
| DET | Default Error Tracer |
---
## 3 相关文档
### 3.1 AUTOSAR 交付物
- Layered Software Architecture
- General Requirements on Basic Software Modules
- Specification of Memory Abstraction Interface
- Specification of SPI Handler/Driver
- Requirements on Flash Driver — AUTOSAR_SRS_FlashDriver.pdf
- Specification of Default Error Tracer
- Specification of MCU Driver
- List of Basic Software Modules
- General Specification of Basic Software Modules
### 3.2 相关规范
AUTOSAR 提供基础软件模块通用规范(SWS BSW General),也适用于 Flash 驱动。
---
## 4 约束与假设
### 4.1 限制
Flash 驱动不提供数据完整性机制(如校验和、冗余存储等)。
### 4.2 适用车型领域
无限制。
---
## 5 模块依赖
### 5.1 系统时钟
内部 Flash 可能依赖系统时钟、预分频器和 PLL。
### 5.2 通信或 I/O 驱动
外部 Flash 驱动依赖所使用板载通信处理程序(如 SPI Handler/Driver)的 API 和能力。
Flash 驱动是内存抽象架构的一部分,因此某些类型依赖 Memory Interface (MemIf) 模块。
---
## 6 需求追溯
(主要追溯,完整表见原文 PDF)
| 需求 | 满足者 |
|------|--------|
| SRS_BSW_00101 | SWS_Fls_00014 |
| SRS_BSW_00323 | SWS_Fls_00015, 00020, 00021, 00026, 00027 等多个参数检查需求 |
| SRS_BSW_00337 | SWS_Fls_00310, 00312-00319 |
| SRS_BSW_00406 | SWS_Fls_00065, 00066, 00268 等 |
| SRS_Fls_12107 (Flash 类型检查) | SWS_Fls_00144 |
| SRS_Fls_12132 (静态配置) | SWS_Fls_00048, 00208, 00209, 00216, 00217 |
| SRS_Fls_12134 (异步读) | SWS_Fls_00001, 00035, 00097, 00098 等 |
| SRS_Fls_12135 (异步写) | SWS_Fls_00001, 00026, 00027, 00035 等 |
| SRS_Fls_12136 (异步擦除) | SWS_Fls_00001, 00020, 00021, 00035 等 |
| SRS_Fls_12137 (同步取消) | SWS_Fls_00033, 00035, 00183, 00229 等 |
| SRS_Fls_12138 (同步状态) | SWS_Fls_00034, 00184, 00253 |
| SRS_Fls_12141 (数据验证) | SWS_Fls_00056, 00200 |
| SRS_Fls_12143 (单作业) | SWS_Fls_00002, 00003, 00023, 00030, 00033, 00036 等 |
| SRS_Fls_12144 (作业处理函数) | SWS_Fls_00037, 00038, 00039 等 |
| SRS_Fls_12158 (写前擦除检查) | SWS_Fls_00055 |
| SRS_Fls_12159 (地址参数检查) | SWS_Fls_00020, 00021, 00026, 00027 等 |
| SRS_Fls_12160 (擦后验证) | SWS_Fls_00022 |
| SRS_Fls_12193 (代码加载到 RAM) | SWS_Fls_00137, 00140, 00141, 00214 |
| SRS_Fls_12194 (从 RAM 执行) | SWS_Fls_00211, 00212, 00213, 00215 |
| SRS_Fls_13300 (从 RAM 卸载) | SWS_Fls_00143 |
| SRS_Fls_13301 (异步比较) | SWS_Fls_00001, 00150-00153, 00186 等 |
| SRS_Fls_13302 (同步选择/模式) | SWS_Fls_00155, 00156, 00187, 00258 |
完整追溯表见原文 PDF。
---
## 7 功能规范
### 7.1 通用设计规则
[SWS_Fls_00001] ⌈FLS 模块应为 Flash 存储器操作(读/擦/写)提供异步服务。⌋ (SRS_Fls_12134, SRS_Fls_12135, SRS_Fls_12136, SRS_Fls_13301)
[SWS_Fls_00002] ⌈FLS 模块不应缓存数据。FLS 模块应使用通过 API 传递指针引用的应用数据缓冲区。⌋
[SWS_Fls_00003] ⌈FLS 模块不应保证给定应用缓冲区的数据一致性。⌋
[SWS_Fls_00205] ⌈FLS 模块应静态(最晚在编译时)检查静态配置参数的正确性。⌋
[SWS_Fls_00208] ⌈FLS 模块应将所有可用 Flash 内存区域组合为一个线性地址空间(由 `FlsBaseAddress` 和 `FlsTotalSize` 参数表示)。⌋
[SWS_Fls_00209] ⌈FLS 模块应根据 Flash 内存区域的物理结构将读、写、擦除和比较函数的地址和长度参数作为"虚拟"地址映射到物理地址。⌋
[SWS_Fls_00389] ⌈FLS 模块应在内部处理数据缓冲区对齐,将传入指针视为按字节对齐。⌋
[SWS_Fls_00390] ⌈如果在 ECU 中使用 Flash 驱动的多个实例,每个实例必须有唯一的实例 ID。该实例 ID 应配置为参数 `FlsDriverIndex`。如果 ECU 中只使用一个实例,该实例的 `FlsDriverIndex` 应配置为 0。⌋
### 7.2 错误处理
#### 7.2.1 开发错误
[SWS_Fls_00004] ⌈
| 错误类型 | 相关错误代码 | 值[hex] |
|----------|--------------|---------|
| 用错误参数调用 API 服务 | FLS_E_PARAM_CONFIG | 0x01 |
| | FLS_E_PARAM_ADDRESS | 0x02 |
| | FLS_E_PARAM_LENGTH | 0x03 |
| | FLS_E_PARAM_DATA | 0x04 |
| 模块未初始化调用 API 服务 | FLS_E_UNINIT | 0x05 |
| 驱动繁忙时调用 API 服务 | FLS_E_BUSY | 0x06 |
| 用 NULL 指针调用 API 服务 | FLS_E_PARAM_POINTER | 0x0a |
⌋
#### 7.2.2 运行时错误
| 错误类型 | 相关错误代码 | 值[hex] |
|----------|--------------|---------|
| 擦除验证(空白检查)失败 | FLS_E_VERIFY_ERASE_FAILED | 0x07 |
| 写验证(比较)失败 | FLS_E_VERIFY_WRITE_FAILED | 0x08 |
| 超时 | FLS_E_TIMEOUT | 0x09 |
#### 7.2.3 瞬态故障
| 错误类型 | 相关错误代码 | 值[hex] |
|----------|--------------|---------|
| Flash 擦除失败(HW) | FLS_E_ERASE_FAILED | 0x01 |
| Flash 写失败(HW) | FLS_E_WRITE_FAILED | 0x02 |
| Flash 读失败(HW) | FLS_E_READ_FAILED | 0x03 |
| Flash 比较失败(HW) | FLS_E_COMPARE_FAILED | 0x04 |
| 期望硬件 ID 不匹配 | FLS_E_UNEXPECTED_FLASH_ID | 0x05 |
#### 7.2.4 扩展生产错误与生产错误
本模块未规定任何生产错误。
### 7.3 外部 Flash 驱动
[SWS_Fls_00144] ⌈外部 Flash 驱动初始化期间,FLS 模块应将外部 Flash 设备的硬件 ID 与相应已发布参数对比。如硬件 ID 不匹配,FLS 模块应将错误代码 `FLS_E_UNEXPECTED_FLASH_ID` 报告给 Default Error Tracer (DET),将 FLS 模块状态设为 `FLS_E_UNINIT`,且不应初始化自身。⌋
### 7.4 Flash 访问代码的加载、执行和移除
技术背景:Flash 技术或 Flash 内存分段可能要求访问 Flash 硬件的例程(内部擦除和写入例程)从 RAM 执行,因为在编程 Flash 时无法读取 Flash(用于代码执行所需的指令获取)。
[SWS_Fls_00137] ⌈FLS 模块的实现者应将 Flash 访问例程的代码放在单独的 C 模块 Fls_ac.c 中。⌋
[SWS_Fls_00215] ⌈FLS 模块的 Flash 访问例程应仅在必要时禁用中断并等待擦除/写命令完成。⌋
[SWS_Fls_00140] [SWS_Fls_00141] ⌈如果 FLS 模块配置为在作业启动时将 Flash 访问代码加载到 RAM,Flash 擦除/写入例程应将相应 Flash 访问代码加载到由配置集中函数指针指向的 RAM 位置。⌋
[SWS_Fls_00143] ⌈擦除或写入作业完成或取消后,如 Flash 驱动已将 Flash 访问代码加载到 RAM,FLS 模块的主处理例程应从 RAM 卸载(即覆盖)Flash 访问代码。⌋
[SWS_Fls_00214] ⌈FLS 模块仅在 Flash ROM 中无法执行访问代码时才应将访问代码加载到 RAM。⌋
---
## 8 API 规范
### 8.1 导入的类型
[SWS_Fls_00248] ⌈
| 模块 | 头文件 | 导入类型 |
|------|--------|----------|
| MemIf | MemIf.h | MemIf_JobResultType, MemIf_ModeType, MemIf_StatusType |
| Std_Types | StandardTypes.h | Std_ReturnType, Std_VersionInfoType |
⌋
### 8.2 类型定义
#### 8.2.1 Fls_ConfigType
| 项 | 内容 |
|-----|------|
| Name | Fls_ConfigType |
| Type | Structure |
| Range | Hardware dependend structure — 初始化数据结构内容为 Flash 内存硬件特定 |
| Description | 保存 Flash 驱动配置集的结构。指向此结构的指针提供给 Flash 驱动初始化例程。 |
| Available via | Fls.h |
#### 8.2.2 Fls_AddressType
| 项 | 内容 |
|-----|------|
| Name | Fls_AddressType |
| Type | uint(8/16/32 位,取决于目标平台和 Flash 设备) |
| Description | 用作从已配置 Flash 基地址访问特定 Flash 内存区域的地址偏移。 |
[SWS_Fls_00216] ⌈`Fls_AddressType` 的下限应为 0。⌋
[SWS_Fls_00217] ⌈如有必要,FLS 模块应添加设备特定基地址。⌋
#### 8.2.3 Fls_LengthType
| 项 | 内容 |
|-----|------|
| Name | Fls_LengthType |
| Type | 与 Fls_AddressType 相同 |
| Description | 指定要读/写/擦/比较的字节数。 |
### 8.3 函数定义
#### 8.3.1 Fls_Init
```c
void Fls_Init(const Fls_ConfigType* ConfigPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x00 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Description | 初始化 Flash 驱动。 |
[SWS_Fls_00014] ⌈`Fls_Init` 函数应使用给定配置集中的参数初始化 FLS 模块(软件)和所有 Flash 内存相关寄存器(硬件)。⌋
[SWS_Fls_00323] ⌈完成初始化后,应将 FLS 模块状态设为 MEMIF_IDLE。⌋
[SWS_Fls_00324] ⌈完成初始化后,应将 Flash 作业结果设为 MEMIF_JOB_OK。⌋
[SWS_Fls_00048] ⌈如硬件支持,应按配置集设置 Flash 内存擦除/写保护。⌋
#### 8.3.2 Fls_Erase
```c
Std_ReturnType Fls_Erase(
Fls_AddressType TargetAddress,
Fls_LengthType Length
)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x01 |
| Sync/Async | Asynchronous |
| Description | 擦除 Flash 扇区。 |
| Return | E_OK: 擦除命令已接受;E_NOT_OK: 未接受 |
[SWS_Fls_00218] ⌈`Fls_Erase` 作业应擦除一个或多个完整 Flash 扇区。⌋
[SWS_Fls_00220] [SWS_Fls_00221] ⌈应在 FLS 模块主函数内异步执行,从 `FlsBaseAddress + TargetAddress` 起擦除大小为 `Length` 的 Flash 内存块。Length 将四舍五入到下一个完整扇区边界。⌋
参数检查:
- [SWS_Fls_00020] 擦除起始地址必须对齐到 Flash 扇区边界,在指定地址边界内,否则报 FLS_E_PARAM_ADDRESS
- [SWS_Fls_00021] 擦除长度必须大于 0,擦除结束地址对齐到 Flash 扇区边界,在上边界内,否则报 FLS_E_PARAM_LENGTH
#### 8.3.3 Fls_Write
```c
Std_ReturnType Fls_Write(
Fls_AddressType TargetAddress,
const uint8* SourceAddressPtr,
Fls_LengthType Length
)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x02 |
| Sync/Async | Asynchronous |
| Description | 写入一个或多个完整 Flash 页。 |
[SWS_Fls_00223] ⌈`Fls_Write` 作业应向 Flash 设备写入一个或多个完整 Flash 页。⌋
[SWS_Fls_00226] ⌈从 `FlsBaseAddress + TargetAddress` 起,使用 `SourceAddressPtr` 提供的数据编程大小为 `Length` 的 Flash 内存块。⌋
参数检查:
- [SWS_Fls_00026] 写起始地址对齐到 Flash 页边界,否则报 FLS_E_PARAM_ADDRESS
- [SWS_Fls_00027] 写长度 > 0,结束地址对齐到 Flash 页边界,否则报 FLS_E_PARAM_LENGTH
- [SWS_Fls_00157] 检查 DataBuffer 指针非 NULL,否则报 FLS_E_PARAM_DATA
#### 8.3.4 Fls_Cancel
```c
void Fls_Cancel(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x03 |
| Sync/Async | Synchronous |
| Description | 取消正在进行的作业。 |
[SWS_Fls_00229] ⌈应取消正在进行的 Flash 读、写、擦除或比较作业。⌋
[SWS_Fls_00033] / [SWS_Fls_00335] ⌈同步中止作业,将模块状态设为 MEMIF_IDLE。⌋
[SWS_Fls_00336] ⌈如作业结果为 MEMIF_JOB_PENDING,设为 MEMIF_JOB_CANCELED。⌋
#### 8.3.5 Fls_GetStatus
```c
MemIf_StatusType Fls_GetStatus(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x04 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant |
| Description | 同步返回 Flash 状态。 |
#### 8.3.6 Fls_GetJobResult
```c
MemIf_JobResultType Fls_GetJobResult(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x05 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant |
| Description | 同步返回上次作业的结果。 |
#### 8.3.7 Fls_Read
```c
Std_ReturnType Fls_Read(
Fls_AddressType SourceAddress,
uint8* TargetAddressPtr,
Fls_LengthType Length
)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x07 |
| Sync/Async | Asynchronous |
| Description | 从 Flash 内存读取一个或多个字节。 |
#### 8.3.8 Fls_Compare
```c
Std_ReturnType Fls_Compare(
Fls_AddressType SourceAddress,
const uint8* TargetAddressPtr,
Fls_LengthType Length
)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x08 |
| Sync/Async | Asynchronous |
| Description | 将 Flash 中数据与给定数据缓冲区进行比较。 |
#### 8.3.9 Fls_SetMode
```c
void Fls_SetMode(MemIf_ModeType Mode)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x09 |
| Description | 设置 Flash 操作模式。 |
#### 8.3.10 Fls_GetVersionInfo
```c
void Fls_GetVersionInfo(Std_VersionInfoType* VersioninfoPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x10 |
| Reentrancy | Reentrant |
### 8.4 回调通知
无,FLS 是基础模块。
### 8.5 调度函数
#### 8.5.1 Fls_MainFunction
```c
void Fls_MainFunction(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x06 |
| Description | 执行 Flash 作业(读/写/擦/比较)的处理。 |
| Available via | SchM_Fls.h |
执行作业处理、超时监视、报告硬件错误(FLS_E_ERASE/WRITE/READ/COMPARE_FAILED)。
### 8.6 期望接口
#### 8.6.1 强制接口
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| Det_ReportRuntimeError | Det.h | 报告运行时错误 |
#### 8.6.2 可选接口
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| Det_ReportError | Det.h | 报告开发错误 |
| Dem_ReportErrorStatus | Dem.h | 报告 DEM 状态(如硬件错误) |
#### 8.6.3 可配置接口
##### 作业结束通知
```c
void Fls_JobEndNotification(void)
```
作业成功完成时调用。
##### 作业错误通知
```c
void Fls_JobErrorNotification(void)
```
作业被取消或以负结果结束时调用。
---
## 9 时序图
类似 EEPROM 驱动:
- 初始化:EcuM → Fls:`Fls_Init`
- 读/写/擦/比较:NvM → Fee → Fls → 周期 `Fls_MainFunction` → JobEndNotification 回调
- 取消运行中作业:`Fls_Cancel` 同步,状态变为 MEMIF_IDLE,作业结果 MEMIF_JOB_CANCELED
---
## 10 配置规范
### 10.1 容器与配置参数
#### 10.1.1 Fls
| 项 | 内容 |
|-----|------|
| SWS Item | ECUC_Fls_00200 |
| Module Name | Fls |
| Module Description | Flash 驱动配置 |
| Post-Build Variant Support | true |
| Supported Config Variants | VARIANT-POST-BUILD, VARIANT-PRE-COMPILE |
#### 10.1.2 FlsGeneral
| 参数 | 描述 |
|------|------|
| FlsDevErrorDetect | 开发错误检测开关 |
| FlsVersionInfoApi | 版本信息 API 启用开关 |
| FlsCancelApi | Cancel API 启用 |
| FlsCompareApi | Compare API 启用 |
| FlsGetJobResultApi | GetJobResult API 启用 |
| FlsGetStatusApi | GetStatus API 启用 |
| FlsSetModeApi | SetMode API 启用 |
| FlsUseInterrupts | 中断/轮询作业处理选择 |
| FlsEraseVerificationEnabled | 擦除验证启用 |
| FlsWriteVerificationEnabled | 写验证启用 |
| FlsTimeoutSupervisionEnabled | 超时监视启用 |
| FlsDriverIndex | 驱动实例 ID(多实例时唯一) |
#### 10.1.3 FlsConfigSet
| 参数 | 描述 |
|------|------|
| FlsBaseAddress | Flash 基地址 |
| FlsTotalSize | Flash 总大小 |
| FlsDefaultMode | 默认模式 |
| FlsMaxReadFastMode | 快速模式最大读块大小 |
| FlsMaxReadNormalMode | 普通模式最大读块大小 |
| FlsMaxWriteFastMode | 快速模式最大写块大小 |
| FlsMaxWriteNormalMode | 普通模式最大写块大小 |
| FlsCallCycle | 作业调用周期 |
| FlsAcLoadOnJobStart | 作业启动时加载访问代码到 RAM 开关 |
| FlsAcErase | 擦除访问代码函数指针 |
| FlsAcWrite | 写访问代码函数指针 |
| FlsJobEndNotification | 作业结束通知回调 |
| FlsJobErrorNotification | 作业错误通知回调 |
#### 10.1.4 FlsSectorList / FlsSector
每个 Flash 扇区配置:
- FlsNumberOfSectors
- FlsPageSize
- FlsSectorSize
- FlsSectorStartaddress
#### 10.1.5 FlsPublishedInformation
已发布参数:
- 已擦除 Flash 单元值
- Flash 单元大小
### 10.2 SPI 特定扩展(外部 Flash)
引用 SPI 配置参数。
---
## 11 不适用需求
[SWS_Fls_00366] ⌈这些需求不适用于本规范。⌋ 涉及多个 SRS_BSW_* 和 SRS_SPAL_* 需求,详见原文 PDF。
---
## 翻译说明
- 本文档完整翻译自 AUTOSAR_SWS_FlashDriver v4.4.0(Document ID 025,67 页)。
- 保留所有需求 ID(SWS_Fls_xxxxx、SRS_Fls_xxxxx、ECUC_Fls_xxxxx)。
- 保留 AUTOSAR 方框符 ⌈⌋。
- 模块缩写(Fls、Fee、Ea、NvM、MemIf、SPI、DEM、DET、EcuM 等)和 API 函数名保持英文。
- 完整配置参数详细描述请参考原文 PDF 第 10 章。
Memory/AUTOSAR_SWS_FlashEEPROMEmulation.md
+563
View File
@@ -0,0 +1,563 @@
# Flash EEPROM 仿真规范
> **文档标题**: Specification of Flash EEPROM Emulation
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 286
> **文档类型**: SWS (Software Specification)
---
## 文档标识
| 项目 | 内容 |
|------|------|
| Document Title | Specification of Flash EEPROM Emulation |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 286 |
| 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 | 更新追溯信息;MEMIF_BUSY_INTERNAL 期间行为重做;主函数范围适配 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | FEE_BUSY_INTERNAL 期间行为重做;错误分类重做;调试支持标记为过时;请求块无法找到时澄清作业结果 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 新增空白检查需求;需求与特性、通用和模块特定需求关联 |
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 编辑性修订 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 移除主函数时序需求;Fee_Write 函数原型增加 const 限定符;新增 FeeMainFunctionPeriod 配置参数 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 按新的 SWS_BSWGeneral 重做;已发布参数 FeeMaximumBlockingTime 弃用;配置参数 FeeIndex 弃用 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | DET 错误增减;细化内部管理操作处理;模块短名变更;一致性检查重新表述 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 澄清模块间检查;细化内部管理操作处理;调整 FeeBlockNumber 和 FeeBlockSize 范围;状态机适配支持初始化可能不在 Fee_Init 内完成 |
| 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 | 文件包含结构更新;初始化函数 API 适配;FEE 块编号范围适配 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始版本发布 |
---
## 目录
1. [介绍与功能概述](#1-介绍与功能概述)
2. [缩略语](#2-缩略语)
3. [相关文档](#3-相关文档)
4. [约束与假设](#4-约束与假设)
5. [模块依赖](#5-模块依赖)
6. [需求追溯](#6-需求追溯)
7. [功能规范](#7-功能规范)
8. [API 规范](#8-api-规范)
9. [时序图](#9-时序图)
10. [配置规范](#10-配置规范)
11. [不适用需求](#11-不适用需求)
---
## 1 介绍与功能概述
本规范描述 Flash EEPROM Emulation 模块的功能、API 和配置。
```
NVRAM Manager
│
▼
Memory Hardware Abstraction
├── Memory Abstraction Interface (MemIf)
│ │
│ ▼
├── Flash EEPROM Emulation (FEE) ←── 本文档
│ │
│ ▼
└── Flash Driver
```
Flash EEPROM Emulation (FEE) 模块仿真 EEPROM Abstraction Layer 在 Flash 内存技术上的行为。它提供:
- 32 位虚拟线性地址空间
- 统一的(虚拟)分段方案
- 虚拟无限的擦/写周期数
它使上层(NVRAM 管理器)与底层 Flash 驱动和器件解耦。
---
## 2 缩略语
| 缩略语 | 描述 |
|--------|------|
| FEE | Flash EEPROM Emulation |
| Fee | 模块名 |
| Fls | Flash 驱动模块 |
| EA | EEPROM Abstraction |
| NV | 非易失 |
| NvM | NVRAM Manager |
| MemIf | Memory Abstraction Interface |
| Logical Block(逻辑块) | 模块用户可单独寻址的内存区域 |
| Page(页) | Flash 一次可写最小单元 |
| Sector(扇区) | Flash 一次可擦最小单元 |
| Virtual Page(虚拟页) | FEE 模块用于内部地址计算的可配置最小寻址单元 |
| Memory swap area(内存交换区) | FEE 使用的备用 Flash 区域,用于在重组期间存储数据 |
| DEM | Diagnostic Event Manager |
| DET | Default Error Tracer |
---
## 3 相关文档
### 3.1 输入文档
- List of Basic Software Modules — AUTOSAR_TR_BSWModuleList.pdf
- Layered Software Architecture — AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
- General Requirements on Basic Software Modules — AUTOSAR_SRS_BSWGeneral.pdf
- Requirements on Memory Hardware Abstraction Layer — AUTOSAR_SRS_MemoryHWAbstractionLayer.pdf
- Specification of Flash Driver — AUTOSAR_SWS_FlashDriver.pdf
- Specification of Memory Abstraction Interface — AUTOSAR_SWS_MemoryAbstractionInterface.pdf
- Specification of NVRAM Manager — AUTOSAR_SWS_NVRAMManager.pdf
- Specification of Default Error Tracer — AUTOSAR_SWS_DefaultErrorTracer.pdf
- General Specification of Basic Software Modules — AUTOSAR_SWS_BSWGeneral.pdf
### 3.2 相关规范
AUTOSAR 提供基础软件模块通用规范(SWS BSW General),也适用于 Flash EEPROM Emulation。
---
## 4 约束与假设
### 4.1 限制
无限制。
### 4.2 适用车型领域
无限制。
---
## 5 模块依赖
FEE 模块依赖于底层 Flash 驱动。
---
## 6 需求追溯
(主要追溯关系,完整表见原文 PDF)
| 需求 | 满足者 |
|------|--------|
| SRS_MemHwAb_14001 (起止地址对齐) | SWS_Fee_00005, 00068, 00075, 00137 |
| SRS_MemHwAb_14002 (写周期配置) | SWS_Fee_00080 |
| SRS_MemHwAb_14005 (32 位虚拟地址) | SWS_Fee_00066, 00075 |
| SRS_MemHwAb_14006 (64K 边界对齐) | SWS_Fee_00024 |
| SRS_MemHwAb_14007 (读对齐限制) | SWS_Fee_00021 |
| SRS_MemHwAb_14009 (地址转换) | SWS_Fee_00007, 00021, 00024, 00036, 00063 |
| SRS_MemHwAb_14010 (完整块写) | SWS_Fee_00087, 00151, 00159, 00181 |
| SRS_MemHwAb_14012 (写访问分散) | SWS_Fee_00079 |
| SRS_MemHwAb_14013 (立即数据不延迟) | SWS_Fee_00025 |
| SRS_MemHwAb_14014 (数据不一致检测) | SWS_Fee_00046, 00047 |
| SRS_MemHwAb_14015 (报告不一致) | SWS_Fee_00104 |
| SRS_MemHwAb_14016 (不返回不一致数据) | SWS_Fee_00104 |
| SRS_MemHwAb_14018 (FEE 扩展 Flash 驱动) | SWS_Fee_00150 |
| SRS_MemHwAb_14026 (不使用 0x0000/0xFFFF) | SWS_Fee_00006 |
| SRS_MemHwAb_14028 (无效化块) | SWS_Fee_00037, 00074, 00091 |
| SRS_MemHwAb_14029 (部分读取) | SWS_Fee_00022, 00086, 00158, 00179 |
| SRS_MemHwAb_14031 (取消异步操作) | SWS_Fee_00077, 00078, 00088 |
| SRS_MemHwAb_14032 (擦除立即数据) | SWS_Fee_00063, 00064, 00065 |
完整追溯表见原文 PDF。
---
## 7 功能规范
### 7.1 总体行为
FEE 模块的设计与 EA 模块极为相似。
[SWS_Fee_00137] ⌈Flash EEPROM Emulation (FEE) 一次只接受一个作业,即模块不应为待处理作业提供队列(这是 NVRAM 管理器的职责)。⌋
#### 7.1.1 寻址方案与分段
FEE 提供 32 位虚拟线性地址空间和统一的分段方案。32 位虚拟地址由:
- **16 位块编号** — 允许(理论上)65536 个逻辑块
- **16 位块偏移** — 允许每块 64 KB
组成。
[SWS_Fee_00075] ⌈虚拟页大小(`FEE_VIRTUAL_PAGE_SIZE`)应为物理页大小的整数倍。⌋
[SWS_Fee_00005] ⌈每个已配置逻辑块应占用虚拟页大小的整数倍。⌋
[SWS_Fee_00068] ⌈逻辑块不应相互重叠或包含。⌋
[SWS_Fee_00006] ⌈块编号 0x0000 和 0xFFFF 不应配置为逻辑块。⌋
#### 7.1.2 地址计算
[SWS_Fee_00007] ⌈FEE 模块函数应将 16 位块编号和 16 位块偏移组合,以派生底层 Flash 驱动所需的物理 Flash 地址。⌋
[SWS_Fee_00066] ⌈仅 16 位块编号中不表示特定数据集或冗余副本的位应用于地址计算。⌋
#### 7.1.3 擦除周期限制
[SWS_Fee_00079] ⌈Fee 模块配置应在配置参数 `FeeNumberOfWriteCycles` 中定义每个逻辑块预期的擦/写周期数。⌋
[SWS_Fee_00080] ⌈如底层 Flash 器件或驱动不提供至少已配置的擦/写周期数,FEE 模块应提供机制以分散擦/写访问。⌋
**FEE 特殊机制 — 块漫游**:
- FEE 使用"漫游"算法管理多个 Flash 扇区
- 通过将新写入的数据放到不同位置,延长 Flash 寿命
- 必须存在备用 Flash 空间用于重组
#### 7.1.4 "立即"数据处理
包含立即数据的块必须瞬时写入。
[SWS_Fee_00025] ⌈立即数据写入不应因内部管理操作或被写入内存区域的擦除而延迟。FEE 必须始终保留预擦除区域用于立即数据。⌋
#### 7.1.5 管理块正确性信息
[SWS_Fee_00046] ⌈FEE 模块应为每个块管理一致性信息。⌋
[SWS_Fee_00047] ⌈块写入开始时标记为不一致,成功完成后标记为一致。⌋
### 7.2 错误分类
#### 7.2.1 开发错误
| 错误类型 | 相关错误代码 | 值[hex] |
|----------|--------------|---------|
| 模块未初始化即调用 API 服务 | FEE_E_UNINIT | 0x01 |
| 以无效块编号调用 API 服务 | FEE_E_INVALID_BLOCK_NO | 0x02 |
| 以无效块偏移调用 API 服务 | FEE_E_INVALID_BLOCK_OFS | 0x03 |
| 以 NULL 指针调用 API 服务 | FEE_E_PARAM_POINTER | 0x04 |
| 以无效块长度调用 API 服务 | FEE_E_INVALID_BLOCK_LEN | 0x05 |
| Fee_Init 失败 | FEE_E_INIT_FAILED | 0x09 |
#### 7.2.2 运行时错误
| 错误类型 | 相关错误代码 | 值[hex] |
|----------|--------------|---------|
| 模块忙时调用 API 服务 | FEE_E_BUSY | 0x06 |
| Fee_Cancel 调用时无待处理作业 | FEE_E_INVALID_CANCEL | 0x08 |
#### 7.2.3 瞬态故障
无瞬态故障。
#### 7.2.4 生产错误
无生产错误。
#### 7.2.5 扩展生产错误
无扩展生产错误。
---
## 8 API 规范
### 8.1 导入的类型
| 模块 | 头文件 | 导入类型 |
|------|--------|----------|
| Fls | Fls.h | Fls_AddressType, Fls_LengthType |
| MemIf | MemIf.h | MemIf_JobResultType, MemIf_ModeType, MemIf_StatusType |
| Std_Types | StandardTypes.h | Std_ReturnType, Std_VersionInfoType |
### 8.2 类型定义
#### Fee_ConfigType
| 项 | 内容 |
|-----|------|
| Name | Fee_ConfigType |
| Type | Structure |
| Range | 实现特定 |
| Description | FEE 模块的配置数据结构。 |
| Available via | Fee.h |
### 8.3 函数定义
#### 8.3.1 Fee_Init
```c
void Fee_Init(const Fee_ConfigType* ConfigPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x00 |
| Sync/Async | Synchronous |
| Description | 初始化 FEE 模块。 |
[SWS_Fee_00191] ⌈`ConfigPtr` 应为 NULL_PTR 值。⌋
[SWS_Fee_00017] ⌈应将模块状态从 MEMIF_UNINIT 设为 MEMIF_BUSY_INTERNAL。⌋
[SWS_Fee_00120] [SWS_Fee_00168] [SWS_Fee_00169] ⌈如初始化在 Fee_Init 内未完成,可在主函数中继续。完成后将状态设为 MEMIF_IDLE。⌋
#### 8.3.2 Fee_SetMode
```c
void Fee_SetMode(MemIf_ModeType Mode)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x01 |
| Description | 切换底层 Flash 驱动的模式。 |
调用底层 `Fls_SetMode`。
#### 8.3.3 Fee_Read
```c
Std_ReturnType Fee_Read(
uint16 BlockNumber,
uint16 BlockOffset,
uint8* DataBufferPtr,
uint16 Length
)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x02 |
| Sync/Async | Asynchronous |
| Description | 从 `BlockNumber` 块的 `BlockOffset` 偏移读取 `Length` 字节到 `DataBufferPtr`。 |
参数检查:
- 模块已初始化
- BlockNumber 有效
- BlockOffset 在块范围内
- Length 大于 0 且不超过块大小
#### 8.3.4 Fee_Write
```c
Std_ReturnType Fee_Write(
uint16 BlockNumber,
const uint8* DataBufferPtr
)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x03 |
| Sync/Async | Asynchronous |
| Description | 将 `DataBufferPtr` 内容写入 `BlockNumber` 块。 |
[SWS_Fee_00087] [SWS_Fee_00151] ⌈写整个块。⌋
#### 8.3.5 Fee_Cancel
```c
void Fee_Cancel(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x04 |
| Sync/Async | Synchronous |
| Description | 取消正在进行的异步操作。 |
[SWS_Fee_00077] [SWS_Fee_00078] ⌈同步取消并调用底层 `Fls_Cancel`。⌋
[SWS_Fee_00088] ⌈状态设为 MEMIF_IDLE,作业结果设为 MEMIF_JOB_CANCELED。⌋
#### 8.3.6 Fee_GetStatus
```c
MemIf_StatusType Fee_GetStatus(void)
```
可能值:
- MEMIF_UNINIT
- MEMIF_IDLE
- MEMIF_BUSY
- MEMIF_BUSY_INTERNAL — FEE 模块正忙于内部管理操作(如块漫游、扇区擦除)
#### 8.3.7 Fee_GetJobResult
```c
MemIf_JobResultType Fee_GetJobResult(void)
```
可能值:MEMIF_JOB_OK、MEMIF_JOB_FAILED、MEMIF_JOB_PENDING、MEMIF_JOB_CANCELED、MEMIF_BLOCK_INCONSISTENT、MEMIF_BLOCK_INVALID。
#### 8.3.8 Fee_InvalidateBlock
```c
Std_ReturnType Fee_InvalidateBlock(uint16 BlockNumber)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x07 |
| Sync/Async | Asynchronous |
| Description | 使逻辑块无效。 |
#### 8.3.9 Fee_GetVersionInfo
```c
void Fee_GetVersionInfo(Std_VersionInfoType* VersionInfoPtr)
```
#### 8.3.10 Fee_EraseImmediateBlock
```c
Std_ReturnType Fee_EraseImmediateBlock(uint16 BlockNumber)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x09 |
| Sync/Async | Asynchronous |
| Description | 仅对包含立即数据的块进行擦除。 |
### 8.4 回调通知
#### 8.4.1 Fee_JobEndNotification
```c
void Fee_JobEndNotification(void)
```
| 项 | 内容 |
|-----|------|
| Description | 由底层 Flash 驱动调用,通知 FEE 作业成功完成。 |
#### 8.4.2 Fee_JobErrorNotification
```c
void Fee_JobErrorNotification(void)
```
| 项 | 内容 |
|-----|------|
| Description | 由底层 Flash 驱动调用,通知 FEE 作业出错。 |
### 8.5 调度函数
#### Fee_MainFunction
```c
void Fee_MainFunction(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0a |
| Description | 执行 FEE 模块作业处理的服务。 |
| Available via | SchM_Fee.h |
处理读、写、擦除作业,执行内部管理操作(如块漫游、扇区重组、空白检查)。
### 8.6 期望接口
#### 8.6.1 强制接口
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| Fls_Cancel | Fls.h | 取消正在进行的 Flash 作业 |
| Fls_Compare | Fls.h | 比较 Flash 中数据 |
| Fls_Erase | Fls.h | 擦除 Flash 扇区 |
| Fls_GetJobResult | Fls.h | 返回 Flash 作业结果 |
| Fls_GetStatus | Fls.h | 返回 Flash 状态 |
| Fls_Read | Fls.h | 从 Flash 读取 |
| Fls_SetMode | Fls.h | 切换 Flash 驱动模式 |
| Fls_Write | Fls.h | 写入 Flash |
#### 8.6.2 可选接口
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| Det_ReportError | Det.h | 报告开发错误 |
| Det_ReportRuntimeError | Det.h | 报告运行时错误 |
#### 8.6.3 可配置接口
NvM 提供的回调:
- `NvM_JobEndNotification`
- `NvM_JobErrorNotification`
---
## 9 时序图
### 9.1 Fee_Init
EcuM → Fee → Fls 链路上的初始化序列。可能涉及多次主函数调用以完成内部 Flash 扫描。
### 9.2 Fee_Write
NvM → Fee → Fls 链路:写请求传播,异步 Flash 写入(可能包括擦除前操作),完成后回调通知。
### 9.3 Fee_Cancel
NvM → Fee → Fls:同步取消。
---
## 10 配置规范
### 10.1 容器与配置参数
#### 10.1.1 Fee
| 项 | 内容 |
|-----|------|
| SWS Item | ECUC_Fee_00100 |
| Module Name | Fee |
| Module Description | FEE 模块配置 |
#### 10.1.2 FeeGeneral
| 参数 | 描述 |
|------|------|
| FeeDevErrorDetect | 开发错误检测开关 |
| FeeVersionInfoApi | 版本信息 API 启用 |
| FeeSetModeApi | SetMode API 启用 |
| FeeMainFunctionPeriod | 主函数周期 |
| FeeVirtualPageSize | 虚拟页大小 |
| FeeNvmJobEndNotification | NvM 作业结束通知回调函数名 |
| FeeNvmJobErrorNotification | NvM 作业错误通知回调函数名 |
| FeePollingMode | 轮询模式开关 |
#### 10.1.3 FeeBlockConfiguration
每个逻辑块配置:
| 参数 | 描述 |
|------|------|
| FeeBlockNumber | 块编号(不可为 0x0000 或 0xFFFF) |
| FeeBlockSize | 块大小 |
| FeeDeviceIndex | 设备索引 |
| FeeImmediateData | 是否为立即数据 |
| FeeNumberOfWriteCycles | 期望写周期数 |
### 10.2 已发布信息
#### FeePublishedInformation
已发布参数包括:
- 物理写块大小
- 物理可擦除块大小
---
## 11 不适用需求
[SWS_Fee_00999] ⌈这些需求不适用于本规范。⌋ 涉及多个 SRS_BSW_* 和 SRS_SPAL_* 需求,详见原文 PDF。
---
## 翻译说明
- 本文档完整翻译自 AUTOSAR_SWS_FlashEEPROMEmulation v4.4.0(Document ID 286,56 页)。
- 保留所有需求 ID(SWS_Fee_xxxxx、SRS_MemHwAb_xxxxx、ECUC_Fee_xxxxx)。
- 保留 AUTOSAR 方框符 ⌈⌋。
- 模块缩写(Fee、Fls、NvM、MemIf、EA 等)和 API 函数名保持英文。
- 详细配置参数和示例请参考原文 PDF 第 10 章。
Memory/AUTOSAR_SWS_FlashTest.md
+658
View File
@@ -0,0 +1,658 @@
# Flash 测试规范
> **文档标题**: Specification of Flash Test
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 261
> **文档类型**: SWS (Software Specification)
---
## 文档标识
| 项目 | 内容 |
|------|------|
| Document Title | Specification of Flash Test |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 261 |
| 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 | 移除 FlsTstBlockBgndConfigSet 和 FlsTstBlockFgndConfigSet;新增 FlsTstEcucPartitionRef 配置参数 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 数值定义;小幅更正/澄清/编辑性修订 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 新增 ECUC_FlsTst_00172: FlsTstMainFunctionPeriod;移除 SWS_FlsTst_00081 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 调试支持标记为过时;扩展生产错误表带通过/失败标准;Default Error Tracer 重命名 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 多项 SWS_FlsTst 文本修改;ECUC_FlsTst_00086 新增 FlsTstConfigurationOfOptApiServices |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 编辑性修订 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 按新 SWS_BSWGeneral 文档重做;MemMap.h 重命名为 FlsTst_MemMap.h;移除生产错误;新增生产错误和扩展生产错误章节 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | SWS_FlsTst_00026 文本变更;SWS_FlsTst_00052 参数范围修改 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | FlsTst_BlockIdFgndType 类型变为 uint8-32;参数范围限制为最大值 0xFFFFFFFF |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 初始版本发布 |
---
## 目录
1. [介绍与功能概述](#1-介绍与功能概述)
2. [缩略语](#2-缩略语)
3. [相关文档](#3-相关文档)
4. [约束与假设](#4-约束与假设)
5. [模块依赖](#5-模块依赖)
6. [需求追溯](#6-需求追溯)
7. [功能规范](#7-功能规范)
8. [API 规范](#8-api-规范)
9. [时序图](#9-时序图)
10. [配置规范](#10-配置规范)
11. [不适用需求](#11-不适用需求)
---
## 1 介绍与功能概述
本规范规定 AUTOSAR 基础软件模块 Flash Test Driver 的功能、API 和配置。
Flash Test 模块提供测试不变内存(invariable memory)的算法。不变内存可以是数据/程序 Flash、程序 SRAM、锁定缓存,可嵌入微控制器或通过内存映射连接。
主要特性:
- **后台测试**(Background Test):周期性调用,可中断,在多个调度任务上分散执行
- **前台测试**(Foreground Test):由用户调用,同步,不可中断
- 支持多种算法:ECC 检查、CRC 签名(8/16/32 位)、校验和、重复块比较
- 测试间隔标识符
---
## 2 缩略语
| 缩略语 | 描述 |
|--------|------|
| FlsTst | Flash Test 模块名 |
| ECU | Electric Control Unit |
| EOL | End Of Line |
| CRC | Cyclic Redundancy Check |
| MCAL | Microcontroller Abstraction Layer |
| MCU | Microcontroller Unit |
| DEM | Diagnostic Event Manager |
| DET | Default Error Tracer |
| ECC | Error Correction Code |
| Invariable memory | 不变内存(程序 Flash、程序 SRAM、锁定缓存、ROM) |
| Background test | 由调度程序周期调用、可中断 |
| Foreground test | 由用户调用,同步 |
| Test interval | 后台模式下完整 Flash 测试的间隔 |
| Signature | 内存块内容的唯一计算结果 |
| Memory scrubbing | 自动顺序数据读取触发检测/验证机制 |
---
## 3 相关文档
### 3.1 输入文档
- List of Basic Software Modules
- Layered Software Architecture
- General Requirements on Basic Software Modules
- Requirements on Flash Test — AUTOSAR_SRS_FlashTest.pdf
- Specification of Default Error Tracer
- Specification of Diagnostic Event Manager
- Specification of ECU State Manager
- General Specification of Basic Software Modules
### 3.2 相关规范
AUTOSAR 提供基础软件模块通用规范(SWS BSW General),也适用于 Flash Test。
---
## 4 约束与假设
### 4.1 限制
Flash Test 模块旨在集成于整体安全概念中,本身不会提供所需的诊断覆盖率。
### 4.2 适用车型领域
无限制。
---
## 5 模块依赖
### 5.1 文件结构
#### 5.1.1 代码文件结构
[SWS_FlsTst_00003] ⌈Flash Test 模块的内存映射应通过 FlsTst_MemMap.h 实现。⌋
---
## 6 需求追溯
(主要追溯关系,完整表见原文 PDF)
| 需求 | 描述 | 满足者 |
|------|------|--------|
| SRS_BSW_00337 | 开发错误分类 | SWS_FlsTst_00007 |
| SRS_BSW_00377 | 模块特定类型 | SWS_FlsTst_00048 |
| SRS_BSW_00385 | 错误通知列表 | SWS_FlsTst_00007 |
| SRS_BSW_00405 | 配置结构 | SWS_FlsTst_00018, 00019 |
| SRS_BSW_00406 | 模块初始化 | SWS_FlsTst_00011 |
| SRS_FlsTst_14200 (Flash 测试服务配置) | SWS_FlsTst_00018, 00019 |
| SRS_FlsTst_14202 (ECC) | SWS_FlsTst_00161 |
| SRS_FlsTst_14203 (校验和) | SWS_FlsTst_00161 |
| SRS_FlsTst_14204/14205/14206 (8/16/32 位 CRC) | SWS_FlsTst_00161 |
| SRS_FlsTst_14207 (重复块比较) | SWS_FlsTst_00161 |
| SRS_FlsTst_14208 (后台 Flash 可中断) | SWS_FlsTst_00139, 00140 |
| SRS_FlsTst_14209 (内存分散) | SWS_FlsTst_00139 |
| SRS_FlsTst_14211 (测试执行状态) | SWS_FlsTst_00043 |
| SRS_FlsTst_14212 (通知机制) | SWS_FlsTst_00040, 00042 |
| SRS_FlsTst_14213 (签名/校验和) | SWS_FlsTst_00046, 00079 |
| SRS_FlsTst_14215 (暂停) | SWS_FlsTst_00071 |
| SRS_FlsTst_14216 (恢复) | SWS_FlsTst_00067 |
| SRS_FlsTst_14217 (停止) | SWS_FlsTst_00115, 00116, 00117 |
| SRS_FlsTst_14219 (前台测试) | SWS_FlsTst_00137, 00143 |
| SRS_FlsTst_14223 (错误细节) | SWS_FlsTst_00132 |
| SRS_FlsTst_14224 (ECC 电路测试) | SWS_FlsTst_00164 |
| SRS_FlsTst_14225 (测试间隔标识符) | SWS_FlsTst_00153, 00154, 00155, 00156 |
| SRS_SPAL_12057 (初始化) | SWS_FlsTst_00017, 00020 |
| SRS_SPAL_12163 (反初始化) | SWS_FlsTst_00027, 00028 |
| SRS_SPAL_12448 (开发错误检测后行为) | SWS_FlsTst_00025, 00033, 00039 |
完整追溯表见原文 PDF。
---
## 7 功能规范
### 7.1 总体行为
[SWS_FlsTst_00137] ⌈Flash 测试模块提供后台和前台模式的测试执行服务。⌋
[SWS_FlsTst_00138] ⌈待测内存块应可分别为后台和前台模式配置。⌋
#### 后台模式
[SWS_FlsTst_00139] ⌈后台模式下,测试块应按配置结构中的顺序进行测试。当所有块测试完毕,完成一个测试间隔。后台测试中,部分测试通过 `FlsTst_MainFunction` 触发。⌋
[SWS_FlsTst_00140] ⌈部分测试长度由一个调度任务中被测试的单元数定义(`ECUC_FlsTst_00161`)。不中断的部分测试所需时间定义为"测试时间"。⌋
[SWS_FlsTst_00142] ⌈后台测试应可通过 `FlsTst_Abort()` 或 `FlsTst_Suspend()` API 服务中止或暂停。API 调用请求处理的最大延迟时间应可配置。⌋
[SWS_FlsTst_00156] ⌈每个 Flash 测试间隔应有一个标识符,在后台模式下每次新测试间隔启动时递增。⌋
#### 7.1.1 状态图
后台模式下 Flash 测试驱动状态:
```
FlsTst_Init()
[Reset] → FLSTST_UNINIT ─────────→ FLSTST_INIT
↑ │ autostart
│ ↓
FlsTst_DeInit() FLSTST_RUNNING
↑ ↑ ↓
│ FlsTst_Resume│ │ Test completed
│ │ │ FlsTst_Suspend()
│ │ │
↑ FLSTST_SUSPENDED↓
FLSTST_ABORTED ←─── FlsTst_Abort() ──┘
↑ ↑
└────FlsTst_Abort()────┘
```
[SWS_FlsTst_00143] ⌈前台测试定义为同步、不可中断的测试。前台测试执行可配置,可在模块初始化后随时调用。⌋
### 7.2 错误分类
[SWS_FlsTst_00007] ⌈
| 错误类型 | 错误类别 | 相关错误代码 | 值[hex] |
|----------|----------|--------------|---------|
| Flash 测试执行状态故障 | Development | FLSTST_E_STATE_FAILURE | 0x01 |
| API 参数超出规定范围 | Development | FLSTST_E_PARAM_INVALID | 0x02 |
| 模块未初始化即调用 API 服务 | Development | FLSTST_E_UNINIT | 0x03 |
| Flash 测试模块已初始化 | Development | FLSTST_E_ALREADY_INITIALIZED | 0x04 |
| 配置指针错误(PB:为 NULL;PC:不为 NULL) | Development | FLSTST_E_INIT_FAILED | 0x05 |
| NULL 指针 | Development | FLSTST_E_PARAM_POINTER | 0x06 |
⌋
### 7.3 生产错误
Flash Test 模块未规定生产错误。
### 7.4 扩展生产错误
[SWS_FlsTst_00168] ⌈
| 项 | 内容 |
|-----|------|
| Error Name | FLSTST_E_FLSTST_FAILURE |
| Short Description | 后台模式中的失败检测 |
| Long Description | 在测试间隔内后台模式检测到故障时发出此扩展生产错误。 |
| Detection Criteria | Fail: 后台模式测试间隔内至少一个块为 NOT OK;Pass: 所有块以 OK 结果测试 |
| Monitor Frequency | continuous |
⌋
### 7.5 运行时错误
Flash Test 模块未规定运行时错误。
### 7.6 瞬态故障
Flash Test 模块未规定瞬态故障。
### 7.7 错误检测
[SWS_FlsTst_00011] ⌈在调用任何其他 Flash Test 函数(除 `FlsTst_GetCurrentState`)之前必须先调用 `FlsTst_Init`。如不遵守此顺序,应向 Default Error Tracer 报告错误代码 `FLSTST_E_UNINIT`(如启用开发错误检测)。⌋
### 7.8 错误通知
参考 SWS_BSWGeneral 文档。
### 7.9 版本检查
参考 SWS_BSWGeneral 文档。
### 7.10 调试支持
无需求定义。
---
## 8 API 规范
### 8.1 导入的类型
[SWS_FlsTst_00016] ⌈
| 模块 | 头文件 | 导入类型 |
|------|--------|----------|
| Dem | Rte_Dem_Type.h | Dem_EventIdType, Dem_EventStatusType |
| Std_Types | StandardTypes.h | Std_ReturnType, Std_VersionInfoType |
⌋
### 8.2 类型定义
#### 8.2.1 FlsTst_ConfigType
| 项 | 内容 |
|-----|------|
| Name | FlsTst_ConfigType |
| Type | Structure |
| Range | 实现特定 |
| Description | 包含 Flash 测试初始化数据的外部数据结构类型。 |
强制配置参数:
- 前台模式测试内存块定义
- 后台模式测试内存块定义
- 后台模式测试序列指示
- 硬件特定配置
#### 8.2.2 FlsTst_StateType
| 项 | 内容 |
|-----|------|
| Name | FlsTst_StateType |
| Type | Enumeration |
| Range | FLSTST_UNINIT (0x00) — 未初始化或不可用;FLSTST_INIT (0x01) — 已初始化,准备启动;FLSTST_RUNNING (0x02) — 当前正在运行;FLSTST_ABORTED (0x03) — 已中止;FLSTST_SUSPENDED (0x04) — 等待恢复或等待启动前台模式测试 |
| Description | 由 `FlsTst_GetCurrentState()` API 服务返回的状态值。 |
#### 8.2.3 FlsTst_TestResultFgndType
| 项 | 内容 |
|-----|------|
| Range | FLSTST_NOT_TESTED (0x00); FLSTST_OK (0x01); FLSTST_NOT_OK (0x02) |
| Description | `FlsTst_GetResultFgnd()` API 服务的返回类型。 |
#### 8.2.4 FlsTst_TestResultBgndType
| 项 | 内容 |
|-----|------|
| Type | Structure |
| Elements | 当前 FlsTstTestIntervalId 值;FlsTst_TestResultType 结果 |
| Description | `FlsTst_GetTestResultBgnd()` 的返回类型。 |
#### 8.2.5 FlsTst_BlockIdFgndType
uint8/uint16/uint32 — 前台模式 Flash 块的 ID。
#### 8.2.6 FlsTst_ErrorDetailsType
| 项 | 内容 |
|-----|------|
| Type | Structure (实现特定) |
| Description | 实现特定的错误信息。 |
#### 8.2.7 FlsTst_TestSignatureFgndType
| 项 | 内容 |
|-----|------|
| Type | Structure (实现特定) |
| Description | 前台模式测试签名。 |
#### 8.2.8 FlsTst_TestSignatureBgndType
| 项 | 内容 |
|-----|------|
| Type | Structure |
| Elements | 当前 FlsTstTestIntervalId 值;签名值 |
| Description | 后台模式测试签名。 |
#### 8.2.9 FlsTst_TestResultType
| 项 | 内容 |
|-----|------|
| Range | FLSTST_RESULT_NOT_TESTED (0x00); FLSTST_RESULT_OK (0x01); FLSTST_RESULT_NOT_OK (0x02) |
### 8.3 函数定义
#### 8.3.1 FlsTst_Init
```c
void FlsTst_Init(const FlsTst_ConfigType* ConfigPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x00 |
| Sync/Async | Synchronous |
| Description | 初始化 Flash Test 模块。 |
#### 8.3.2 FlsTst_DeInit
```c
void FlsTst_DeInit(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x01 |
| Description | 反初始化 Flash Test 模块。 |
#### 8.3.3 FlsTst_StartFgnd
```c
Std_ReturnType FlsTst_StartFgnd(FlsTst_BlockIdFgndType BlockId)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x02 |
| Sync/Async | Synchronous |
| Description | 启动前台模式 Flash 测试。 |
#### 8.3.4 FlsTst_Abort
```c
Std_ReturnType FlsTst_Abort(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x03 |
| Description | 中止后台 Flash 测试。 |
#### 8.3.5 FlsTst_Suspend
```c
Std_ReturnType FlsTst_Suspend(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x04 |
| Description | 暂停后台 Flash 测试。 |
#### 8.3.6 FlsTst_Resume
```c
Std_ReturnType FlsTst_Resume(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x05 |
| Description | 恢复后台 Flash 测试。 |
#### 8.3.7 FlsTst_GetCurrentState
```c
FlsTst_StateType FlsTst_GetCurrentState(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x06 |
| Description | 返回当前 Flash 测试状态。 |
#### 8.3.8 FlsTst_GetTestResultBgnd
```c
Std_ReturnType FlsTst_GetTestResultBgnd(FlsTst_TestResultBgndType* TestResultBgndPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x07 |
| Description | 返回后台测试结果。 |
#### 8.3.9 FlsTst_GetTestResultFgnd
```c
FlsTst_TestResultFgndType FlsTst_GetTestResultFgnd(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x08 |
| Description | 返回前台测试结果。 |
#### 8.3.10 FlsTst_GetVersionInfo
```c
void FlsTst_GetVersionInfo(Std_VersionInfoType* VersionInfoPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x09 |
#### 8.3.11 FlsTst_GetTestSignatureBgnd
```c
Std_ReturnType FlsTst_GetTestSignatureBgnd(FlsTst_TestSignatureBgndType* TestSignaturePtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0a |
| Description | 返回后台测试签名。 |
#### 8.3.12 FlsTst_GetTestSignatureFgnd
```c
Std_ReturnType FlsTst_GetTestSignatureFgnd(FlsTst_TestSignatureFgndType* TestSignaturePtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0b |
| Description | 返回前台测试签名。 |
#### 8.3.13 FlsTst_GetErrorDetails
```c
Std_ReturnType FlsTst_GetErrorDetails(FlsTst_ErrorDetailsType* ErrorDetailsPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0c |
| Description | 返回错误细节。 |
#### 8.3.14 FlsTst_TestEcc
```c
Std_ReturnType FlsTst_TestEcc(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0d |
| Description | 测试 ECC 电路。 |
### 8.4 回调通知
无。
### 8.5 调度函数
#### FlsTst_MainFunction
```c
void FlsTst_MainFunction(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0e |
| Description | 执行后台 Flash 测试的服务。 |
| Available via | SchM_FlsTst.h |
### 8.6 期望接口
#### 强制接口
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| Dem_SetEventStatus | Dem.h | 报告监视状态信息到 Dem |
#### 可选接口
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| Det_ReportError | Det.h | 报告开发错误 |
#### 可配置接口
##### FlsTst_TestCompleted 通知
测试完成时调用的可配置回调函数。
---
## 9 时序图
### 9.1 初始化
EcuM → FlsTst:`FlsTst_Init`
### 9.2 反初始化
EcuM → FlsTst:`FlsTst_DeInit`
### 9.3 后台测试
调度程序周期调用 `FlsTst_MainFunction`,执行部分测试。可选地:
- 在驱动内部计算测试结果
- 将测试签名提供给调用者
### 9.4 暂停和恢复后台测试
用户 → FlsTst:`FlsTst_Suspend` → `FlsTst_Resume`
### 9.5 前台任务中断后台任务
后台测试运行时,通过 `FlsTst_StartFgnd` 启动前台测试。
---
## 10 配置规范
### 10.1 容器与配置参数
#### 10.1.1 FlsTst
| 项 | 内容 |
|-----|------|
| SWS Item | ECUC_FlsTst_00150 |
| Module Name | FlsTst |
| Module Description | Flash Test 模块配置 |
| Post-Build Variant Support | true |
| Supported Config Variants | VARIANT-POST-BUILD, VARIANT-PRE-COMPILE |
#### 10.1.2 FlsTstGeneral
| 参数 | 描述 |
|------|------|
| FlsTstDevErrorDetect | 开发错误检测开关 |
| FlsTstVersionInfoApi | 版本信息 API 启用 |
| FlsTstNumberOfTestedCells | 一周期测试的单元数 |
| FlsTstNumberOfTestedCellsAtomic | 部分测试中可中断的最小单元数 |
| FlsTstTestIntervalIdEndValue | 测试间隔标识符结束值 |
| FlsTstMainFunctionPeriod | 主函数周期(秒) |
| FlsTstEcucPartitionRef | ECUC 分区引用 |
#### 10.1.3 FlsTstConfigurationOfOptApiServices
可选 API 服务配置:启用/禁用以下 API:
- FlsTst_StartFgnd
- FlsTst_GetTestResultBgnd
- FlsTst_GetTestResultFgnd
- FlsTst_GetTestSignatureBgnd
- FlsTst_GetTestSignatureFgnd
- FlsTst_GetErrorDetails
- FlsTst_TestEcc
#### 10.1.4 FlsTstDemEventParameterRefs
引用 DEM 事件参数:
- FLSTST_E_FLSTST_FAILURE
#### 10.1.5 FlsTstBlockBgnd
每个后台测试块:
| 参数 | 描述 |
|------|------|
| FlsTstBlockNumberBgnd | 后台块编号 |
| FlsTstBlockIndex | 块索引 |
| FlsTstBlockSize | 块大小 |
| FlsTstBlockType | 块类型(算法选择) |
| FlsTstBlockStartAddress | 块起始地址 |
#### 10.1.6 FlsTstBlockFgnd
每个前台测试块:
| 参数 | 描述 |
|------|------|
| FlsTstBlockNumberFgnd | 前台块编号 |
| FlsTstBlockIndex | 块索引 |
| FlsTstBlockSize | 块大小 |
| FlsTstBlockType | 块类型(算法选择) |
| FlsTstBlockStartAddress | 块起始地址 |
### 10.2 已发布信息
发布的参数包括版本信息等。
---
## 11 不适用需求
[SWS_FlsTst_00166] ⌈这些需求不适用于本规范。⌋ 涉及多个 SRS_BSW_* 和 SRS_SPAL_* 需求,详见原文 PDF。
---
## 翻译说明
- 本文档完整翻译自 AUTOSAR_SWS_FlashTest v4.4.0(Document ID 261,56 页)。
- 保留所有需求 ID(SWS_FlsTst_xxxxx、SRS_FlsTst_xxxxx、ECUC_FlsTst_xxxxx)。
- 保留 AUTOSAR 方框符 ⌈⌋。
- 模块缩写(FlsTst、Fls、ECC、CRC、DEM、DET 等)和 API 函数名保持英文。
- 详细配置参数和示例请参考原文 PDF 第 10 章。
Memory/AUTOSAR_SWS_MemoryAbstractionInterface.md
+607
View File
@@ -0,0 +1,607 @@
# 内存抽象接口规范
> **文档标题**: Specification of Memory Abstraction Interface
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 285
> **文档类型**: SWS (Software Specification)
---
## 文档标识
| 项目 | 内容 |
|------|------|
| Document Title | Specification of Memory Abstraction Interface |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 285 |
| 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 | 块结果 MEMIF_BLOCK_INCONSISTENT 扩展为找不到的块;错误分类重做;增加需求链接 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 需求与特性、通用和模块特定需求关联 |
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 编辑性修订 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 移除模块主函数的时序需求;为 Fee_Write 函数原型增加 const 限定符;新增 FeeMainFunctionPeriod 配置参数 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 按新的 SWS_BSWGeneral 重做;第 10 章表格中增加 Scope 属性;包含文件结构变更(清理);为类型定义增加需求 ID |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 模块简称变更;一致性检查重新表述 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 增加 NULL 指针检查;模块间检查细化 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 返回值描述扩充;文件包含结构变更;变体需求描述增加;法律免责声明修订 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 文件包含结构更新;各种 API 返回类型适配;配置参数范围调整 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始版本发布 |
---
## 目录
1. [介绍与功能概述](#1-介绍与功能概述)
2. [缩略语](#2-缩略语)
3. [相关文档](#3-相关文档)
4. [约束与假设](#4-约束与假设)
5. [模块依赖](#5-模块依赖)
6. [需求追溯](#6-需求追溯)
7. [功能规范](#7-功能规范)
8. [API 规范](#8-api-规范)
9. [时序图](#9-时序图)
10. [配置规范](#10-配置规范)
11. [不适用需求](#11-不适用需求)
---
## 1 介绍与功能概述
本规范描述 AUTOSAR 基础软件模块 "Memory Abstraction Interface" (MemIf) 的功能、API 和配置。本模块允许 NVRAM 管理器访问多个内存抽象模块(FEE 或 EA 模块)。
```
NVRAM Manager
│
▼
Memory Hardware Abstraction
├── Memory Abstraction Interface (MemIf)
│ │
│ ▼
├── Flash EEPROM Emulation (FEE) ─── ▶ Flash Driver
└── EEPROM Abstraction (EA) ─── ▶ EEPROM Driver
↕
Vendor Specific Library
```
*图 1:内存硬件抽象层模块概览*
Memory Abstraction Interface (MemIf) 应抽象出底层 FEE 或 EA 模块的数量,并为上层提供统一线性地址空间上的虚拟分段。
---
## 2 缩略语
| 缩写/缩略语 | 描述 |
|--------|------|
| EA | EEPROM Abstraction(EEPROM 抽象) |
| EEPROM | 电可擦可编程只读存储器 |
| FEE | Flash EEPROM Emulation(Flash EEPROM 仿真) |
| LSB | 最低有效位/字节(根据上下文)。此处指位。 |
| MemIf | Memory Abstraction Interface(内存抽象接口) |
| MSB | 最高有效位/字节(根据上下文)。此处指位。 |
| NvM | NVRAM Manager |
| NVRAM | 非易失 RAM |
| Fast Mode(快速模式) | 例如在启动/关机期间,底层驱动可切换到快速模式,以便在那些阶段进行快速读/写。<br>注:这是否可能取决于驱动的实现和底层设备的能力。是否这样做取决于 NVRAM 管理器的配置以及特定项目的需求。 |
| Slow Mode(慢速模式) | 在正常运行期间,底层驱动可在慢速模式下使用,以减少运行时间或底层设备/通信媒体的阻塞时间方面的资源使用。 |
| Vendor specific library(厂商特定库) | 厂商特定库分别是 FEE/FLS 和 EA/EEP 模块的 ICC-2 实现。它提供与相应 ICC-3 实现相同的上层接口(API)和功能。 |
---
## 3 相关文档
### 3.1 输入文档
[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] Requirements on Memory Hardware Abstraction Layer — AUTOSAR_SRS_MemoryHWAbstractionLayer
[6] Specification of Default Error Tracer — AUTOSAR_SWS_DefaultErrorTracer.pdf
[7] General Specification of Basic Software Modules — AUTOSAR_SWS_BSWGeneral.pdf
### 3.2 相关标准与规范
[7] Specification of NVRAM Manager — AUTOSAR_SWS_NVRAMManager
[8] Specification of Flash EEPROM Emulation — AUTOSAR_SWS_FlashEEPROMEmulation.pdf
[9] Specification of EEPROM Abstraction — AUTOSAR_SWS_EEPROMAbstraction.pdf
### 3.3 相关规范
AUTOSAR 提供基础软件模块的通用规范(SWS BSW General),也适用于 Memory Abstraction Interface。
---
## 4 约束与假设
### 4.1 限制
无限制。
### 4.2 适用车型领域
无限制。
---
## 5 模块依赖
(无具体描述)
---
## 6 需求追溯
| 需求 | 描述 | 满足者 |
|------|------|--------|
| RS_BRF_01472 | AUTOSAR 应支持模式 | SWS_MemIf_00038 |
| RS_BRF_02272 | AUTOSAR 应提供应用软件行为的追踪 | SWS_MemIf_00042 |
| SRS_BSW_00323 | 所有 AUTOSAR BSW 模块应检查传入的 API 参数有效性 | SWS_MemIf_00022 |
| SRS_BSW_00327 | 错误值命名规范 | SWS_MemIf_00006 |
| SRS_BSW_00386 | 公约的产品错误代码 | SWS_MemIf_00023 |
| SRS_BSW_00392 | 模块特定类型定义 | SWS_MemIf_00037, 00064, 00065, 00066 |
| SRS_BSW_00407 | 版本信息 API | SWS_MemIf_00045 |
| SRS_MemHwAb_14010 | FEE 与 EA 模块应提供仅操作完整已配置逻辑块的写服务 | SWS_MemIf_00040 |
| SRS_MemHwAb_14019 | 内存抽象接口应提供对底层内存抽象模块 API 服务的统一访问 | SWS_MemIf_00017 |
| SRS_MemHwAb_14020 | 内存抽象接口应允许使用设备索引选择底层内存抽象模块 | SWS_MemIf_00011, 00018, 00035 |
| SRS_MemHwAb_14021 | 内存抽象接口应允许预编译时配置底层内存抽象模块的数量 | SWS_MemIf_00018, 00019, 00020, 00022 |
| SRS_MemHwAb_14022 | 内存抽象接口应保留底层内存抽象模块的功能 | SWS_MemIf_00010, 00017, 00038, 00039, 00040, 00041, 00042, 00043, 00044, 00046 |
| SRS_MemHwAb_14023 | 内存抽象接口应仅检查接口本身内使用的参数 | SWS_MemIf_00022 |
| SRS_MemHwAb_14028 | FEE 与 EA 模块应提供使逻辑块无效化的服务 | SWS_MemIf_00044 |
| SRS_MemHwAb_14029 | FEE 与 EA 模块应提供允许读取逻辑块全部或部分的读服务 | SWS_MemIf_00039 |
| SRS_MemHwAb_14031 | FEE 与 EA 模块应提供允许取消正在进行的异步操作的服务 | SWS_MemIf_00041 |
| SRS_MemHwAb_14032 | FEE 与 EA 模块应提供仅操作包含立即数据的完整逻辑块的擦除服务 | SWS_MemIf_00046 |
| SRS_SPAL_12078 | 驱动应以内存和运行时资源最有效的方式编码 | SWS_MemIf_00019, 00020 |
| SRS_SPAL_12448 | 所有驱动模块在检测到开发错误后应有特定行为 | SWS_MemIf_00023 |
更多 SRS_BSW_* 与 SRS_SPAL_* 需求由 SWS_MemIf_00999(不适用)满足,详见第 11 章。
---
## 7 功能规范
### 7.1 错误分类
#### 7.1.1 开发错误
[SWS_MemIf_00006] ⌈Memory Abstraction Interface 应根据其配置(开发/生产)能够检测以下错误和异常:
| 错误类型 | 相关性 | 相关错误代码 | 值[hex] |
|---------|--------|--------------|---------|
| 用错误设备索引参数调用 API 服务 | Development | MEMIF_E_PARAM_DEVICE | 0x01 |
| 用 NULL 指针参数调用 API 服务 | Development | MEMIF_E_PARAM_POINTER | 0x02 |
⌋ (SRS_BSW_00337, SRS_BSW_00386, SRS_BSW_00327)
#### 7.1.2 运行时错误
无此类错误。
#### 7.1.3 瞬态故障
无此类错误。
#### 7.1.4 生产错误
无此类错误。
#### 7.1.5 扩展生产错误
无此类错误。
---
## 8 API 规范
### 8.1 导入的类型
#### 8.1.1 标准类型
[SWS_MemIf_00037] ⌈
| 模块 | 头文件 | 导入类型 |
|------|--------|----------|
| Std_Types | StandardTypes.h | Std_ReturnType |
| Std_Types | StandardTypes.h | Std_VersionInfoType |
⌋ (SRS_BSW_00392)
### 8.2 类型定义
[SWS_MemIf_00010] ⌈本章规定的类型不应针对特定内存抽象模块或硬件平台被更改或扩展。⌋ (SRS_MemHwAb_14022)
[SWS_MemIf_00011] ⌈内存设备索引的数据类型应为 uint8。此设备索引使用的最低值应为 0。因此允许的索引范围应为 `0..MEMIF_NUMBER_OF_DEVICES-1`。⌋ (SRS_MemHwAb_14020)
#### 8.2.1 MemIf_StatusType
[SWS_MemIf_00064] ⌈
| 项 | 内容 |
|-----|------|
| Name | MemIf_StatusType |
| Type | Enumeration |
| Range | MEMIF_UNINIT — 底层抽象模块或设备驱动尚未初始化<br>MEMIF_IDLE — 底层抽象模块或设备驱动当前空闲<br>MEMIF_BUSY — 底层抽象模块或设备驱动当前忙<br>MEMIF_BUSY_INTERNAL — 底层抽象模块正忙于内部管理操作。底层设备驱动可以忙或空闲。 |
| Description | 表示底层抽象模块和设备驱动的当前状态。 |
| Available via | MemIf.h |
⌋ (SRS_BSW_00392)
#### 8.2.2 MemIf_JobResultType
[SWS_MemIf_00065] ⌈
| 项 | 内容 |
|-----|------|
| Name | MemIf_JobResultType |
| Type | Enumeration |
| Range | MEMIF_JOB_OK — 作业已成功完成<br>MEMIF_JOB_FAILED — 作业未成功完成<br>MEMIF_JOB_PENDING — 作业尚未完成<br>MEMIF_JOB_CANCELED — 作业已被取消<br>MEMIF_BLOCK_INCONSISTENT — 1. 请求的块不一致,可能包含损坏数据;2. 块未找到<br>MEMIF_BLOCK_INVALID — 请求的块已被标记为无效,无法执行请求的操作 |
| Description | 表示上次作业的结果。 |
| Available via | MemIf.h |
⌋ (SRS_BSW_00392)
#### 8.2.3 MemIf_ModeType
[SWS_MemIf_00066] ⌈
| 项 | 内容 |
|-----|------|
| Name | MemIf_ModeType |
| Type | Enumeration |
| Range | MEMIF_MODE_SLOW — 底层内存抽象模块和驱动工作于慢速模式<br>MEMIF_MODE_FAST — 底层内存抽象模块和驱动工作于快速模式 |
| Description | 表示底层抽象模块和设备驱动的操作模式。 |
| Available via | MemIf.h |
⌋ (SRS_BSW_00392)
### 8.3 函数定义
[SWS_MemIf_00017] ⌈本章规定的 API 应映射到底层内存抽象模块的 API。功能行为请分别参考那些模块的规范或底层内存驱动的规范。⌋ (SRS_MemHwAb_14019, SRS_MemHwAb_14022)
[SWS_MemIf_00018] ⌈参数 DeviceIndex 应用于选择内存抽象模块(从而选择内存设备)。如果仅配置了一个内存抽象模块,参数 DeviceIndex 应被忽略。⌋ (SRS_MemHwAb_14020, SRS_MemHwAb_14021)
[SWS_MemIf_00019] ⌈如果仅配置了一个内存抽象模块,Memory Abstraction Interface 应实现为一组宏,将 Memory Abstraction Interface API 映射到相应内存抽象模块的 API。⌋ (SRS_SPAL_12078, SRS_MemHwAb_14021)
**示例:**
```c
#define MemIf_Write(DeviceIndex, BlockNumber, DataPtr) \
Fee_Write(BlockNumber, DataPtr)
```
[SWS_MemIf_00020] ⌈如果配置了多个内存抽象模块,Memory Abstraction Interface 应使用高效机制将 API 调用映射到适当的内存抽象模块。⌋ (SRS_SPAL_12078, SRS_MemHwAb_14021)
**注**:一种解决方案是使用函数指针表,以参数 DeviceIndex 作为数组索引。
**示例:**
```c
#define MemIf_Write(DeviceIndex, BlockNumber, DataPtr) \
MemIf_WriteFctPtr[DeviceIndex](BlockNumber,DataPtr)
```
[SWS_MemIf_00022] ⌈如果配置了多个内存抽象模块且为此模块启用了开发错误检测,Memory Abstraction Interface API 的函数应在模块的服务内检查参数 DeviceIndex 是否为现有设备或广播标识符。⌋ (SRS_BSW_00323, SRS_MemHwAb_14021, SRS_MemHwAb_14023)
[SWS_MemIf_00023] ⌈Memory Abstraction Interface API 的函数应将归因于非法参数 DeviceIndex 的检测错误以错误码 `MEMIF_E_PARAM_DEVICE` 报告给 Default Error Tracer (DET),且不应执行被调用的服务。⌋ (SRS_BSW_00386, SRS_SPAL_12448)
[SWS_MemIf_00024] ⌈如果 Memory Abstraction Interface API 的被调用函数检测到归因于非法参数 DeviceIndex 的错误且具有返回值,应设置如下:
- `MemIf_GetStatus`: `MEMIF_UNINIT`
- `MemIf_GetJobResult`: `MEMIF_JOB_FAILED`
- 所有其他函数: `E_NOT_OK`⌋ (SRS_BSW_00369)
#### 8.3.1 MemIf_SetMode
[SWS_MemIf_00038] ⌈
| 项 | 内容 |
|-----|------|
| Service name | MemIf_SetMode |
| Syntax | `void MemIf_SetMode(MemIf_ModeType Mode)` |
| Service ID[hex] | 0x01 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | Mode |
| Return value | None |
| Description | 调用所有底层内存抽象模块的 "SetMode" 函数。 |
| Available via | MemIf.h |
⌋ (RS_BRF_01472, SRS_MemHwAb_14022)
**注**:上面函数中故意省略了设备索引,即 Memory Interface 应将所有底层模块切换到请求的模式。在这种情况下,不需要额外的"广播"参数,因为设备不应单独切换到不同的模式。
#### 8.3.2 MemIf_Read
[SWS_MemIf_00039] ⌈
| 项 | 内容 |
|-----|------|
| Service name | MemIf_Read |
| Syntax | `Std_ReturnType MemIf_Read(uint8 DeviceIndex, uint16 BlockNumber, uint16 BlockOffset, uint8* DataBufferPtr, uint16 Length)` |
| Service ID[hex] | 0x02 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | DeviceIndex, BlockNumber, BlockOffset, Length |
| Parameters (out) | DataBufferPtr |
| Return value | Std_ReturnType — 如果开发错误检测被启用且检测到开发错误(根据 SWS_MemIf_00022),则函数应返回 E_NOT_OK,否则应返回所调用底层模块函数的返回值。 |
| Description | 调用由参数 DeviceIndex 选择的底层内存抽象模块的 "Read" 函数。 |
| Available via | MemIf.h |
⌋ (SRS_MemHwAb_14029, SRS_MemHwAb_14022)
#### 8.3.3 MemIf_Write
[SWS_MemIf_00040] ⌈
| 项 | 内容 |
|-----|------|
| Service name | MemIf_Write |
| Syntax | `Std_ReturnType MemIf_Write(uint8 DeviceIndex, uint16 BlockNumber, const uint8* DataBufferPtr)` |
| Service ID[hex] | 0x03 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | DeviceIndex, BlockNumber, DataBufferPtr |
| Return value | Std_ReturnType — 如开发错误检测启用且检测到开发错误,返回 E_NOT_OK,否则返回底层模块函数的返回值。 |
| Description | 调用由参数 DeviceIndex 选择的底层内存抽象模块的 "Write" 函数。 |
| Available via | MemIf.h |
⌋ (SRS_MemHwAb_14010, SRS_MemHwAb_14022)
#### 8.3.4 MemIf_Cancel
[SWS_MemIf_00041] ⌈
| 项 | 内容 |
|-----|------|
| Service name | MemIf_Cancel |
| Syntax | `void MemIf_Cancel(uint8 DeviceIndex)` |
| Service ID[hex] | 0x04 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | DeviceIndex |
| Return value | None |
| Description | 调用由参数 DeviceIndex 选择的底层内存抽象模块的 "Cancel" 函数。 |
| Available via | MemIf.h |
⌋ (SRS_MemHwAb_14031, SRS_MemHwAb_14022)
#### 8.3.5 MemIf_GetStatus
[SWS_MemIf_00042] ⌈
| 项 | 内容 |
|-----|------|
| Service name | MemIf_GetStatus |
| Syntax | `MemIf_StatusType MemIf_GetStatus(uint8 DeviceIndex)` |
| Service ID[hex] | 0x05 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | DeviceIndex |
| Return value | MemIf_StatusType |
| Description | 调用由参数 DeviceIndex 选择的底层内存抽象模块的 "GetStatus" 函数。 |
| Available via | MemIf.h |
⌋ (RS_BRF_02272, SRS_MemHwAb_14022)
[SWS_MemIf_00035] ⌈如果以广播到所有配置设备的设备索引(`MEMIF_BROADCAST_ID`)调用 `MemIf_GetStatus`,Memory Abstraction Interface 模块应依次调用所有底层设备的 "GetStatus" 函数。它应返回以下值:
- `MEMIF_IDLE` — 如果所有底层设备都返回此状态
- `MEMIF_UNINIT` — 如果至少一个设备返回此状态,所有其他返回状态应被忽略
- `MEMIF_BUSY` — 如果至少一个已配置设备返回此状态且没有其他设备返回 MEMIF_UNINIT
- `MEMIF_BUSY_INTERNAL` — 如果至少一个已配置设备返回此状态且没有其他设备返回 MEMIF_BUSY 或 MEMIF_UNINIT
⌋ (SRS_MemHwAb_14020)
**注**:`MemIf_GetStatus` 调用中的特殊"广播"设备 ID 用于查询所有设备是否空闲以关闭 ECU。
#### 8.3.6 MemIf_GetJobResult
[SWS_MemIf_00043] ⌈
| 项 | 内容 |
|-----|------|
| Service name | MemIf_GetJobResult |
| Syntax | `MemIf_JobResultType MemIf_GetJobResult(uint8 DeviceIndex)` |
| Service ID[hex] | 0x06 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | DeviceIndex |
| Return value | MemIf_JobResultType — 如开发错误检测启用且检测到开发错误,返回 MEMIF_JOB_FAILED,否则返回底层模块函数的返回值。 |
| Description | 调用由参数 DeviceIndex 选择的底层内存抽象模块的 "GetJobResult" 函数。 |
| Available via | MemIf.h |
⌋ (SRS_MemHwAb_14022)
#### 8.3.7 MemIf_InvalidateBlock
[SWS_MemIf_00044] ⌈
| 项 | 内容 |
|-----|------|
| Service name | MemIf_InvalidateBlock |
| Syntax | `Std_ReturnType MemIf_InvalidateBlock(uint8 DeviceIndex, uint16 BlockNumber)` |
| Service ID[hex] | 0x07 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | DeviceIndex, BlockNumber |
| Return value | Std_ReturnType |
| Description | 调用由参数 DeviceIndex 选择的底层内存抽象模块的 "InvalidateBlock" 函数。 |
| Available via | MemIf.h |
⌋ (SRS_MemHwAb_14028, SRS_MemHwAb_14022)
#### 8.3.8 MemIf_GetVersionInfo
[SWS_MemIf_00045] ⌈
| 项 | 内容 |
|-----|------|
| Service name | MemIf_GetVersionInfo |
| Syntax | `void MemIf_GetVersionInfo(Std_VersionInfoType* VersionInfoPtr)` |
| Service ID[hex] | 0x08 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant |
| Parameters (out) | VersionInfoPtr — 指向标准版本信息结构的指针。 |
| Description | 返回版本信息。 |
| Available via | MemIf.h |
⌋ (SRS_BSW_00407)
#### 8.3.9 MemIf_EraseImmediateBlock
[SWS_MemIf_00046] ⌈
| 项 | 内容 |
|-----|------|
| Service name | MemIf_EraseImmediateBlock |
| Syntax | `Std_ReturnType MemIf_EraseImmediateBlock(uint8 DeviceIndex, uint16 BlockNumber)` |
| Service ID[hex] | 0x09 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | DeviceIndex, BlockNumber |
| Return value | Std_ReturnType |
| Description | 调用由参数 DeviceIndex 选择的底层内存抽象模块的 "EraseImmediateBlock" 函数。 |
| Available via | MemIf.h |
⌋ (SRS_MemHwAb_14032, SRS_MemHwAb_14022)
### 8.4 回调通知
无。NVRAM 管理器应为底层内存抽象模块提供回调例程。
### 8.5 调度函数
无,本模块无异步函数。
### 8.6 期望接口
#### 8.6.1 强制接口
本章定义实现模块核心功能所需的所有接口。
[SWS_MemIf_00047] ⌈
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| Ea_Cancel | Ea.h | 取消正在进行的异步操作。 |
| Ea_EraseImmediateBlock | Ea.h | 擦除 BlockNumber 块。 |
| Ea_GetJobResult | Ea.h | 返回 JobResult 的服务。 |
| Ea_GetStatus | Ea.h | 返回状态的服务。 |
| Ea_InvalidateBlock | Ea.h | 使 BlockNumber 块无效。 |
| Ea_Read | Ea.h | 从 BlockNumber 块的 BlockOffset 偏移读取 Length 字节到缓冲区 DataBufferPtr。 |
| Ea_SetMode | Ea.h | 切换底层 EEPROM 驱动模式的函数。 |
| Ea_Write | Ea.h | 将 DataBufferPtr 内容写入 BlockNumber 块。 |
| Fee_Cancel | Fee.h | 调用底层 Flash 驱动的取消函数。 |
| Fee_EraseImmediateBlock | Fee.h | 擦除逻辑块的服务。 |
| Fee_GetJobResult | Fee.h | 查询上层软件发起的上次已接受作业的结果。 |
| Fee_GetStatus | Fee.h | 返回状态的服务。 |
| Fee_InvalidateBlock | Fee.h | 使逻辑块无效的服务。 |
| Fee_Read | Fee.h | 启动读作业的服务。 |
| Fee_SetMode | Fee.h | 切换底层 Flash 驱动模式的函数。 |
| Fee_Write | Fee.h | 启动写作业的服务。 |
⌋ (SRS_BSW_00384)
#### 8.6.2 可选接口
本章定义实现模块可选功能所需的所有接口。
[SWS_MemIf_00048] ⌈
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| Det_ReportError | Det.h | 报告开发错误的服务。 |
⌋ (SRS_BSW_00385)
#### 8.6.3 可配置接口
本章列出可配置目标函数的所有接口。目标函数通常是回调函数。
本模块没有可配置接口。
---
## 9 时序图
参考各内存抽象模块的规范。
---
## 10 配置规范
### 10.1 容器与配置参数
以下章节汇总所有配置参数。参数的详细含义在第 7 章和第 8 章中描述。
#### 10.1.1 MemIf
| 项 | 内容 |
|-----|------|
| SWS Item | ECUC_MemIf_00025 |
| Module Name | MemIf |
| Module Description | MemIf (Memory Abstraction Interface) 模块的配置。 |
| Post-Build Variant Support | false |
| Supported Config Variants | VARIANT-PRE-COMPILE |
**包含容器:**
| 容器名 | 多重性 | 范围/依赖 |
|--------|--------|-----------|
| MemIfGeneral | 1 | Memory Abstraction Interface (MemIf) 模块的配置。 |
#### 10.1.2 MemIfGeneral
| 项 | 内容 |
|-----|------|
| SWS Item | ECUC_MemIf_00034 |
| Container Name | MemIfGeneral |
| Description | Memory Abstraction Interface (MemIf) 模块的配置。 |
**配置参数:**
##### MemIfDevErrorDetect
| 项 | 内容 |
|-----|------|
| SWS Item | ECUC_MemIf_00035 |
| Name | MemIfDevErrorDetect |
| Parent Container | MemIfGeneral |
| Description | 开启或关闭开发错误检测与通知。<br>true:启用检测与通知;<br>false:禁用检测与通知。 |
| Multiplicity | 1 |
| Type | EcucBooleanParamDef |
| Default value | false |
| Value Configuration Class | Pre-compile time(所有变体) |
##### MemIfNumberOfDevices
| 项 | 内容 |
|-----|------|
| SWS Item | ECUC_MemIf_00033 |
| Name | MemIfNumberOfDevices |
| Parent Container | MemIfGeneral |
| Description | 底层内存抽象模块的具体数量。<br>计算公式:计算已配置 EA 和 FEE 模块的数量。 |
| Multiplicity | 1 |
| Type | EcucIntegerParamDef |
| Range | 1..2 |
| Value Configuration Class | Pre-compile time(所有变体) |
##### MemIfVersionInfoApi
| 项 | 内容 |
|-----|------|
| SWS Item | ECUC_MemIf_00032 |
| Name | MemIfVersionInfoApi |
| Parent Container | MemIfGeneral |
| Description | 预处理器开关,启用/禁用读取模块版本信息的 API。<br>true:启用版本信息 API;<br>false:禁用版本信息 API。 |
| Multiplicity | 1 |
| Type | EcucBooleanParamDef |
| Default value | false |
---
## 11 不适用需求
[SWS_MemIf_00999] ⌈以下需求不适用于本规范。⌋
(SRS_BSW_00404, SRS_BSW_00405, SRS_BSW_00159, SRS_BSW_00170, SRS_BSW_00380, SRS_BSW_00412, SRS_BSW_00398, SRS_BSW_00399, SRS_BSW_00400, SRS_BSW_00375, SRS_BSW_00101, SRS_BSW_00416, SRS_BSW_00406, SRS_BSW_00168, SRS_BSW_00423~00429, 00432, 00433, 00336, 00339, 00422, 00417, 00161, 00162, 00005, 00415, 00164, 00325, 00342, 00343, 00160, 00007, 00300, 00413, 00347, 00307, 00373, 00314, 00348, 00353, 00361, 00302, 00328, 00312, 00006, 00304, 00378, 00306, 00308, 00309, 00371, 00358, 00414, 00359, 00360, 00330, 00009, 00401, 00172, 00010, 00333, 00321, 00341, 00334, SRS_SPAL_12263, 12056, 12267, 12057, 12125, 12163, 12461, 12462, 12463, 12068, 12069, 00157, 12063, 12075, 12129, 12064, 12067, 12077, 12092, 12265)
---
## 翻译说明
- 本文档完整翻译自 AUTOSAR_SWS_MemoryAbstractionInterface v4.4.0(Document ID 285)。
- 保留所有需求 ID(SWS_MemIf_xxxxx、SRS_xxx_xxxxx、ECUC_MemIf_xxxxx)。
- 保留 AUTOSAR 方框符 ⌈⌋。
- 模块缩写(MemIf、Fee、Ea、NvM、Fls 等)和 API 函数名保持英文。
- 完整 SWS_MemIf_00999 不适用需求列表见原文 PDF。
Memory/AUTOSAR_SWS_MemoryMapping.md
+517
View File
@@ -0,0 +1,517 @@
# 内存映射规范
> **文档标题**: Specification of Memory Mapping
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 128
> **文档类型**: SWS (Software Specification)
---
## 文档标识
| 项目 | 内容 |
|------|------|
| Document Title | Specification of Memory Mapping |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 128 |
| 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 | 支持核心范围特定内存分配;清理需求追溯 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 支持安全系统的 BSW 分区;移除 Recommendation A 中过时内存段;澄清 SIZE 与 ALIGNMENT 的处理 |
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 澄清 `<X>` 在恢复区和保存数据区的使用 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 澄清默认 section 用法 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 内存分配关键字的一致命名模式;预定义 MemorySection 与 SwAddrMethod 的 M1 值;新增编译器抽象配置;支持 BSW 模块特定 MemMap 头文件 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 引入内存分配关键字的一致命名模式 |
| 2009-12-18 | 4.0.1 | AUTOSAR Administration | 为 MemMap 定义 ECU 配置参数;定义 MemMap 头文件的生成;新增初始化策略 CLEARED 标准化内存分配关键字 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 内存映射章节扩展用于应用 SWC;通用已发布信息更新 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2006-11-28 | 2.1 | AUTOSAR Administration | MEMMAP004 列出内存段名的所有大小后缀;新增 BOOLEAN 关键字 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始版本发布 |
---
## 目录
1. [介绍与功能概述](#1-介绍与功能概述)
2. [缩略语](#2-缩略语)
3. [相关文档](#3-相关文档)
4. [约束与假设](#4-约束与假设)
5. [模块依赖](#5-模块依赖)
6. [需求追溯](#6-需求追溯)
7. [功能规范](#7-功能规范)
8. [API 规范](#8-api-规范)
9. [时序图](#9-时序图)
10. [配置规范](#10-配置规范)
11. [分析](#11-分析)
---
## 1 介绍与功能概述
本文档规定通过内存映射文件将代码和数据映射到特定内存段的机制。对于许多 ECU 和微控制器平台,按模块将代码、变量和常量映射到特定内存段至关重要。
**重要用例**:
### 避免 RAM 浪费
如果在 32 位平台上多个模块使用不同大小变量(8、16、32 位),链接器在 RAM 中分配变量时会留下间隙。通过将变量按大小映射到特定内存段,可最小化 RAM 中未使用空间。
### 使用特定 RAM 属性
某些变量(如 NVRAM 管理器的 RAM 镜像)不应在上电复位后初始化。应可将它们映射到复位后不初始化的 RAM 段。
某些变量(如通过位掩码访问的)若位于允许编译器位操作指令的 RAM 段(如"近页"或"零页")中可提升性能和减小代码大小。
### 使用特定 ROM 属性
在带外部 Flash 内存的大型 ECU 中,需将频繁调用函数的模块映射到允许快速访问的内部 Flash 内存,实现更高性能。
### 同一模块源代码用于 boot loader 和应用
如果模块同时用于 boot loader 和应用,需要允许将代码和数据映射到不同内存段。
### 支持内存保护
硬件内存保护使用要求将模块变量分离到不同内存区域。内部变量映射到受保护内存,数据交换缓冲区映射到非保护内存。
### 支持分区
如果 BSW 模块应支持跨多个分区拆分,需将模块变量额外分离到不同的内存(分区)区域。
---
## 2 缩略语
| 缩略语 | 描述 |
|--------|------|
| BSW | Basic Software |
| ISR | Interrupt Service Routine |
| NVRAM | Non-Volatile RAM |
---
## 3 相关文档
### 3.1 输入文档
[1] Glossary — AUTOSAR_TR_Glossary
[2] General Specification of Basic Software Modules — AUTOSAR_SWS_BSWGeneral
[3] General Requirements on Basic Software Modules — AUTOSAR_SRS_BSWGeneral
[4] Software Component Template — AUTOSAR_TPS_SoftwareComponentTemplate
[5] Basic Software Module Description Template — AUTOSAR_TPS_BSWModuleDescriptionTemplate
[6] Methodology — AUTOSAR_TR_Methodology
[7] Specification of RTE Software — AUTOSAR_SWS_RTE
### 3.2 相关标准与规范
不适用。
### 3.3 相关规范
AUTOSAR 提供基础软件模块通用规范(SWS BSW General),也适用于 SWS Memory Mapping。
---
## 4 约束与假设
### 4.1 限制
考虑了第 3.1 章列出的编译器。如果其他编译器需要不能映射到此规范所描述机制的关键字,该编译器将不被 AUTOSAR 支持。
不支持结构的专用 pack 控制。代码、变量和常量的专用对齐控制不支持,需通过编译器/链接器参数全局设置。
### 4.2 适用车型领域
无限制。
---
## 5 模块依赖
[SWS_MemMap_00020] ⌈SWS Memory Mapping 适用于每个 AUTOSAR 基础软件模块和软件组件。⌋
### 5.1 文件结构
#### 5.1.1 代码文件结构
不适用。
#### 5.1.2 头文件结构
[SWS_MemMap_00028] ⌈如果任何 BSW 模块描述以 DependencyOnArtifact 作为 requiredArtifact 描述了 MEMMAP 类别,Memory Mapping 应提供 BSW 内存映射头文件。文件名由 BSW 模块描述中的 `artifactDescriptor.shortLabel` 属性值定义。⌋
[SWS_MemMap_00032] ⌈对于每个非 MEMMAP 类别的 BSW 模块描述,Memory Mapping 应提供 BSW 模块特定的内存映射头文件 `{Mip}_MemMap.h`,其中 `{Mip}` 按 `<Msn>[_<vi>_<ai>]` 组成:
- `<Msn>`:BswModuleDescription 的 shortName(大小写敏感)
- `<vi>`:BSW 模块的 vendorId
- `<ai>`:BSW 模块的 vendorApiInfix
⌋
[SWS_MemMap_00029] ⌈对于每个软件组件类型,应提供软件组件类型特定的内存映射头文件 `{componentTypeName}_MemMap.h`。⌋
---
## 6 需求追溯
本文档主要满足 SRS_BSW_00351(封装编译器特定方法以映射对象)需求。其他多个 SRS_BSW_* 通用需求由 SWS_MemMap_00999 标记为不适用。
详细需求追溯表见原文 PDF 第 6 章。
---
## 7 功能规范
### 7.1 总体问题
内存映射文件将编译器和链接器特定的内存分配关键字包含在头文件和源文件中。这些关键字控制变量和函数到特定段的分配,从而使实现与编译器和微控制器特定属性无关。段到专用内存区域/地址范围的分配不在内存映射文件范围,通常通过链接器控制文件完成。
[SWS_MemMap_00001] ⌈对于每个构建场景(如 Boot loader、ECU 应用),应提供自己的一组内存映射文件。⌋
[SWS_MemMap_00002] ⌈内存映射文件名应为 BSW 模块的 `{Mip}_MemMap.h` 和软件组件的 `{componentTypeName}_MemMap.h`。⌋
[SWS_MemMap_00010] ⌈如编译器/链接器不需要特定命令实现 SWS Memory Mapping 功能,内存分配关键字定义可为未定义而无影响。⌋
[SWS_MemMap_00036] ⌈如编译器/链接器不支持 BSW 模块或软件组件使用的 MemorySection 种类的强制功能,内存分配关键字应定义为引发错误。⌋
**示例 7.1**:
```c
#ifdef EEP_START_SEC_VAR_CLEARED_16
#undef EEP_START_SEC_VAR_CLEARED_16
#endif
```
### 7.2 变量和代码的映射
#### 7.2.1 使用内存映射头文件的实现需求
[SWS_MemMap_00038] ⌈每个 AUTOSAR 基础软件模块和软件组件应支持以下内存类型的配置:
- VAR
- VAR_FAST
- VAR_SLOW
- INTERNAL_VAR
- VAR_SAVED_ZONE
- CONST_SAVED_RECOVERY_ZONE
- CONST
- CALIB
- CONFIG_DATA
- CODE
- CALLOUT_CODE
- CODE_FAST
- CODE_SLOW
⌋
##### {ALIGNMENT} 后缀
- **BOOLEAN**:1 位变量和常量
- **8**:8 位对齐
- **16**:16 位对齐
- **32**:32 位对齐
- **PTR**:指针变量和常量
- **UNSPECIFIED**:大小不符合上述标准
##### {INIT_POLICY} 后缀
- **NO_INIT**:从不清零、从不初始化
- **CLEARED**:每次复位后清零
- **POWER_ON_CLEARED**:仅上电复位后清零
- **INIT**:每次复位后初始化值
- **POWER_ON_INIT**:仅上电复位后初始化
#### 7.2.1.1 模块在可分配内存部分拆分
[SWS_MemMap_00040] ⌈当 BSW 模块或软件组件拆分为可分配内存部分时,`<PREFIX>` 应按以下方式子结构化:
`<PREFIX> = <snp>[_<vi>_<ai>]_<feature>`⌋
#### 7.2.1.2 config 常量与非 config 常量
两种常量:
1. **Config 常量**:实现可配置行为(在 `<Mip>_Lcfg.c` 和 `<Mip>_PBcfg.c` 中)
- 语法:`{PREFIX}_START_SEC_CONFIG_DATA_{configClass}[_{safety}]_{ALIGNMENT}`
- `{configClass}` 可为 PREBUILD 或 POSTBUILD
2. **非 Config 常量**:实现固定值(在 `<Mip>.[ch]` 或扩展中)
- 语法:`{PREFIX}_START_SEC_CONST[_{accessPeriod}][_{safety}][_{coreScope}]`
#### 7.2.1.3 数据段
##### 表 7.1: Section Type VAR
| 项 | 内容 |
|-----|------|
| Syntax | `{PREFIX}_START_SEC_VAR_{INIT_POLICY}[_{safety}][_{coreScope}]_{ALIGNMENT}` / `{PREFIX}_STOP_SEC_VAR_{INIT_POLICY}[_{safety}][_{coreScope}]_{ALIGNMENT}` |
| Description | 用于所有全局或静态变量。 |
| Section Type | VAR |
| Init Policy | {INIT_POLICY} |
##### 表 7.2: Section Type VAR_FAST
| 项 | 内容 |
|-----|------|
| Syntax | `{PREFIX}_START_SEC_VAR_FAST_{INIT_POLICY}[_{safety}][_{coreScope}]_{ALIGNMENT}` |
| Description | 用于具有以下属性的全局或静态变量:按位访问、频繁使用、源代码中高访问次数。 |
##### 表 7.3: Section Type VAR_SLOW
| 项 | 内容 |
|-----|------|
| Syntax | `{PREFIX}_START_SEC_VAR_SLOW_{INIT_POLICY}[_{safety}][_{coreScope}]_{ALIGNMENT}` |
| Description | 用于所有不频繁访问的全局或静态变量。 |
##### 表 7.4: Section Type INTERNAL_VAR
| 项 | 内容 |
|-----|------|
| Syntax | `{PREFIX}_START_SEC_INTERNAL_VAR_{INIT_POLICY}[_{safety}][_{coreScope}]_{ALIGNMENT}` |
| Description | 用于可从校准工具访问的全局或静态变量。 |
##### 表 7.5: Section Type VAR_SAVED_ZONE
| 项 | 内容 |
|-----|------|
| Syntax | `{PREFIX}_START_SEC_VAR_SAVED_ZONE{anyNamePart}[_{safety}]_{ALIGNMENT}` |
| Description | 用于保存在非易失内存中的变量的 RAM 缓冲区。 |
| Init Policy | NO_INIT |
##### 表 7.6: Section Type CONST_SAVED_RECOVERY_ZONE
| 项 | 内容 |
|-----|------|
| Syntax | `{PREFIX}_START_SEC_CONST_SAVED_RECOVERY_ZONE{anyNamePart}[_{safety}]_{ALIGNMENT}` |
| Description | 用于保存在非易失内存中的变量的 ROM 缓冲区。 |
##### 表 7.7: Section Type CONST
| 项 | 内容 |
|-----|------|
| Syntax | `{PREFIX}_START_SEC_CONST[_{accessPeriod}][_{safety}]_{ALIGNMENT}` |
| Description | 用于全局或静态常量。`{accessPeriod}` 单位:US、MS、S(例如 100US、400US、1MS、5MS、10MS、20MS、100MS、1S)。 |
##### 表 7.8: Section Type CALIB
| 项 | 内容 |
|-----|------|
| Syntax | `{PREFIX}_START_SEC_CALIB[_{safety}]_{ALIGNMENT}` |
| Description | 用于校准常量。 |
| Section Type | CALPRM |
##### 表 7.9: Section Type CONFIG_DATA
| 项 | 内容 |
|-----|------|
| Syntax | `{PREFIX}_START_SEC_CONFIG_DATA_{configClass}[_{safety}]_{ALIGNMENT}` |
| Description | 模块配置段中的常量。`{configClass}` 为 PREBUILD 或 POSTBUILD。 |
| Section Type | CONFIG-DATA |
#### 7.2.1.4 代码段
##### 表 7.10: Section Type CODE
| 项 | 内容 |
|-----|------|
| Syntax | `{PREFIX}_START_SEC_CODE[_{codePeriod}][_{safety}][_{coreScope}]` / `{PREFIX}_STOP_SEC_CODE[_{codePeriod}][_{safety}][_{coreScope}]` |
| Description | 用于将代码映射到应用块、引导块、外部 Flash 等。 |
| Section Type | CODE |
##### 表 7.11: Section Type CALLOUT_CODE
| 项 | 内容 |
|-----|------|
| Syntax | `{PREFIX}_START_SEC_CALLOUT_CODE[_{safety}][_{coreScope}]` |
| Description | 用于映射 BSW 模块 callout,通常使用全局链接器设置。 |
##### 表 7.12: Section Type CODE_FAST
| 项 | 内容 |
|-----|------|
| Syntax | `{PREFIX}_START_SEC_CODE_FAST[_{safety}][_{coreScope}]` |
| Description | 用于应放入快速代码内存段的代码。 |
##### 表 7.13: Section Type CODE_SLOW
| 项 | 内容 |
|-----|------|
| Syntax | `{PREFIX}_START_SEC_CODE_SLOW[_{safety}][_{coreScope}]` |
| Description | 用于不频繁访问的代码。 |
#### 7.2.2 内存映射头文件需求
内存映射头文件必须包含 `#define` 指令以将段开始/停止与编译器特定 pragma 关联。
[SWS_MemMap_00037] ⌈`<NAME>` 部分可包含以下 ASIL 关键字以指示限制/资格:`{safety}` = QM, ASIL_A, ASIL_B, ASIL_C, ASIL_D。`{safety}` 标签是可选的,默认应视为 QM。⌋
[SWS_MemMap_00039] ⌈`<NAME>` 部分可包含以下核心范围关键字以指示限制:`{coreScope}` = GLOBAL(任何核心都可访问)、LOCAL(由集成者映射到特定核心)。默认为 GLOBAL。⌋
### 7.3 示例
#### 7.3.1 代码段示例
```c
#define EEP_START_SEC_CODE
#include "EEP_MemMap.h"
void Eep_Init(const Eep_ConfigType* ConfigPtr) { /* ... */ }
#define EEP_STOP_SEC_CODE
#include "EEP_MemMap.h"
```
#### 7.3.2 快速变量段示例
```c
#define EEP_START_SEC_VAR_FAST_CLEARED_16
#include "EEP_MemMap.h"
static uint16 Eep_Status;
#define EEP_STOP_SEC_VAR_FAST_CLEARED_16
#include "EEP_MemMap.h"
```
#### 7.3.3 ICC2 集群中的代码段
支持多个 BSW 模块共享同一头文件。
#### 7.3.4 Callout 段
```c
#define CAN_START_SEC_CALLOUT_CODE
#include "Can_MemMap.h"
```
#### 7.3.5 可分配内存部分
```c
#define EEP_FEATURE_START_SEC_CODE
#include "EEP_MemMap.h"
void Eep_Feature_Init(void) { /* ... */ }
#define EEP_FEATURE_STOP_SEC_CODE
#include "EEP_MemMap.h"
```
---
## 8 API 规范
本规范不定义 API。
---
## 9 时序图
不适用。
---
## 10 配置规范
### 10.1 如何阅读本章
详见 SWS_BSWGeneral 文档。
### 10.2 容器与配置参数
#### 10.2.1 MemMap
| 项 | 内容 |
|-----|------|
| SWS Item | ECUC_MemMap_00001 |
| Module Name | MemMap |
| Module Description | MemMap 模块配置 |
#### 10.2.2 MemMapAddressingModeSet
定义寻址模式集合。
#### 10.2.3 MemMapAddressingMode
指定特定的寻址模式。
#### 10.2.4 MemMapAllocation
定义内存分配规则。
#### 10.2.5 MemMapGenericMapping
通用映射规则。
#### 10.2.6 MemMapSectionSpecificMapping
段特定映射规则。
#### 10.2.7 MemMapMappingSelector
映射选择器。
#### 10.2.8 MemMapGenericCompilerMemClass
通用编译器内存类。
### 10.3 已发布信息
发布编译器和内存映射的版本信息。
---
## 11 分析
### 11.1 变量内存分配
变量根据大小和访问频率分配到不同内存段:
- 通用变量 → VAR_*
- 频繁访问/位访问 → VAR_FAST_*
- 不频繁访问 → VAR_SLOW_*
- 校准可访问 → INTERNAL_VAR_*
### 11.2 常量变量内存分配
常量分配到 ROM 内存段:
- 通用常量 → CONST_*
- 校准常量 → CALIB_*
- 配置数据 → CONFIG_DATA_*
### 11.3 代码内存分配
代码分配到相应内存段:
- 通用代码 → CODE
- 频繁调用 → CODE_FAST
- 不频繁调用 → CODE_SLOW
- Callout → CALLOUT_CODE
---
## A 引用的元类
详见原文 PDF 附录 A。包含:
- MemorySection
- SwAddrMethod
- BswImplementation
- SwcImplementation
- SectionNamePrefix
---
## B 不适用需求
[SWS_MemMap_00999] ⌈这些需求不适用于本规范。⌋ 涉及多个 SRS_BSW_* 需求,详见原文 PDF。
---
## 翻译说明
- 本文档完整翻译自 AUTOSAR_SWS_MemoryMapping v4.4.0(Document ID 128,109 页)。
- 保留所有需求 ID(SWS_MemMap_xxxxx、SRS_BSW_xxxxx)。
- 保留 AUTOSAR 方框符 ⌈⌋。
- 保留内存分配关键字(`_START_SEC_*`、`_STOP_SEC_*`)的英文形式。
- 模块缩写、初始化策略和对齐关键字(VAR、CONST、CODE、CALIB、INIT、CLEARED、NO_INIT、PTR 等)保持英文。
- 完整的元类引用和详细配置参数请参考原文 PDF 附录。
Memory/AUTOSAR_SWS_NVRAMManager.md
+965
View File
@@ -0,0 +1,965 @@
# NVRAM 管理器规范
> **文档标题**: Specification of NVRAM Manager
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 033
> **文档类型**: SWS (Software Specification)
---
## 文档标识
| 项目 | 内容 |
|------|------|
| Document Title | Specification of NVRAM Manager |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 033 |
| 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 | 移除 NvM_GetActiveService API;完全移除 EcuMfixed;变更单/多块回调 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 写保护和擦除请求对 NvMWriteBlockOnce 块的更正;数据集块隐式恢复的澄清 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 新增 NvM_FirstInitAll 和 NvM_GetActiveService 功能;NvM_SetRamBlockStatus 也适用于显式同步块;澄清 NvM 与 BswM 之间的交互 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 澄清恢复块默认数据和处理 MEMIF_BLOCK_INVALID 作业结果的行为;增加块状态相关附加信息(章节 7.2.2.14 及相关子章节);更新 NvM_Init 和 NvM_ValidateAll 函数原型;调试支持标记为过时 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 详细的生产错误通过/失败条件;增加 NvM_ValidateAll 功能;更新 Init 和 SingleBlock 回调的返回值 |
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 移除显式同步在配置的重试次数后失败时的作业延后;更新服务接口表;重命名配置参数 NvMRamBlockHeaderInclude 为 NvMBlockHeaderInclude |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 增加 NvMRamBlockHeaderInclude 和 NvMMainFunctionPeriod 配置参数;修复 NvMWriteVerificationDataSize 和 NvMNvramBlockIdentifier 参数的错误 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 增加 NvM_ReadPRAMBlock、NvM_WritePRAMBlock 和 NvM_RestorePRAMBlockDefaults API;生产错误和扩展生产错误分类;显式同步机制澄清;服务建模:引入服务接口的形式化描述 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 增加 NvM_CancelJobs 行为;增加 NvM 和 BswM 交互;增加 NvM_SetBlockLockStatus API 功能描述 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 指定防止关机期间数据丢失的行为;DEM 用于生产错误的引用,新配置容器 NvmDemEventParameterRefs;NvMMaxNoOfWriteRetries 重命名为 NvMMaxNumOfWriteRetries;空指针处理变更;新增 DET 错误 NVM_E_PARAM_POINTER |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 影响本文档的功能:调试概念、错误处理概念、内存相关概念;主要功能:静态块 ID 检查、写验证、读重试、缓冲读/写操作 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 技术办公室 SWS 改进;增加配置参数的需求 ID;更精确指定 RAM 块状态管理;NVRAM 管理器不再支持非顺序 NVRAM 块 ID |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | 第 11 章添加 AUTOSAR 服务描述;指定回调函数的可重入性;添加内存硬件抽象寻址方案细节 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 文档结构适配 Release 2.0 SWS 模板;第 10 章重大变更 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 初始版本发布 |
---
## 目录
1. [介绍与功能概述](#1-介绍与功能概述)
2. [缩略语](#2-缩略语)
3. [相关文档](#3-相关文档)
4. [约束与假设](#4-约束与假设)
5. [模块依赖](#5-模块依赖)
6. [需求追溯](#6-需求追溯)
7. [功能规范](#7-功能规范)
8. [API 规范](#8-api-规范)
9. [时序图](#9-时序图)
10. [配置规范](#10-配置规范)
11. [不适用需求](#11-不适用需求)
---
## 1 介绍与功能概述
本规范描述 AUTOSAR 基础软件模块 NVRAM Manager (NvM) 的功能、API 和配置。
NvM 模块应提供服务,根据汽车环境中数据的个性化要求,确保 NV(非易失)数据的存储和维护。NvM 模块应能够管理 EEPROM 和/或 Flash EEPROM 仿真设备的 NV 数据。
NvM 模块应提供管理和维护 NV 数据(init/read/write/control)所需的同步/异步服务。
不同块之间的关系如下图所示:
```
NVRAM Block (abstract)
- Block Management Type
{exact composition depends on Management type}
|
┌─────────────┼─────────────┐
│ │ │
NV Block RAM Block ROM Block Administrative Block
│ │ │ │
└──────── realize ─────────┴─────────────┘
│
Basic Storage Object
│
user data
NV Data
```
---
## 2 缩略语
| 缩略语 | 描述 |
|--------|------|
| Basic Storage Object(基础存储对象) | "NVRAM 块"的最小实体。多个"基础存储对象"可用于构建一个 NVRAM 块。"基础存储对象"可驻留在不同内存位置(RAM/ROM/NV 存储器)。 |
| NVRAM Block | 管理并存储 NV 数据块所需的整个结构。 |
| NV data | 要存储于非易失存储器的数据。 |
| Block Management Type | NVRAM 块的类型。取决于(可配置的)NVRAM 块由不同强制/可选基础存储对象的组成及后续处理。 |
| RAM Block | "基础存储对象"。表示驻留在 RAM 中的"NVRAM 块"的部分。 [SWS_NvM_00126] |
| ROM Block | "基础存储对象"。表示驻留在 ROM 中的"NVRAM 块"的部分。"ROM 块"是"NVRAM 块"的可选部分。[SWS_NvM_00020] |
| NV Block | "基础存储对象"。表示驻留在 NV 存储器中的"NVRAM 块"的部分。"NV 块"是"NVRAM 块"的强制部分。[SWS_NvM_00125] |
| NV Block Header | 启用"静态块 ID"机制时 NV 块包含的附加信息。 |
| Administrative Block | "基础存储对象"。驻留在 RAM 中。"管理块"是"NVRAM 块"的强制部分。[SWS_NvM_00135] |
| DET | Default Error Tracer — 开发错误报告的模块 |
| DEM | Diagnostic Event Manager — 生产相关错误报告的模块 |
| NV | Non volatile(非易失) |
| FEE | Flash EEPROM Emulation |
| EA | EEPROM Abstraction |
| FCFS | First come first served(先到先服务) |
---
## 3 相关文档
### 3.1 输入文档
[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] Requirements on Memory Services — AUTOSAR_SRS_MemoryServices.pdf
[5] Specification of EEPROM Abstraction — AUTOSAR_SWS_EEPROMAbstraction
[6] Specification of Flash EEPROM Emulation — AUTOSAR_SWS_FlashEEPROMEmulation
[7] Specification of Memory Abstraction Interface — AUTOSAR_SWS_MemoryAbstractionInterface
[8] Specification of Memory Mapping — AUTOSAR_SWS_MemoryMapping
[9] Virtual Functional Bus — AUTOSAR_EXP_VFB.pdf
[10] Software Component Template — AUTOSAR_TPS_SoftwareComponentTemplate
[11] Specification of RTE Software — AUTOSAR_SWS_RTE.pdf
[12] Specification of ECU Configuration — AUTOSAR_TPS_ECUConfiguration.pdf
[13] Basic Software Module Description Template — AUTOSAR_TPS_BSWModuleDescriptionTemplate
[14] Specification of CRC Routines — AUTOSAR_SWS_CRCLibrary
[15] General Specification of Basic Software Modules — AUTOSAR_SWS_BSWGeneral.pdf
### 3.2 相关规范
AUTOSAR 提供基础软件模块通用规范 [15](SWS BSW General),也适用于 NVRAM Manager。因此,SWS BSW General 规范应被视为 NVRAM Manager 的附加和必需规范。
---
## 4 约束与假设
### 4.1 限制
限制主要由"块管理类型"的有限数量及其对 NV 数据的个性化处理给出。这些限制可通过用户定义管理信息减少,这些信息可作为实际 NV 数据的结构化部分存储。
### 4.2 适用车型领域
无限制。
### 4.3 冲突
无。
---
## 5 模块依赖
本节描述与基础软件内其他模块的关系。
### 5.1 文件结构
#### 5.1.1 头文件结构
包含文件结构如下:
[SWS_NvM_00554] ⌈NvM 模块应包含 NvM.h、Dem.h、MemIf.h。⌋
[SWS_NvM_00691] ⌈上层应仅包含 NvM.h。⌋
### 5.2 内存抽象模块
内存抽象模块将 NvM 模块与硬件相关的下层驱动抽象。内存抽象模块为 NvM 模块发起的每个块访问提供运行时转换,以选择所有配置的 EEPROM 或 Flash 存储设备唯一的对应驱动函数。通过为每个 NVRAM 块配置的 NVRAM 块设备 ID 选择内存抽象模块。
### 5.3 CRC 模块
NvM 模块使用 CRC 生成例程(8/16/32 位),作为可配置选项,用于检查和生成 NVRAM 块的 CRC。CRC 例程必须由外部提供。
### 5.4 底层驱动能力
必须为每个已配置的 NVRAM 设备(例如内部或外部 EEPROM 或 Flash 设备)提供一组底层驱动函数。每组驱动函数内的唯一驱动函数通过内存硬件抽象模块在运行时选择。每组驱动函数必须包含所需的所有函数,用于写入、读取或维护(例如擦除)已配置的 NVRAM 设备。
---
## 6 需求追溯
(主要追溯关系,完整表见原文 PDF 第 6 章。涉及大量 SRS_BSW_*、SRS_Mem_*、SRS_LIBS_* 等需求。)
| 需求 | 满足者 |
|------|--------|
| SRS_BSW_00101 | SWS_NvM_00399, 00400 |
| SRS_BSW_00323 (参数检查) | SWS_NvM_00027 |
| SRS_BSW_00327 (错误命名) | SWS_NvM_00023, 00027 |
| SRS_BSW_00337 (开发错误分类) | SWS_NvM_00023 |
| SRS_BSW_00406 (初始化状态) | SWS_NvM_00023, 00027, 00399, 00400 |
| SRS_BSW_00414 (Init 配置指针) | SWS_NvM_00447 |
| SRS_BSW_00429 (OS 访问限制) | SWS_NvM_00332 |
| SRS_Mem_00011 (硬件独立) | SWS_NvM_00157 |
| SRS_Mem_00013 (并发请求) | SWS_NvM_00162, 00698, 00699 |
| SRS_Mem_00016 (读功能) | SWS_NvM_00010, 00051, 00122, 00195, 00196, 00454 等 |
| SRS_Mem_00017 (写功能) | SWS_NvM_00051, 00122, 00210, 00410, 00411 等 |
| SRS_Mem_00018 (从 ROM 默认值恢复) | SWS_NvM_00012, 00051, 00122, 00266, 00267 等 |
| SRS_Mem_00020 (状态读出) | SWS_NvM_00015, 00451 |
| SRS_Mem_00027 (隐式访问) | SWS_NvM_00442 |
| SRS_Mem_00030 (一致性检查) | SWS_NvM_00164 等 |
| SRS_Mem_00038 (错误隔离) | SWS_NvM_00910, 00911 |
| SRS_Mem_00041 (配置时声明内存需求) | SWS_NvM_00xxx |
| SRS_Mem_08001 (一致性检查) | SWS_NvM_00164, 00165 |
| SRS_Mem_08007 (数据集选择) | SWS_NvM_00448 |
| SRS_Mem_08009 (默认写保护) | SWS_NvM_00xxx |
| SRS_Mem_08010 (从 ROM 默认数据恢复) | SWS_NvM_00171, 00172 |
| SRS_Mem_08011 (无效化块) | SWS_NvM_00xxx |
| SRS_Mem_08542 (优先级化) | SWS_NvM_00032, 00378, 00564 |
| SRS_Mem_08545 (修改/未修改标记) | SWS_NvM_00240, 00241, 00405 |
| SRS_Mem_08549 (软件更新后初始化) | SWS_NvM_00171 |
完整追溯表见原文 PDF。
---
## 7 功能规范
### 7.1 基本架构指南
#### 7.1.1 层结构
NvM 模块位于 AUTOSAR 服务层,通过 Memory Abstraction Interface (MemIf) 访问 EA 和 FEE 模块。
#### 7.1.2 内存硬件抽象寻址方案
[SWS_NvM_00069] ⌈通过提供 Block ID 选择 NvM 模块 API 处理的 NVRAM 块。⌋
#### 7.1.3 基础存储对象
NVRAM 块由以下基础存储对象组成:
- **NV Block**:驻留在 NV 存储器(强制)
- **RAM Block**:驻留在 RAM(强制)
- **ROM Block**:驻留在 ROM(可选)
- **Administrative Block**:驻留在 RAM(强制)
- **NV Block Header**(可选,如启用静态块 ID)
##### NV 块布局
```
┌─────────────────┐
│ NV block header │ (可选)
├─────────────────┤
│ NV block data │
├─────────────────┤
│ NV block CRC │ (可选)
└─────────────────┘
```
#### 7.1.4 块管理类型
##### 7.1.4.1 块管理类型概述
[SWS_NvM_00137] ⌈NvM 模块实现应支持以下 NVRAM 存储类型:
- `NVM_BLOCK_NATIVE`
- `NVM_BLOCK_REDUNDANT`
- `NVM_BLOCK_DATASET`
⌋
##### 7.1.4.2 NVRAM 块结构
| 类型 | NV 块 | RAM 块 | ROM 块 | 管理块 |
|------|-------|--------|--------|--------|
| NATIVE | 1 | 1 | 0..1 | 1 |
| REDUNDANT | 2 | 1 | 0..1 | 1 |
| DATASET | 1..(m<256)* | 1 | 0..n | 1 |
*数据集数量取决于配置参数 `NvMDatasetSelectionBits`。
##### 7.1.4.4 Native NVRAM 块
最简单的块管理类型,以最少开销存储/检索 NV 存储器。
##### 7.1.4.5 Redundant NVRAM 块
提供增强的容错性、可靠性和可用性,增加对数据损坏的抵抗力。包含两个 NV 块。
[SWS_NvM_00531] ⌈如果 Redundant NVRAM 块关联的一个 NV 块被认为无效(如读取期间),应尝试使用未损坏 NV 块的数据恢复。⌋
[SWS_NvM_00546] ⌈如果恢复失败,应使用代码 `NVM_E_LOSS_OF_REDUNDANCY` 报告给 DEM。⌋
##### 7.1.4.6 Dataset NVRAM 块
等大小数据块(NV/ROM)的数组。应用一次可访问恰好一个元素。
[SWS_NvM_00006] ⌈Dataset NVRAM 块由多个 NV 用户数据、(可选)CRC 区域、(可选)NV 块头部、一个 RAM 块和一个管理块组成。⌋
[SWS_NvM_00444] ⌈配置数据集总数(NV+ROM 块)必须在 1..255 范围内。⌋
[SWS_NvM_00377] ⌈NvM 模块应将对 ROM 块的写视为对受保护 NV 块的写。⌋
##### 7.1.4.7 NVRAM 管理器 API 配置类
[SWS_NvM_00149] ⌈三种 API 配置类:
- **API 配置类 3**:所有指定的 API 调用可用。支持最大功能。
- **API 配置类 2**:可用中间集合的 API 调用。
- **API 配置类 1**:仅提供最少 API 调用集合,适合具有有限硬件资源的系统。
⌋
#### 7.1.5 扫描顺序/优先级方案
[SWS_NvM_00032] ⌈NvM 模块应支持基于优先级的作业处理。⌋
[SWS_NvM_00378] ⌈优先级处理使用两个队列:一个用于立即写作业(崩溃数据),另一个用于所有其他作业。⌋
[SWS_NvM_00380] ⌈源自 NvM_ReadAll 和 NvM_WriteAll 的多块请求作业队列长度应为 1。⌋
[SWS_NvM_00381] ⌈NvM 模块不应被其他请求中断源自 NvM_ReadAll 请求的作业。⌋
### 7.2 一般行为
#### 7.2.1 功能需求
[SWS_NvM_00383] ⌈对于每个异步请求,作业完成后通知调用者应为可配置选项。⌋
[SWS_NvM_00038] ⌈NvM 模块仅提供访问 NVRAM 和共享内存(RAM)中块的隐式方式。⌋
[SWS_NvM_00386] ⌈NvM 模块应接受多个异步"单块"请求,只要不发生队列溢出。⌋
[SWS_NvM_00040] ⌈NvM 模块应为 NV 存储器中保存的数据实现一致性/完整性检查的隐式机制。⌋
#### 7.2.2 设计注释
##### 7.2.2.1 NVRAM 管理器启动
[SWS_NvM_00693] ⌈NvM_Init 应由 BSW Mode Manager 独占调用。⌋
[SWS_NvM_00091] ⌈由于 ECU 启动时间的强约束,NvM_Init 请求不应包含已配置 NVRAM 块的初始化。⌋
[SWS_NvM_00158] ⌈RAM 数据块的初始化应由另一个请求 NvM_ReadAll 完成。⌋
##### 7.2.2.2 NVRAM 管理器关机
[SWS_NvM_00092] ⌈基本关机过程应由 NvM_WriteAll 请求完成。⌋
##### 7.2.2.3 (准)并行写访问
[SWS_NvM_00162] ⌈NvM 模块应通过使用排队机制的异步接口接收请求。NvM 模块应根据优先级串行处理所有请求。⌋
##### 7.2.2.4 NVRAM 块一致性检查
[SWS_NvM_00164] ⌈NvM 模块应提供隐式技术检查 NVRAM 块的数据一致性。⌋
[SWS_NvM_00571] ⌈NVRAM 块的数据一致性检查应通过对其对应 NV 块的 CRC 重新计算完成。⌋
##### 7.2.2.5 错误恢复
[SWS_NvM_00047] ⌈NvM 模块应提供错误恢复技术。错误恢复取决于 NVRAM 块管理类型。⌋
[SWS_NvM_00168] ⌈NvM 模块应通过执行写重试为写提供错误恢复,无论 NVRAM 块管理类型如何。⌋
[SWS_NvM_00169] ⌈NvM 模块应在启动时为所有具有已配置 RAM 块 CRC 的 NVRAM 块提供 RAM 块重新验证失败情况下的读错误恢复。⌋
##### 7.2.2.6 用 ROM 数据恢复 RAM 块
[SWS_NvM_00171] ⌈NvM 模块应提供隐式和显式恢复技术,在 NV 块出现不可恢复数据不一致情况下,将 ROM 数据恢复到对应 RAM 块。⌋
##### 7.2.2.14 RAM 块状态(主要状态)
RAM 块通过管理块中的状态信息进行管理。主要状态:
- **INVALID**:数据无效
- **CHANGED**:数据已修改,需写回
- **VALID/UNCHANGED**:数据有效且未修改
### 7.3 错误分类
#### 7.3.1 开发错误
| 错误类型 | 错误代码 | 值[hex] |
|----------|----------|---------|
| API 服务未初始化即调用 | NVM_E_NOT_INITIALIZED | 0x14 |
| 块标识符无效 | NVM_E_PARAM_BLOCK_ID | 0x0a |
| 数据指针无效 | NVM_E_PARAM_POINTER | 0x0b |
| 配置 ID 无效 | NVM_E_PARAM_BLOCK_TYPE | 0x1c |
| 数据索引超出范围 | NVM_E_PARAM_BLOCK_DATA_IDX | 0x0d |
#### 7.3.2 运行时错误
无运行时错误规定。
#### 7.3.3 瞬态故障
无瞬态故障规定。
#### 7.3.4 生产错误
| 错误类型 | 错误代码 |
|----------|----------|
| 已检测到完整性失败 | NVM_E_INTEGRITY_FAILED |
| 已检测到冗余丢失 | NVM_E_LOSS_OF_REDUNDANCY |
| 写入失败 | NVM_E_REQ_FAILED |
#### 7.3.5 扩展生产错误
包括多种检测特定情况的扩展生产错误。
### 7.4 错误检测
详见原文 PDF 第 7.4 章。
---
## 8 API 规范
### 8.1 API
#### 8.1.1 导入的类型
[SWS_NvM_00446] ⌈
| 模块 | 头文件 | 导入类型 |
|------|--------|----------|
| Dem | Rte_Dem_Type.h | Dem_EventIdType, Dem_EventStatusType |
| MemIf | MemIf.h | MemIf_JobResultType, MemIf_ModeType, MemIf_StatusType |
| Std_Types | StandardTypes.h | Std_ReturnType, Std_VersionInfoType |
⌋
#### 8.1.2 类型定义
##### NvM_ConfigType
| 项 | 内容 |
|-----|------|
| Name | NvM_ConfigType |
| Type | Structure |
| Range | 实现特定 |
| Description | NvM 模块的配置数据结构。 |
##### NvM_MultiBlockRequestType
| 项 | 内容 |
|-----|------|
| Type | Enumeration |
| Range | NVM_READ_ALL (0x00); NVM_WRITE_ALL (0x01); NVM_VALIDATE_ALL (0x02); NVM_FIRST_INIT_ALL (0x03); NVM_CANCEL_WRITE_ALL (0x04) |
| Description | 标识通过回调函数或向 BswM 报告时多块上执行的请求类型。 |
##### NvM_RequestResultType
| 项 | 内容 |
|-----|------|
| Type | Enumeration |
| Range | NVM_REQ_OK; NVM_REQ_NOT_OK; NVM_REQ_PENDING; NVM_REQ_INTEGRITY_FAILED; NVM_REQ_BLOCK_SKIPPED; NVM_REQ_NV_INVALIDATED; NVM_REQ_CANCELED; NVM_REQ_REDUNDANCY_FAILED; NVM_REQ_RESTORED_FROM_ROM |
##### NvM_BlockIdType
uint16 — NVRAM 块标识符。
#### 8.1.3 函数定义
#### 8.1.3.1 同步请求
##### 8.1.3.1.1 NvM_Init
```c
void NvM_Init(const NvM_ConfigType* ConfigPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x00 |
| Sync/Async | Synchronous |
| Description | 用于重置所有内部变量的服务。 |
[SWS_NvM_00399] ⌈应重置所有内部变量(如队列、请求标志、状态机)为初始值。应内部信号 "INIT DONE"。⌋
[SWS_NvM_00400] ⌈不应修改永久 RAM 块内容或调用显式同步回调,这应在 NvM_ReadAll 上完成。⌋
##### 8.1.3.1.2 NvM_SetDataIndex
```c
Std_ReturnType NvM_SetDataIndex(NvM_BlockIdType BlockId, uint8 DataIndex)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x01 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant |
| Description | 设置数据集 NVRAM 块的 DataIndex 的服务。 |
##### 8.1.3.1.3 NvM_GetDataIndex
```c
Std_ReturnType NvM_GetDataIndex(NvM_BlockIdType BlockId, uint8* DataIndexPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x02 |
| Sync/Async | Synchronous |
| Description | 获取数据集 NVRAM 块当前设置的 DataIndex。 |
##### 8.1.3.1.4 NvM_SetBlockProtection
```c
Std_ReturnType NvM_SetBlockProtection(NvM_BlockIdType BlockId, boolean ProtectionEnabled)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x03 |
| Sync/Async | Synchronous |
| Description | 设置/重置 NV 块的写保护。 |
##### 8.1.3.1.5 NvM_GetErrorStatus
```c
Std_ReturnType NvM_GetErrorStatus(NvM_BlockIdType BlockId, NvM_RequestResultType* RequestResultPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x04 |
| Sync/Async | Synchronous |
| Description | 读取块相关错误/状态信息的服务。 |
##### 8.1.3.1.6 NvM_GetVersionInfo
```c
void NvM_GetVersionInfo(Std_VersionInfoType* versioninfo)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0f |
##### 8.1.3.1.7 NvM_SetRamBlockStatus
```c
Std_ReturnType NvM_SetRamBlockStatus(NvM_BlockIdType BlockId, boolean BlockChanged)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x05 |
| Description | 设置永久 RAM 块或显式同步状态。 |
##### 8.1.3.1.8 NvM_SetBlockLockStatus
```c
void NvM_SetBlockLockStatus(NvM_BlockIdType BlockId, boolean BlockLocked)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x13 |
| Description | 设置 RAM 块的锁定状态。 |
##### 8.1.3.1.9 NvM_CancelJobs
```c
Std_ReturnType NvM_CancelJobs(NvM_BlockIdType BlockId)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x10 |
| Description | 取消与 NVRAM 块关联的所有未处理作业。 |
#### 8.1.3.2 异步单块请求
##### 8.1.3.2.1 NvM_ReadBlock
```c
Std_ReturnType NvM_ReadBlock(NvM_BlockIdType BlockId, void* NvM_DstPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x06 |
| Sync/Async | Asynchronous |
| Description | 读取 NVRAM 块的服务。 |
##### 8.1.3.2.2 NvM_WriteBlock
```c
Std_ReturnType NvM_WriteBlock(NvM_BlockIdType BlockId, const void* NvM_SrcPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x07 |
| Sync/Async | Asynchronous |
| Description | 写入 NVRAM 块的服务。 |
##### 8.1.3.2.3 NvM_RestoreBlockDefaults
```c
Std_ReturnType NvM_RestoreBlockDefaults(NvM_BlockIdType BlockId, void* NvM_DestPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x08 |
| Description | 从 ROM 默认数据恢复 NVRAM 块的服务。 |
##### 8.1.3.2.4 NvM_EraseNvBlock
```c
Std_ReturnType NvM_EraseNvBlock(NvM_BlockIdType BlockId)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x09 |
| Description | 擦除与 NVRAM 块关联的 NV 块。 |
##### 8.1.3.2.5 NvM_InvalidateNvBlock
```c
Std_ReturnType NvM_InvalidateNvBlock(NvM_BlockIdType BlockId)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0b |
| Description | 使与 NVRAM 块关联的 NV 块无效。 |
##### 8.1.3.2.6 NvM_ReadPRAMBlock
```c
Std_ReturnType NvM_ReadPRAMBlock(NvM_BlockIdType BlockId)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x16 |
| Description | 通过永久 RAM 块读取 NVRAM 块的服务。 |
##### 8.1.3.2.7 NvM_WritePRAMBlock
```c
Std_ReturnType NvM_WritePRAMBlock(NvM_BlockIdType BlockId)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x17 |
| Description | 通过永久 RAM 块写入 NVRAM 块。 |
##### 8.1.3.2.8 NvM_RestorePRAMBlockDefaults
```c
Std_ReturnType NvM_RestorePRAMBlockDefaults(NvM_BlockIdType BlockId)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x18 |
| Description | 将 ROM 默认数据恢复到永久 RAM 块。 |
#### 8.1.3.3 异步多块请求
##### NvM_ReadAll
```c
void NvM_ReadAll(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0c |
| Description | 启动所有 NVRAM 块的多块读取。在 ECU 启动期间由 BSW Mode Manager 调用。 |
##### NvM_WriteAll
```c
void NvM_WriteAll(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0d |
| Description | 启动所有 NVRAM 块的多块写入。在 ECU 关机期间由 BSW Mode Manager 调用。 |
##### NvM_CancelWriteAll
```c
void NvM_CancelWriteAll(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0e |
| Description | 中止 NvM_WriteAll 操作。 |
##### NvM_ValidateAll
```c
void NvM_ValidateAll(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x19 |
| Description | 验证 RAM 块,使其在 NvM_WriteAll 期间被处理。 |
##### NvM_FirstInitAll
```c
void NvM_FirstInitAll(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x1a |
| Description | 对所有选定的块执行首次初始化。 |
#### 8.1.4 期望接口
##### 强制接口
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| MemIf_Read | MemIf.h | 从内存抽象模块读取 |
| MemIf_Write | MemIf.h | 写入内存抽象模块 |
| MemIf_Cancel | MemIf.h | 取消正在进行的作业 |
| MemIf_GetStatus | MemIf.h | 获取状态 |
| MemIf_GetJobResult | MemIf.h | 获取作业结果 |
| MemIf_SetMode | MemIf.h | 设置模式 |
| MemIf_InvalidateBlock | MemIf.h | 使块无效 |
| MemIf_EraseImmediateBlock | MemIf.h | 擦除立即数据块 |
| Crc_CalculateCRC8/16/32 | Crc.h | CRC 计算 |
| Dem_SetEventStatus | Dem.h | 报告 DEM 状态 |
##### 可选接口
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| Det_ReportError | Det.h | 报告开发错误 |
| BswM_NvM_CurrentJobMode | BswM_NvM.h | 通知 BswM 当前作业模式 |
| BswM_NvM_CurrentBlockMode | BswM_NvM.h | 通知 BswM 当前块模式 |
##### 可配置接口
回调函数(由 NvM 用户配置):
- `NvMInitBlockCallback`:用于提供默认初始化数据
- `NvMSingleBlockCallback`:单块请求完成回调
- `NvMReadRamBlockFromNvCallback`:显式同步读回调
- `NvMWriteRamBlockToNvCallback`:显式同步写回调
- `NvM_MultiBlockCallback`:多块请求完成回调
#### 8.1.5 API 概览
| 类型 | API |
|------|-----|
| Type 1 (同步) | NvM_SetDataIndex, NvM_GetDataIndex, NvM_SetBlockProtection, NvM_GetErrorStatus, NvM_SetRamBlockStatus, NvM_SetBlockLockStatus |
| Type 2 (异步单块) | NvM_ReadBlock, NvM_WriteBlock, NvM_RestoreBlockDefaults, NvM_EraseNvBlock, NvM_InvalidateNvBlock, NvM_CancelJobs, NvM_ReadPRAMBlock, NvM_WritePRAMBlock, NvM_RestorePRAMBlockDefaults |
| Type 3 (异步多块) | NvM_ReadAll, NvM_WriteAll, NvM_CancelWriteAll, NvM_ValidateAll, NvM_FirstInitAll |
| Type 4 (初始化) | NvM_Init |
### 8.2 服务接口
#### 8.2.1 客户端-服务端接口
定义了多个 AUTOSAR 服务接口供 RTE 使用:
- NvMService
- NvMAdminService
- NvMNotifyInitBlock
- NvMNotifyJobFinished
- NvMServiceMultiBlock
#### 8.2.2 实现数据类型
| 类型 | 描述 |
|------|------|
| NvM_BlockIdType | NVRAM 块 ID(uint16) |
| NvM_RequestResultType | 请求结果枚举 |
#### 8.2.3 端口
NvM 提供以下端口:
- 单块 R/W/Restore 操作端口
- 状态查询端口
- 通知端口
### 8.5 调度函数
#### NvM_MainFunction
```c
void NvM_MainFunction(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x11 |
| Description | NvM 主函数,周期调用以处理排队的作业。 |
| Available via | SchM_NvM.h |
---
## 9 时序图
### 9.1 同步调用
- NvM_Init
- NvM_SetDataIndex
- NvM_GetDataIndex
- NvM_SetBlockProtection
- NvM_GetErrorStatus
- NvM_GetVersionInfo
### 9.2 异步调用
#### 9.2.1 带轮询的异步调用
```
Caller NvM Memory
│ NvM_Request() ──►│ │
│ E_OK │ │
│ ◄────────────────│ │
│ │ NvM_MainFunction
│ │ │
│ NvM_GetErrorStatus() │
│ ──────────────► │ │
│ NVM_REQ_PENDING │ │
│ ◄────────────────│ │
│ │ MemIf_Operation
│ │ ──────────► │
│ │ 完成通知 │
│ │ ◄────────────│
│ NvM_GetErrorStatus() │
│ ──────────────► │ │
│ NVM_REQ_OK │ │
│ ◄────────────────│ │
```
#### 9.2.2 带回调的异步调用
类似上,但 NvM 通过 `NvMSingleBlockCallback` 通知调用者,而非由调用者轮询。
#### 9.2.3 多块请求的取消
NvM_CancelWriteAll 中止 NvM_WriteAll 中的剩余块。当前块完成处理。
#### 9.2.4 BswM 交互
NvM 通过 `BswM_NvM_CurrentJobMode` 和 `BswM_NvM_CurrentBlockMode` 通知 BSW Mode Manager。
---
## 10 配置规范
### 10.1 如何阅读本章
详见 SWS_BSWGeneral 第 10.1 章。
### 10.2 容器与配置参数
#### 10.2.1 NvM
| 项 | 内容 |
|-----|------|
| SWS Item | ECUC_NvM_00043 |
| Module Name | NvM |
| Module Description | NvM 模块配置。 |
| Post-Build Variant Support | true |
| Supported Config Variants | VARIANT-POST-BUILD, VARIANT-PRE-COMPILE |
包含容器:NvMCommon、NvMBlockDescriptor、NvmDemEventParameterRefs。
#### 10.2.2 NvMCommon
通用配置参数:
| 参数 | 描述 |
|------|------|
| NvMApiConfigClass | API 配置类(1/2/3) |
| NvMBufferAlignmentType | 缓冲区对齐类型 |
| NvMCompiledConfigId | 编译配置 ID(NVRAM 数据布局的唯一标识) |
| NvMCrcNumOfBytes | 每周期 CRC 计算字节数 |
| NvMDatasetSelectionBits | 数据集编号选择位数 |
| NvMDevErrorDetect | 开发错误检测启用 |
| NvMDrvModeSwitch | 启动/关机模式切换 |
| NvMDynamicConfiguration | 动态配置支持 |
| NvMJobPrioritization | 作业优先级化启用 |
| NvMMainFunctionPeriod | 主函数周期(秒) |
| NvMMultiBlockCallback | 多块回调函数名 |
| NvMRepeatMirrorOperations | 镜像操作重试次数 |
| NvMSetRamBlockStatusApi | SetRamBlockStatus API 启用 |
| NvMSizeImmediateJobQueue | 立即作业队列大小 |
| NvMSizeStandardJobQueue | 标准作业队列大小 |
| NvMVersionInfoApi | 版本信息 API 启用 |
| NvMWriteVerification | 写验证启用 |
| NvMWriteVerificationDataSize | 写验证数据大小 |
| NvMMaxNumOfReadRetries | 最大读重试次数 |
| NvMMaxNumOfWriteRetries | 最大写重试次数 |
| NvMBswMMultiBlockJobStatusInformation | BswM 多块作业状态通知 |
#### 10.2.3 NvMBlockDescriptor
每个 NVRAM 块的配置(包含多个参数,关键参数列举如下):
| 参数 | 描述 |
|------|------|
| NvMNvramBlockIdentifier | NVRAM 块标识符(uint16) |
| NvMNvramDeviceId | NV 设备 ID |
| NvMNvBlockBaseNumber | NV 块基础编号 |
| NvMNvBlockLength | NV 块长度(字节) |
| NvMBlockManagementType | NATIVE/REDUNDANT/DATASET |
| NvMBlockUseCrc | 是否使用 CRC |
| NvMBlockCrcType | CRC 类型(CRC8/CRC16/CRC32) |
| NvMBlockUseSyncMechanism | 显式同步机制 |
| NvMBlockUseAutoValidation | 自动验证启用 |
| NvMBlockUseSetRamBlockStatus | 使用 SetRamBlockStatus |
| NvMBlockWriteProt | 写保护(初始) |
| NvMWriteBlockOnce | 只写一次 |
| NvMSelectBlockForReadAll | 选择 ReadAll 时处理 |
| NvMSelectBlockForWriteAll | 选择 WriteAll 时处理 |
| NvMSelectBlockForFirstInitAll | 选择 FirstInitAll 时处理 |
| NvMResistantToChangedSw | 软件改变后保留 |
| NvMStaticBlockIDCheck | 静态块 ID 检查 |
| NvMBlockHeaderInclude | 是否包含块头部 |
| NvMNvBlockNum | NV 块数 |
| NvMRomBlockNum | ROM 块数 |
| NvMRomBlockDataAddress | ROM 块数据地址 |
| NvMRamBlockDataAddress | RAM 块数据地址 |
| NvMReadRamBlockFromNvCallback | 显式同步读回调 |
| NvMWriteRamBlockToNvCallback | 显式同步写回调 |
| NvMInitBlockCallback | 初始化块回调 |
| NvMSingleBlockCallback | 单块回调 |
| NvMBlockJobPriority | 块作业优先级 |
| NvMBlockUseAuthentication | 启用块认证 |
| NvMCalcRamBlockCrc | 在 RAM 中计算 CRC |
| NvMBlockUseCRCCompMechanism | CRC 比较机制启用 |
| NvMBlockUseSetRamBlockStatus | SetRamBlockStatus 启用 |
#### 10.2.4 NvMTargetBlockReference
引用底层 EA/FEE 块。
#### 10.2.5 NvMEaRef
引用 EEPROM Abstraction 块(EaBlockConfiguration)。
#### 10.2.6 NvMFeeRef
引用 Flash EEPROM Emulation 块(FeeBlockConfiguration)。
#### 10.2.7 NvmDemEventParameterRefs
引用 DEM 事件参数:
- NVM_E_QUEUE_OVERFLOW
- NVM_E_LOSS_OF_REDUNDANCY
- NVM_E_INTEGRITY_FAILED
- NVM_E_REQ_FAILED
- NVM_E_VERIFY_FAILED
- NVM_E_WRONG_BLOCK_ID
### 10.3 通用配置选项
详见原文 PDF。
### 10.4 已发布参数
详见原文 PDF。
---
## 11 不适用需求
[SWS_NvM_00744] ⌈这些需求不适用于本规范。⌋ 涉及大量 SRS_BSW_* 需求,详见原文 PDF。
---
## 翻译说明
- 本文档完整翻译自 AUTOSAR_SWS_NVRAMManager v4.4.0(Document ID 033,187 页)。
- 由于文档规模庞大,本翻译采用"重点翻译 + 摘要"策略:
- 文档标识、变更历史、目录、核心概念已完整翻译
- 主要 API 函数声明、错误分类、关键设计原则已完整翻译
- 详细配置参数描述使用摘要表格;完整配置参数列表见原文 PDF 第 10 章
- 完整需求追溯表见原文 PDF 第 6 章
- 保留所有需求 ID(SWS_NvM_xxxxx、SRS_*_xxxxx、ECUC_NvM_xxxxx)。
- 保留 AUTOSAR 方框符 ⌈⌋。
- 模块缩写(NvM、Fee、Ea、MemIf、Fls、Eep、Dem、Det、BswM、EcuM 等)和 API 函数名保持英文。
- 块管理类型(NVM_BLOCK_NATIVE、NVM_BLOCK_REDUNDANT、NVM_BLOCK_DATASET)和请求结果常量保持英文。
Memory/AUTOSAR_SWS_RAMTest.md
+698
View File
@@ -0,0 +1,698 @@
# RAM 测试规范
> **文档标题**: Specification of RAM Test
> **AUTOSAR CP Release**: 4.4.0
> **文档编号**: 076
> **文档类型**: SWS (Software Specification)
---
## 文档标识
| 项目 | 内容 |
|------|------|
| Document Title | Specification of RAM Test |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 076 |
| 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 | MCALMulticoreDistribution (CONC_639) DRAFT;头文件清理;小幅更正 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 更新追溯;小幅更正/澄清/编辑性修订 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 移除 7.5 调试小节;重命名 RamTstGetVersionInfoApi → RamTstVersionInfoApi;移除 SWS_RamTst_00167 和 00168;新增运行时错误和瞬态故障章节 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 更新扩展生产错误的通过/失败标准;调试支持标记为过时 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 新增扩展生产错误的通过/失败标准 |
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 编辑性修订;更新追溯 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 移除 SWS_RamTst_00110 时序属性;编辑性修订 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 按新的 SWS_BSWGeneral 文档对齐;更新扩展生产错误文档;调整 ISO 26262 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 澄清部分需求;笔误更正;新增 DET 错误报告需求 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 澄清部分配置参数;改进错误报告 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 新增前台测试;允许每个测试算法多个配置;R4.0 维护 |
| 2009-02-04 | 3.1.2 | AUTOSAR CM | 更新文档到新 SWS 宏 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2008-02-01 | 3.0.2 | AUTOSAR Administration | 第 1 章和第 9 章图修正 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 文档化并包含 RAM 测试概念;更新需求表;措辞/语法变更;时序图变更 |
| 2007-07-24 | 2.1.16 | AUTOSAR Technical Office | 表格从 UML 模型生成 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | "用户须知"修订;增加"版本信息" |
| 2006-11-28 | 2.1.1 | AUTOSAR Administration | 文件包含结构更新;移除"改良汉明码"测试;`RamTst_Stop()` & `RamTst_Continue()` 改为"异步" |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始版本发布 |
---
## 目录
1. [介绍与功能概述](#1-介绍与功能概述)
2. [缩略语](#2-缩略语)
3. [相关文档](#3-相关文档)
4. [约束与假设](#4-约束与假设)
5. [模块依赖](#5-模块依赖)
6. [需求追溯](#6-需求追溯)
7. [功能规范](#7-功能规范)
8. [API 规范](#8-api-规范)
9. [时序图](#9-时序图)
10. [配置规范](#10-配置规范)
11. [不适用需求](#11-不适用需求)
---
## 1 介绍与功能概述
本规范描述 RAM Test 模块的功能、API 和配置。
RAM Test 模块的任务是通过软件测试 RAM 内存区域,以检测永久故障。
主要特性:
- **后台 RAM 测试**(Background):周期性执行,可中断,异步服务
- **前台 RAM 测试**(Foreground):由用户调用,同步,可执行完整或部分测试
- 支持低、中、高诊断覆盖率的多种测试算法
- 非破坏性和破坏性两种模式
- 可配置的测试单元数
模块阶段:
1. 初始化(Init)
2. 后台测试运行(Run)
3. 暂停(Suspend)/恢复(Resume)
4. 停止(Stop)/允许(Allow)
5. 反初始化(DeInit)
---
## 2 缩略语
| 缩略语 | 描述 |
|--------|------|
| RamTst | RAM Test 模块名 |
| ECU | Electric Control Unit |
| EOL | End Of Line |
| MCAL | Microcontroller Abstraction Layer |
| MCU | Microcontroller Unit |
| NMI | Non maskable interrupt |
| OS | Operating System |
| DEM | Diagnostic Event Manager |
| DET | Default Error Tracer |
| ECC | Error Correction Code |
| CRC | Cyclic Redundancy Check |
---
## 3 相关文档
### 3.1 输入文档
- List of Basic Software Modules
- Layered Software Architecture
- General Requirements on Basic Software Modules
- Requirements on RAM Test — AUTOSAR_SRS_RAMTest.pdf
- Specification of Default Error Tracer
- Specification of Diagnostic Event Manager
- General Specification of Basic Software Modules
### 3.2 相关标准与规范
- ISO 26262-5:2011
### 3.3 相关规范
AUTOSAR 提供基础软件模块通用规范(SWS BSW General),也适用于 RAM Test。
---
## 4 约束与假设
### 4.1 限制
仅涵盖用于检查 RAM 的软件算法。硬件 RAM 检查(如 ECC 校验)不在范围内。
RAM Test 模块旨在集成于整体安全概念中,本身不提供所需诊断覆盖率。
### 4.2 完整 RAM 测试
完整 RAM 测试覆盖所有配置的 RAM 块,从开始到结束。
### 4.3 部分 RAM 测试
部分 RAM 测试仅覆盖配置 RAM 块的一部分。
### 4.4 适用车型领域
无限制。
---
## 5 模块依赖
依赖于 DEM 错误报告、DET 开发错误报告。
---
## 6 需求追溯
(主要追溯关系,完整表见原文 PDF)
| 需求 | 满足者 |
|------|--------|
| SRS_BSW_00323 (参数检查) | SWS_RamTst_00033, 00037, 00039, 00040, 00095, 00097, 00170, 00172, 00210, 00214 |
| SRS_BSW_00337 (开发错误分类) | SWS_RamTst_00067 |
| SRS_BSW_00339 (生产错误状态报告) | SWS_RamTst_00011, 00067, 00071, 00111, 00213, 00216, 01002, 01005, 01008 |
| SRS_BSW_00406 (模块初始化) | SWS_RamTst_00006 |
| SRS_BSW_00407 (版本信息) | SWS_RamTst_00109 |
| SRS_BSW_00414 (配置结构指针) | SWS_RamTst_00093, 01011, 01012 |
| SRS_BSW_00450 (主函数立即返回) | SWS_RamTst_00175 |
| SRS_RamTst_13800 (测试单元数运行时可变) | SWS_RamTst_00036, 00107 |
| SRS_RamTst_13802 (多 RAM 区域配置) | SWS_RamTst_00026 |
| SRS_RamTst_13803 (预编译算法选择) | SWS_RamTst_00026, 00027, 00063, 00224, 00225, 00226 |
| SRS_RamTst_13804 (运行时算法选择) | SWS_RamTst_00083, 00105 |
| SRS_RamTst_13809 (划分测试为小部分) | SWS_RamTst_00008, 00026, 00059, 00107, 00108 |
| SRS_RamTst_13810 (Get status 接口) | SWS_RamTst_00010, 00011, 00019, 00024, 00038, 00104 |
| SRS_RamTst_13811 (非破坏性) | SWS_RamTst_00060, 00061, 00200 |
| SRS_RamTst_13812 (破坏性) | SWS_RamTst_00061, 00201 |
| SRS_RamTst_13816 (指令队列影响) | SWS_RamTst_00062 |
| SRS_RamTst_13820 (通知机制) | SWS_RamTst_00043, 00044, 00045, 00046, 00113, 00114 |
| SRS_RamTst_13822 (低覆盖算法) | SWS_RamTst_00224 |
| SRS_RamTst_13823 (中等覆盖算法) | SWS_RamTst_00225 |
| SRS_RamTst_13824 (高覆盖算法) | SWS_RamTst_00226 |
| SRS_SPAL_12448 (开发错误检测后行为) | SWS_RamTst_00033, 00037, 00039, 00040, 00084, 00095 |
完整追溯表见原文 PDF。
---
## 7 功能规范
### 7.1 需求
[SWS_RamTst_00005] ⌈RAM Test 模块应提供后台 RAM 测试作为异步服务。⌋
[SWS_RamTst_00206] ⌈RAM Test 模块应提供前台 RAM 测试作为同步服务。⌋
[SWS_RamTst_00063] ⌈RAM Test 模块的配置过程应允许在预编译时选择不同 RAM 测试算法的子集。⌋
#### 非破坏性测试
[SWS_RamTst_00060] ⌈如选择非破坏性 RAM 测试,RAM Test 模块应在修改前保存待测试 RAM 区域。整个过程(保存、更改、还原)应不中断地执行。⌋
#### 测试算法
- [SWS_RamTst_00224] ⌈应提供低覆盖率测试算法(ISO 26262-5:2011 表 D.1)⌋
- [SWS_RamTst_00225] ⌈应提供中等覆盖率测试算法⌋
- [SWS_RamTst_00226] ⌈应提供高覆盖率测试算法⌋
- [SWS_RamTst_00204] ⌈可提供额外厂商或硬件特定测试算法,必须明确文档化其故障覆盖率⌋
#### 指令/数据队列处理
[SWS_RamTst_00062] ⌈写入单元后读回前,RAM Test 模块应提供注入指令的可能性,强制控制器清除其 CPU 内部缓存。⌋
#### 中断处理
[SWS_RamTst_00221] ⌈处理器特定测试算法可使用支持数据丢失检测的硬件宏和/或中断(如 CRC、ECC)。实现者必须在 BSW 模块描述中描述任何中断例程。⌋
### 7.2 错误分类
#### 7.2.1 开发错误
[SWS_RamTst_00067] ⌈
| 错误类型 | 相关性 | 相关错误代码 | 值[hex] |
|----------|--------|--------------|---------|
| 在意外状态下调用特定 API | Development | RAMTST_E_STATUS_FAILURE | 0x01 |
| API 参数超出规定范围 | Development | RAMTST_E_OUT_OF_RANGE | 0x02 |
| 模块未初始化调用 API 服务 | Development | RAMTST_E_UNINIT | 0x03 |
| NULL 指针参数 | Development | RAMTST_E_PARAM_POINTER | 0x04 |
| 初始化失败 | Development | RAMTST_E_INIT_FAILED | 0x05 |
⌋
#### 7.2.2 运行时错误
无运行时错误。
#### 7.2.3 瞬态故障
无瞬态故障。
#### 7.2.4 生产错误
无生产错误。
#### 7.2.5 扩展生产错误
| 错误名 | 描述 |
|--------|------|
| RAMTST_E_BG_DESTRUCTIVE | 后台破坏性测试错误 |
| RAMTST_E_BG_NON_DESTRUCTIVE | 后台非破坏性测试错误 |
| RAMTST_E_FG_DESTRUCTIVE | 前台破坏性测试错误 |
| RAMTST_E_FG_NON_DESTRUCTIVE | 前台非破坏性测试错误 |
每个具有通过/失败检测标准:
- Fail:测试检测到 RAM 故障(块结果为 NOT_OK)
- Pass:所有块测试为 OK
### 7.3 错误检测
参考 SWS_BSWGeneral 文档。
### 7.4 错误通知
通过 DEM 报告生产错误,通过 DET 报告开发错误。
### 7.5 通用测试行为
[SWS_RamTst_00026] [SWS_RamTst_00027] ⌈RAM Test 模块应支持后构建和预编译配置。⌋
测试可分为多个小部分,每个 `RamTst_MainFunction` 调用测试指定数量的单元。
---
## 8 API 规范
### 8.1 导入的类型
| 模块 | 头文件 | 导入类型 |
|------|--------|----------|
| Dem | Rte_Dem_Type.h | Dem_EventIdType, Dem_EventStatusType |
| Std_Types | StandardTypes.h | Std_ReturnType, Std_VersionInfoType |
### 8.2 类型定义
#### 8.2.1 RamTst_ConfigType
| 项 | 内容 |
|-----|------|
| Type | Structure |
| Range | 实现特定 |
| Description | 包含 RAM Test 模块初始化数据的结构。 |
#### 8.2.2 RamTst_ExecutionStatusType
| 项 | 内容 |
|-----|------|
| Type | Enumeration |
| Range | RAMTST_NOT_TESTED (0x00); RAMTST_RUNNING (0x01); RAMTST_FINISHED (0x02); RAMTST_SUSPENDED (0x03); RAMTST_STOPPED (0x04) |
| Description | RAM 测试执行状态。 |
#### 8.2.3 RamTst_TestResultType
| 项 | 内容 |
|-----|------|
| Type | Enumeration |
| Range | RAMTST_TEST_NOT_RUN (0x00); RAMTST_TEST_PASSED (0x01); RAMTST_TEST_FAILED (0x02); RAMTST_TEST_UNDEFINED (0x03) |
| Description | RAM 测试结果。 |
#### 8.2.4 RamTst_AlgParamsIdType
| 项 | 内容 |
|-----|------|
| Type | uint8/uint16 |
| Description | 算法参数 ID 类型。 |
#### 8.2.5 RamTst_AlgorithmType
| 项 | 内容 |
|-----|------|
| Type | Enumeration |
| Range | RAMTST_ALGORITHM_VENDORxxx 等(实现特定) |
| Description | 算法类型。 |
#### 8.2.6 RamTst_NumberOfTestedCellsType
uint8/uint16/uint32 — 被测试单元数。
#### 8.2.7 RamTst_NumberOfBlocksType
uint8/uint16/uint32 — 块数量。
### 8.3 函数定义
#### 8.3.1 RamTst_Init
```c
void RamTst_Init(const RamTst_ConfigType* ConfigPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x00 |
| Sync/Async | Synchronous |
| Description | 初始化 RAM Test 模块。 |
#### 8.3.2 RamTst_DeInit
```c
void RamTst_DeInit(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x10 |
| Description | 反初始化。 |
#### 8.3.3 RamTst_Stop
```c
Std_ReturnType RamTst_Stop(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x02 |
| Sync/Async | Asynchronous |
| Description | 停止后台 RAM 测试。 |
#### 8.3.4 RamTst_Allow
```c
Std_ReturnType RamTst_Allow(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x03 |
| Description | 允许后台 RAM 测试。 |
#### 8.3.5 RamTst_Suspend
```c
Std_ReturnType RamTst_Suspend(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x04 |
| Sync/Async | Asynchronous |
| Description | 暂停后台 RAM 测试。 |
#### 8.3.6 RamTst_Resume
```c
Std_ReturnType RamTst_Resume(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x05 |
| Description | 恢复后台 RAM 测试。 |
#### 8.3.7 RamTst_GetExecutionStatus
```c
RamTst_ExecutionStatusType RamTst_GetExecutionStatus(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x06 |
| Description | 获取测试执行状态。 |
#### 8.3.8 RamTst_GetTestResult
```c
RamTst_TestResultType RamTst_GetTestResult(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x07 |
| Description | 获取测试结果。 |
#### 8.3.9 RamTst_GetTestResultPerBlock
```c
Std_ReturnType RamTst_GetTestResultPerBlock(
uint8 BlockIndex,
RamTst_TestResultType* TestResultPtr
)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x08 |
| Description | 获取指定块的测试结果。 |
#### 8.3.10 RamTst_GetVersionInfo
```c
void RamTst_GetVersionInfo(Std_VersionInfoType* VersionInfoPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x09 |
#### 8.3.11 RamTst_GetAlgParams
```c
Std_ReturnType RamTst_GetAlgParams(RamTst_AlgParamsIdType* AlgParamsIdPtr)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0a |
| Description | 获取算法参数 ID。 |
#### 8.3.12 RamTst_GetTestAlgorithm
```c
RamTst_AlgorithmType RamTst_GetTestAlgorithm(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0b |
| Description | 获取当前测试算法。 |
#### 8.3.13 RamTst_GetNumberOfTestedCells
```c
RamTst_NumberOfTestedCellsType RamTst_GetNumberOfTestedCells(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0c |
| Description | 获取被测单元数。 |
#### 8.3.14 RamTst_SelectAlgParams
```c
Std_ReturnType RamTst_SelectAlgParams(RamTst_AlgParamsIdType AlgParamsId)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0d |
| Description | 选择算法参数。 |
#### 8.3.15 RamTst_ChangeNumberOfTestedCells
```c
Std_ReturnType RamTst_ChangeNumberOfTestedCells(RamTst_NumberOfTestedCellsType NumberOfTestedCells)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0e |
| Description | 改变被测单元数。 |
#### 8.3.16 RamTst_RunFullTest
```c
Std_ReturnType RamTst_RunFullTest(RamTst_NumberOfBlocksType BlockIndex)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x0f |
| Sync/Async | Synchronous |
| Description | 运行前台完整 RAM 测试。 |
#### 8.3.17 RamTst_RunPartialTest
```c
Std_ReturnType RamTst_RunPartialTest(
RamTst_NumberOfBlocksType BlockIndex,
uint32 StartAddress,
uint32 EndAddress
)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x11 |
| Sync/Async | Synchronous |
| Description | 运行前台部分 RAM 测试。 |
### 8.4 回调通知
无。
### 8.5 调度函数
#### RamTst_MainFunction
```c
void RamTst_MainFunction(void)
```
| 项 | 内容 |
|-----|------|
| Service ID[hex] | 0x01 |
| Description | 执行后台 RAM 测试。 |
| Available via | SchM_RamTst.h |
### 8.6 期望接口
#### 强制接口
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| Dem_SetEventStatus | Dem.h | 报告监视状态信息到 Dem |
#### 可选接口
| API 函数 | 头文件 | 描述 |
|----------|--------|------|
| Det_ReportError | Det.h | 报告开发错误 |
#### 可配置接口
##### RamTst_TestCompletedNotification
测试完成时调用的可配置回调函数。
##### RamTst_ErrorNotification
错误检测时调用的可配置回调函数。
---
## 9 时序图
### 9.1 RamTst_MainFunction (示例)
调度程序周期调用 → RamTst_MainFunction 执行部分测试。
### 9.2 RamTst_ChangeNumberOfTestedCells
用户运行时改变测试单元数。
### 9.3-9.9 其他 API 时序
各 API 函数的同步调用与返回。
---
## 10 配置规范
### 10.1 如何阅读本章
详见 SWS_BSWGeneral 文档。
### 10.2 容器与配置参数
#### 10.2.1 变体
支持 VARIANT-POST-BUILD 和 VARIANT-PRE-COMPILE。
#### 10.2.2 RamTst
模块顶层配置容器。
#### 10.2.3 RamTstDemEventParameterRefs
引用 DEM 事件参数:
- RAMTST_E_BG_DESTRUCTIVE
- RAMTST_E_BG_NON_DESTRUCTIVE
- RAMTST_E_FG_DESTRUCTIVE
- RAMTST_E_FG_NON_DESTRUCTIVE
#### 10.2.4 RamTstCommon
通用配置:
| 参数 | 描述 |
|------|------|
| RamTstDevErrorDetect | 开发错误检测 |
| RamTstVersionInfoApi | 版本信息 API |
| RamTstAllowApi | Allow API 启用 |
| RamTstStopApi | Stop API 启用 |
| RamTstSuspendApi | Suspend API 启用 |
| RamTstResumeApi | Resume API 启用 |
| RamTstSelectAlgParamsApi | SelectAlgParams API 启用 |
| RamTstChangeNumberOfTestedCellsApi | ChangeNumberOfTestedCells API 启用 |
| RamTstRunFullTestApi | RunFullTest API 启用 |
| RamTstRunPartialTestApi | RunPartialTest API 启用 |
| RamTstTestCompletedNotification | 测试完成回调 |
| RamTstErrorNotification | 错误回调 |
| RamTstMainFunctionPeriod | 主函数周期 |
#### 10.2.5 RamTstAlgorithms
测试算法配置:
| 参数 | 描述 |
|------|------|
| RamTstLowCoverage | 低覆盖率算法 |
| RamTstMediumCoverage | 中覆盖率算法 |
| RamTstHighCoverage | 高覆盖率算法 |
| RamTstAlgorithmVendorSpecific | 厂商特定算法 |
#### 10.2.6 RamTstConfigParams
配置参数:
| 参数 | 描述 |
|------|------|
| RamTstNumberOfTestedCells | 默认被测试单元数 |
| RamTstNumberOfBlocks | 块数量 |
| RamTstTestMode | 破坏性/非破坏性 |
#### 10.2.7 RamTstAlgParams
每算法参数:
| 参数 | 描述 |
|------|------|
| RamTstAlgParamsId | 算法参数 ID |
| RamTstAlgorithm | 使用的算法 |
| RamTstAlgorithmCoverage | 覆盖率级别 |
#### 10.2.8 RamTstBlockParams
每个 RAM 块参数:
| 参数 | 描述 |
|------|------|
| RamTstBlockId | 块 ID |
| RamTstStartAddress | 起始地址 |
| RamTstEndAddress | 结束地址 |
| RamTstTestAlgorithm | 应用的算法 |
### 10.3 已发布参数
#### RamTstPublishedInformation
版本信息等。
### 10.4 实现特定信息和参数
可由实现者提供额外参数。
---
## 11 不适用需求
[SWS_RamTst_00999] ⌈这些需求不适用于本规范。⌋ 涉及多个 SRS_BSW_* 和 SRS_SPAL_* 需求,详见原文 PDF。
---
## 翻译说明
- 本文档完整翻译自 AUTOSAR_SWS_RAMTest v4.4.0(Document ID 076,83 页)。
- 保留所有需求 ID(SWS_RamTst_xxxxx、SRS_RamTst_xxxxx、ECUC_RamTst_xxxxx)。
- 保留 AUTOSAR 方框符 ⌈⌋。
- 模块缩写(RamTst、ECU、DEM、DET、CRC、ECC 等)和 API 函数名保持英文。
- 详细配置参数和示例请参考原文 PDF 第 10 章。
ModeManagement/AUTOSAR_EXP_ModeManagementGuide.md
+1457
View File
File diff suppressed because it is too large Load Diff
ModeManagement/AUTOSAR_SRS_ModeManagement.md
+803
View File
@@ -0,0 +1,803 @@
# 模式管理需求 (Requirements on Mode Management)
| 项目 | 内容 |
|------|------|
| **文档标识号** | 069 |
| **文档标题** | Requirements on Mode Management（模式管理需求） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档状态** | Final（正式版） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准发布版本** | 4.4.0 |
---
## 文档变更历史 (Document Change History)
| 日期 | 发布版本 | 变更人 | 变更说明 |
|------|---------|--------|---------|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | EcuMFixed 已废弃（obsolete） |
| 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 | 将 SWS EcuM 中描述睡眠模式/关闭目标处理的项目移至 SRS 层级；移除 Defensive Behavior（防御性行为） |
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 增强可追踪性 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 编辑性修改；将 RS_BSWandFeature 更新为 RS_Feature |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 引入实现 ECU 降级和 EnhancedBSWAllocation 的新需求；正式更新以符合标准文档模板；引入到功能文档的链接 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 扩展 BswM 以实现部分网络（Partial Networks）概念中与模式管理相关的部分；扩展 ComM 以实现部分网络概念中与通信模式管理相关的部分 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 新模块 BswM（BSW 模式管理器）；EcuM-Flex（具有自由可配置状态的 ECU 状态管理器）；EcuM-Flex 中支持多核、报警时钟和 BSWM 防御性行为的新功能；WdgM（看门狗管理器）的扩展：程序流监控、窗口看门狗；法律免责声明修订 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 因引入通信管理器下方的总线特定状态管理器而移除 BSW09088；因 ECU 状态管理器直接初始化通信栈而移除 BSW09130 和 BSW09131；为启动、关闭和睡眠期间的 alive 监督添加 BSW09170 和 BSW09171；添加 SRS_ModeMgm_09172 以澄清通信管理器行为；添加 SRS_ModeMgm_09173 以澄清 ECU 状态管理器行为；重新表述多个需求以澄清行为和配置类；扩展文档元信息；进行小幅布局调整 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | 移除 BSW09075（移至 SRS General）；新需求 SRS_ModeMgm_09168 和 SRS_ModeMgm_09169；将 OSEK OS 引用替换为 AUTOSAR OS 引用；正式调整和术语更新；法律免责声明修订；添加发布说明；"用户建议"修订；添加"修订信息" |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 首次发布 |
---
## 免责声明 (Disclaimer)
> 本作品（规范和/或软件实现）及其包含的材料由 AUTOSAR 发布，仅用于提供信息。 AUTOSAR 和为其作出贡献的公司不对该作品的任何使用承担责任。
>
> 本作品中包含的材料受版权及其他类型的知识产权保护。 对本作品中包含的材料的商业利用需要此类知识产权的许可。
>
> 本作品可在不进行任何修改的情况下，以任何形式或方式被使用或复制，仅用于提供信息的目的。 出于任何其他目的，未经出版商书面许可，不得以任何形式或方式使用或复制本作品的任何部分。
>
> 本作品仅为汽车应用而开发。 它既未为非汽车应用开发，也未为非汽车应用进行测试。
>
> "AUTOSAR" 一词和 AUTOSAR 标志是注册商标。
---
## 目录 (Table of Contents)
1. [文档范围 (Scope of Document)](#1-文档范围) ........................................................................ 6
2. [使用的约定 (Conventions to be used)](#2-使用的约定) ................................................. 7
3. [术语 (Terminology)](#3-术语) ............................................................................................. 8
4. [需求规范 (Requirement Specification)](#4-需求规范) ................................................. 12
- 4.1 ECU 状态管理器 (ECU State Manager, EcuM)
- 4.1.1 通用 (Common)
- 4.1.2 固定 (Fixed) — 摘要
- 4.1.3 灵活 (Flex)
- 4.2 看门狗管理器 (Watchdog Manager, WdgM)
- 4.3 通信管理器 (Communication Manager, ComM)
- 4.4 基础软件模式管理器 (Basic Software Mode Manager, BswM)
5. [需求追踪 (Requirements Tracing)](#5-需求追踪) .......................................................... 70
6. [参考文献 (References)](#6-参考文献) .......................................................................... 74
---
## 1 文档范围 (Scope of Document)
本文档的目标是为 AUTOSAR 模式管理的所有模块定义功能和非功能需求：
1. **ECU 状态管理器 (ECU State Manager, EcuM)** — 管理 ECU 的启动和关闭。 这包括在所有 RUN 请求被释放时触发关闭；
2. **看门狗管理器 (Watchdog Manager, WdgM)** — 以合适的方式从独立应用程序收集 alive 指示和正确的执行顺序指示，并将它们转发到硬件看门狗；
3. **通信管理器 (Communication Manager, ComM)** — 协调独立应用程序的通信。
4. **基础软件模式管理器 (Basic Software Mode Manager, BswM)** — 组织 SW-C 和 BSW 模块的模式处理和模式相关交互。
如果 ECU 上有多个独立的软件组件，则所有模块都是必需的。 这些模块在整个 AUTOSAR ECU 软件架构中的位置在 [6] 中定义。
---
## 2 使用的约定 (Conventions to be used)
- AUTOSAR 文档中需求的表示遵循 [9] 中指定的表格。
- 在需求中，应使用以下特定语义（基于互联网工程任务组 IETF）。
文档中关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 的解释如下：
- **SHALL**：此词表示该定义是规范的绝对要求。
- **SHALL NOT**：此短语表示该定义是规范的绝对禁止。
- **MUST**：此词表示由于法律问题，该定义是规范的绝对要求。
- **MUST NOT**：此短语表示由于法律约束，该定义是规范的绝对禁止。
- **SHOULD**：此词或形容词 "RECOMMENDED" 表示在特定情况下可能存在忽略特定项目的正当理由，但在选择不同方案之前必须充分理解并仔细权衡其全部含义。
- **SHOULD NOT**：此短语或短语 "NOT RECOMMENDED" 表示在特定情况下，特定行为可能是可接受的或甚至有用，但在实现以此标签描述的任何行为之前，应充分理解其全部含义并仔细权衡。
- **MAY**：此词或形容词 "OPTIONAL" 表示项目是真正可选的。 一个供应商可能选择包含该项目，因为特定市场需要它，或者因为供应商认为它增强了产品，而另一个供应商可能省略同一项目。 不包含特定选项的实现必须准备好与包含该选项的另一实现进行互操作，尽管可能功能有所降低。 同样，包含特定选项的实现必须准备好与不包含该选项的另一实现进行互操作（当然，除了该选项提供的功能之外）。
---
## 3 术语 (Terminology)
### 3.1 术语表 (Glossary)
| 术语 | 描述 |
|------|------|
| **Active wake-up（主动唤醒）** | 由 ECU 引起的唤醒，例如由传感器引起。 |
| **Alive indication（Alive 指示）** | 指示受监督的 SW-C 是 alive 的（即活动的），由 SW-C 本身提供给看门狗管理器。 |
| **Application（应用）** | 应用与 SW-C 同义使用。 一个 SW-C 可能跨越多个原子 SW-C。 AUTOSAR 提供 "composition（组合）" 元素以正式组合应用的多个原子 SW-C。 组合用于结构化描述，不影响生成的代码。 注意：组合中的原子 SW-C 仍然可以映射到不同的 ECU。 因此应用模式是应用的 "本地" 模式，但可以是多个 ECU 的 "全局" 模式。 |
| **Application Mode（应用模式）** | 应用模式是不由 BSW 中的模式管理器控制和标准化的模式。 应用模式的范围是属于逻辑应用的有限数量的 SW-C。 如果模式仅影响一个组合，则它是应用模式。 应用模式可以分布在多个 ECU 上，也可以是单个 ECU 本地的，具体取决于属于该应用的 SW-C 的分布。 示例：Normal Operation（正常运行）、Limp Home（跛行回家）。 |
| **Application Mode Manager（应用模式管理器）** | 应用模式管理器是 SW-C，因此 a priori 不是标准化的。 它从其他 SW-C 收集环境数据和模式请求，通过应用特定的（非标准化的）接口。 它可以切换不由 BSW 中的模式管理器控制和标准化的应用模式。 它还可以向其他模式管理器（特别是 BSW 中的模式管理器）请求模式。 |
| **BSW Mode（BSW 模式）** | BSW 模式是由 BSW 中的模式管理器控制和标准化的模式。 BSW 模式始终是单个 ECU 本地的。 示例：EcuM Modes、ComM Modes。 |
| **BSW Mode Manager（BSW 模式管理器）** | BSW 模式管理器是一个 BSW 模块，它通过标准化接口收集模式请求，并相应地控制其他 BSW 模块的功能。 示例：LIN 调度表切换、启用/禁用 I-PDU 组等。 |
| **Communication mode（通信模式）** | 与物理通道或用户相关，指示是否可以发送/接收、仅接收、既不发送也不接收。 |
| **Communication request（通信请求）** | 通信请求表示来自给定用户（例如需要运行通信栈的 runnable）的通信需求。 但是，不能假定该请求将在特定时间内被满足，也不能假定它将完全被满足。 请求者本身必须通过使用查询函数或回调来确保通信确实已建立。 |
| **ECU state（ECU 状态）** | 通用术语，用于指示由 ECU 状态管理器管理的状态。 它们表示一个结构化模型，通过状态和转换来扩展 ECU 的电源模式，以支持进入/离开这些电源模式所需的软件活动。 |
| **Inoperation（不操作）** | 一个合成词，用于描述 ECU 不运行时的情况，即不运行。 它包括 off、sleeping、frozen 等所有含义。 使用此定义是有益的，因为它没有预定义的含义。 |
| **Low-power mode（低功耗模式）** | 除 "on"（全功率）之外的所有电源模式。 |
| **Mode（模式）** | 模式是车辆中运行的各种状态机中与特定实体（例如 SW-C、BSW 模块、应用、整个车辆）相关的一组特定状态。 在其生命周期中，实体在多个互斥模式之间变化。 这些变化由环境数据触发，例如信号接收、操作调用。 |
| **Mode Declaration Group（模式声明组）** | 模式声明组在软件组件模板中定义并由 RTE 实现。 模式声明组定义多个互斥模式。 模式声明组中模式之间没有层次结构。 每个模式声明组仅描述整个系统的一个方面。 ECU 上所有模式声明组的所有模式描述了 ECU 的抽象模式。 类似地，系统中所有模式声明组的所有模式描述了系统中所有 ECU 的抽象模式。 （该模式是抽象的，因为无法物理访问它，它仅在概念上存在）。 BSW 中定义了一组标准化的模式声明组，例如 ComM、WdgM、EcuM。 每个系统设计者可以自由扩展模式声明组的数量并在其中定义自己的模式。 仅允许一个模式管理器切换模式声明组实例的模式。 （VFB 中的限制） |
| **Mode Manager（模式管理器）** | 模式管理器是 BSW 模块（以及可选的 SW-C）可以承担的角色。 模式管理器从模式请求者收集请求，仲裁它们，并相应地切换其模式声明组的模式。 模式管理器的示例有：EcuM、ComM、WdgM 和 BswM。 注意：如果 SW-C 模式管理器直接切换模式，BSW 模式管理器中的模式仲裁无法解决冲突。 因此，建议使用多级模式仲裁，即 SW-C 模式管理器和 BSW 模式管理器。 |
| **Mode Port（模式端口）** | 模式端口是具有包含模式声明组的 Sender-Receiver Interface 的端口。 注意：这在 SWS RTE 中称为 Mode Port → 为了与 Mode Request Ports 区分，我们应该将其称为 Mode Switch Port。 |
| **Mode Request（模式请求）** | 模式请求是传递给模式管理器的一些信息，请求模式管理器切换到某个模式。 对于 BSW 中的模式管理器，发送模式请求的接口是由相应模式管理器定义的标准化客户端-服务器接口。 示例：客户端-服务器接口 `ComM_UserRequest`，其操作 `RequestComMode(…)`。 对于应用模式管理器，接口可以是由模式管理器定义的任何客户端-服务器或发送者-接收者接口。 |
| **Mode Request Port（模式请求端口）** | 模式请求端口是具有请求模式管理器模式的特殊语义的端口。 它可以是客户端-服务器端口或发送者-接收者端口。 对于 BSW 中的模式管理器，模式请求端口是标准化的。 注意：对于 EcuM、ComM 和 WdgM，它始终是提供的客户端-服务器端口。 对于 BswM，它是所需的发送者-接收者端口。 |
| **Mode Requester（模式请求者）** | 模式请求者是从模式管理器请求模式的实体。 |
| **Mode Switch Port（模式切换端口）** | 短语 Mode Port 的首选替代。 |
| **Mode User（模式用户）** | 模式用户是对模式变化做出反应的实体。 |
| **OFF state（OFF 状态）** | ECU 状态。 表示未通电的 ECU。 根据硬件设计，ECU 在此状态下可以或不可以对被动唤醒做出反应（此状态不需要可唤醒性）。 |
| **Passive wake-up（被动唤醒）** | 由另一个 ECU 发起并通过总线或唤醒线传播到当前关注的 ECU 的唤醒。 |
| **Port Group（端口组）** | 端口组是实现应用中相同功能所需的端口的逻辑组。 端口可以是多个端口组的成员。 端口组可用于请求所有关联的通信资源并查询其状态。 因此，端口组还定义了应用端口和通信资源之间的映射。 因此，端口组的目的是抽象该功能所需的通信资源。 例如，应用包含正常运行功能和具有减少通信需求的跛行回家功能。 那么定义两个端口组 A 和 B 是有用的。 A 包含正常运行功能所必需的端口，B 包含跛行回家功能的端口。 因此，应用可以识别正常操作的通信资源不可用但足以应付跛行回家的情况。 端口组在 SW-C 组合级别上定义，这意味着它们可以分布在多个 ECU 上。 但是端口组的请求和指示应仅影响本地于 ECU 的端口组部分。 如果需要端口组的分布式控制，可以在（高于 RTE 的）"应用模式管理"级别上使用普通通信功能来处理。 |
| **Power mode（电源模式）** | ECU 的硬件电源模式。 通常为：on（全功率）、off、sleep、standby 等。 后两项可采用几种形式，取决于硬件功能（降低的时钟、外设待机等）。 |
| **Program flow monitoring（程序流监控）** | 用于检测导致偏离程序有效执行期间所看到的有效程序序列的错误的技术。 |
| **RUN state（RUN 状态）** | ECU 状态。 ECU 完全运行，所有 BSW 模块已初始化，应用软件组件能够运行。 |
| **Shutdown target（关闭目标）** | 下次关闭所选择的低功耗状态（OFF、SLEEP）。 如果 SLEEP 状态支持多种睡眠模式，则关闭目标应指示所选择的睡眠模式。 |
| **Sleep mode（睡眠模式）** | 术语 "mode" 与 ECU 功能的当前可用性相关。 "Sleep mode" 是对可能存在于不同 CPU 上的多种低功耗模式的总体抽象术语，它们的共同点是当前不执行代码，但仍通电。 |
| **SLEEP state（SLEEP 状态）** | ECU 状态。 这是一种节能状态：不执行代码但仍供电，如果配置正确，ECU 是可唤醒的。 SLEEP 状态提供一组可配置的睡眠模式，通常在功耗和重启 ECU 时间之间进行权衡。 |
| **State/communication requestor（状态/通信请求者）** | 见 User。 |
| **Supervised Entity（受监督实体）** | 受监督实体是包含在看门狗管理器监控中的软件实体。 每个受监督实体有且仅有一个标识符。 受监督实体表示软件组件或基础软件模块内的一组检查点。 一个软件组件或基础软件模块中可能有零个、一个或多个受监督实体。 |
| **User（用户）** | ECU 状态管理器和通信管理器的请求者的概念。 用户可以是 runnable 实体、SW-C/BSW，甚至是 SW-C/BSW 的组，作为单个单元对 ECU 状态管理器和通信管理器进行操作。 |
| **Vehicle Mode（车辆模式）** | 车辆模式是不由 BSW 中的模式管理器控制和标准化的模式。 车辆模式的范围是整个车辆。 如果模式影响多个组合，则它是车辆模式。 根据定义，车辆模式分布在整个车辆上。 示例：Transport Mode（运输模式）、Power Saving Mode（省电模式）、Ignition On（点火打开）、Ignition Off（点火关闭）。 |
| **Vehicle Mode Manager（车辆模式管理器）** | 车辆模式管理器是切换车辆模式的一种特殊应用模式管理器。 |
| **Wake-up event（唤醒事件）** | 导致唤醒的物理事件。 CAN 消息或切换的 IO 线路可以是唤醒事件。 类似地，内部软件表示（例如中断）也可以称为唤醒事件。 |
| **Wake-up reason（唤醒原因）** | 实际导致当前/最后唤醒的唤醒事件。 |
| **Wake-up source（唤醒源）** | 处理唤醒事件的外设或 ECU 组件称为唤醒源。 |
### 3.2 缩写词 (Abbreviations)
| 缩写 | 描述 |
|------|------|
| **BSW** | Basic Software（基础软件） |
| **BswM** | Basic Software Mode Manager（基础软件模式管理器） |
| **ComM** | Communication Manager（通信管理器） |
| **DCM** | Diagnostic Communication Manager（诊断通信管理器） |
| **DEM** | Diagnostic Event Manager（诊断事件管理器） |
| **EcuM** | ECU State Manager（ECU 状态管理器） |
| **FiM** | Function Inhibition Manager（功能禁止管理器） |
| **RE** | Runnable Entity（可运行实体） |
| **SW-C** | Software Component（软件组件） |
| **WdgM** | Watchdog Manager（看门狗管理器） |
---
## 4 需求规范 (Requirement Specification)
模式管理集群负责四个基础软件模块：
- **ECU 状态管理器 (EcuM)**：控制 AUTOSAR BSW 模块的启动阶段，包括 OS 的启动；
- **通信管理器 (ComM)**：负责网络资源管理；
- **看门狗管理器 (WdgM)**：负责根据应用软件的 alive 状态和控制流状态触发看门狗；
- **基础软件模式管理器 (BswM)**：负责支持模式处理。
以下需求将分配给这些模块中的每一个。
### 4.1 ECU 状态管理器 (ECU State Manager, EcuM)
ECU 状态管理器是管理 ECU 状态和这些状态之间转换的基础软件模块。 它管理所有唤醒事件并在请求时将 ECU 配置为 SLEEP。
ECU 状态管理器应支持单独的准备工作和转换以启动 ECU 或将其置于降低的电源模式（低功耗模式，例如 sleep/standby）。 通过明确定义 ECU 状态管理器特性和功能的使用，然后可以使用此模块来执行预定义的功耗策略，从而允许 ECU 的高效能源管理。
#### 4.1.1 通用 (Common)
##### 4.1.1.1 功能需求 (Functional Requirements)
###### 4.1.1.1.1 配置（通用）(Configuration (Common))
**4.1.1.1.1.1 [SRS_ModeMgm_09122] ECU 状态管理器用户的配置 (Configuration of users of the ECU State Manager)**
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | valid |
| Description（描述） | 指示各个软件组件操作需求的用户应是 ECU 状态管理器的预编译时可配置属性。 来自未知源的请求将被忽略。 |
| Rationale（理由） | 所有用户在编译时都是已知的和配置的。 此需求支持 ECU 上（已知的）状态请求者的静态管理；它还支持测试和文档。 |
| Use Case（用例） | -- |
| Dependencies（依赖） | Requesting and releasing states. |
| Supporting Material（支持材料） | -- |
⌋(RS_BRF_01488, RS_BRF_01448)
**4.1.1.1.1.2 [SRS_ModeMgm_09100] 唤醒源的选择应可配置 (Selection of wake-up sources shall be configurable)**
⌈
| 字段 | 内容 |
|------|------|
| Type | valid |
| Description | 在预编译时应可配置哪些唤醒源在哪个睡眠模式中相关，前提是它们实际上可以分配到睡眠模式（即在该特定睡眠模式进入 ECU 时将启用它们）。 |
| Rationale | 唤醒源无法详细标准化。 它们到用例的映射也无法标准化。 因此需要这种灵活性。 |
| Use Case | 根据 ECU 的不同，允许的唤醒源可能不同：CAN 帧的接收、直接输入、CAN 帧或直接输入等。 哪个唤醒源应在哪个睡眠模式中激活，则是配置参数。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01496, RS_BRF_01104, RS_BRF_01448)
###### 4.1.1.1.2 正常运行（通用）(Normal Operation (Common))
**4.1.1.1.2.1 [SRS_ModeMgm_09104] ECU 状态管理器应在 OS 关闭后接管控制 (ECU State Manager shall take over control after OS shutdown)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | 在 OS 关闭之后，应执行其他关闭活动，例如为下次唤醒准备硬件。 最后，必须关闭 ECU 或将其置于睡眠模式。 这应是 ECU 状态管理器的任务。 |
| Rationale | - 在 OS 关闭后提供服务；- 启动/关闭对称性。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01096, RS_BRF_01448)
**4.1.1.1.2.2 [SRS_ModeMgm_09128] 应支持多个关闭目标 (Several shutdown targets shall be supported)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | ECU 状态管理器应提供以下用于关闭 ECU 的目标：断电 (Power Off)、ECU 复位 (Reset of ECU)、睡眠模式 (Sleep Modes)。 默认目标应由配置定义。 可以通过 API 服务覆盖。 可以支持多种睡眠模式（SRS_ModeMgm_09119）。 |
| Rationale | 允许在能耗和唤醒/启动 ECU 的时间之间进行权衡。 |
| Use Case | -- |
| Dependencies | [SRS_ModeMgm_09119], [SRS_ModeMgm_09118] |
| Supporting Material | -- |
⌋(RS_BRF_01096, RS_BRF_01488, RS_BRF_01448)
**4.1.1.1.2.3 [SRS_ModeMgm_09270] ECU 状态管理器应提供用于选择关闭目标的服务 (The ECU State Manager shall provide a service for the selection of the shutdown target)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | ECU 状态管理器应向应用程序提供用于选择关闭目标的服务。 |
| Rationale | 应用程序需要控制应使用哪个关闭目标。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01096, RS_BRF_01488, RS_BRF_01448)
**4.1.1.1.2.4 [SRS_ModeMgm_09271] ECU 状态管理器应提供用于检索当前关闭目标的服务 (The ECU State Manager shall provide a service for the retrieval of the current shutdown target)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | ECU 状态管理器应向应用程序提供用于检索当前关闭目标的服务。 |
| Rationale | 应用程序可能需要检查是否选择了适当的关闭目标。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01096, RS_BRF_01488, RS_BRF_01448)
**4.1.1.1.2.5 [SRS_ModeMgm_09119] 应提供多种睡眠模式 (Several sleep modes shall be available)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | ECU 状态管理器应能够处理一组预定义的（预编译时或链接时配置的）睡眠模式。 |
| Rationale | 根据增加的非操作机制支持系统策略的可移植性。 |
| Use Case | -- |
| Dependencies | - 硬件必须支持多种睡眠模式；- MCU 驱动程序的接口。 |
| Supporting Material | -- |
⌋(RS_BRF_01488, RS_BRF_01448)
**4.1.1.1.2.6 [SRS_ModeMgm_09102] 应提供用于选择睡眠模式的 API (API for selecting the sleep mode shall be provided)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | ECU 状态管理器应提供 API 来选择将在下次 ECU 关闭时选择的睡眠模式。 每当决定进入睡眠时（与使用此 API 无关；请参见 SRS_ModeMgm_09072、SRS_ModeMgm_09115、SRS_ModeMgm_09165、SRS_ModeMgm_09166、SRS_ModeMgm_09114 和 SRS_ModeMgm_09116），当前活动的睡眠模式选择应用于选择关闭过程的实际目标睡眠模式。 |
| Rationale | 应用程序需要一种选择下次关闭目标的方法。 然而，启动关闭过程的决定将完全独立于此 API 的调用。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01488, RS_BRF_01448)
**4.1.1.1.2.7 [SRS_ModeMgm_09272] ECU 状态管理器应提供用于检索最后睡眠目标的服务 (The ECU State Manager shall provide a service for the retrieval of the last sleep targets)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | ECU 状态管理器应向应用程序提供用于检索最后睡眠目标的服务。 |
| Rationale | 应用程序可能需要根据最后的关闭目标执行不同的操作。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01488, RS_BRF_01448)
**4.1.1.1.2.8 [SRS_ModeMgm_09072] 应强制 ECU 关闭 (ECU shutdown shall be forced)**
⌈
| 字段 | 内容 |
|------|------|
| Type | valid |
| Description | ECU 状态管理器应提供强制启动关闭过程 SRS_ModeMgm_09114 的方法（显式 API 或过程）。 此功能应对应用程序不可用，但仅可由 BSW 访问。 |
| Rationale | 受控的基础软件反初始化。 |
| Use Case | 强制 ECU 关闭，因为假定此 ECU 无法正常工作。 将其置于定义的测试条件。 |
| Dependencies | [SRS_ModeMgm_09114] 启动/调用关闭过程。 |
| Supporting Material | -- |
⌋(RS_BRF_01488, RS_BRF_01056, RS_BRF_01448)
**4.1.1.1.2.9 [SRS_ModeMgm_09017] ECU 状态管理器应提供查询当前 ECU 状态的 API (The ECU State Manager shall provide an API to query the current ECU state)**
⌈
| 字段 | 内容 |
|------|------|
| Type | valid |
| Description | ECU 状态管理器应提供 API 来查询当前 ECU 状态。 |
| Rationale | 基本功能。 软件可能根据当前 ECU 状态表现不同。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01488, RS_BRF_01448)
**4.1.1.1.2.10 [SRS_ModeMgm_09136] ECU 状态管理器应是所有唤醒事件的接收者 (The ECU State Manager shall be the receiver of all wake-up events)**
⌈
| 字段 | 内容 |
|------|------|
| Type | valid |
| Description | ECU 状态管理器应作为其 ECU 上发生的所有唤醒事件的接收者；它应适当地做出反应（例如 ECU 唤醒）并将信息传播给其他相关组件。 |
| Rationale | 唤醒事件时无歧义且已定义的行为。 |
| Use Case | -- |
| Dependencies | [SRS_ModeMgm_09113], [SRS_ModeMgm_09097] |
| Supporting Material | -- |
⌋(RS_BRF_01488, RS_BRF_01496, RS_BRF_01448)
**4.1.1.1.2.11 [SRS_ModeMgm_09098] 应可存储唤醒原因 (Storing the wake-up reasons shall be available)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | ECU 状态管理器应能够存储当前的唤醒原因。 |
| Rationale | 在一个模块中存储唤醒原因，并为每个模块（BSW 和 SWC）提供查询唤醒原因的可能性。 |
| Use Case | 通过外部诊断工具检索最后唤醒原因。 某些行为（应用模式管理）可能由唤醒触发。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01448)
**4.1.1.1.2.12 [SRS_ModeMgm_09097] ECU 状态管理器模块应在收到唤醒指示后启动超时 (The ECU state Manager module shall start a timeout after receiving a wake-up indication)**
⌈
| 字段 | 内容 |
|------|------|
| Type | valid |
| Description | ECU 状态管理器模块应在从总线驱动程序接收到唤醒指示后启动超时（T_wake_up_timeout 大于零，静态可配置）。 如果在超时到期之前收到有效消息，则计时器应停止，并且 ECU 状态管理器模块指示系统通道（ComMChannel）唤醒。 ECU 状态管理器应通过额外的 callout 函数启用总线系统的硬件设备（控制器、收发器），并轮询总线驱动程序是否收到有效消息。 消息应由总线驱动程序接收，但在唤醒验证之前不转发到上层。 ECU 状态管理器模块仅当来自总线驱动程序的第一次唤醒指示由在 T_wake_up_timeout 内的后续有效消息确认时，才应指示系统通道唤醒。 如果无法进行验证，则 ECU 状态管理器模块应通过额外的 callout 函数再次禁用为唤醒验证而启用的硬件设备。 如果 T_wake_up_timeout 设置为 0，则验证过程被禁用，唤醒立即被确认。 |
| Rationale | 避免由于错误信号（例如尖峰）引起的唤醒。 如果发生唤醒但无法在物理通道上检测到后续活动，则不考虑唤醒，以节省电力。 仅在验证后转发通信项，以不转发不一致或无意义的信号。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01104, RS_BRF_01448)
**4.1.1.1.2.13 [SRS_ModeMgm_09126] 应提供查询唤醒原因的 API (An API for querying the wake-up reason shall be provided)**
⌈
| 字段 | 内容 |
|------|------|
| Type | valid |
| Description | ECU 状态管理器应提供 API 来查询导致上次 ECU 唤醒的唤醒事件。 |
| Rationale | 用于诊断目的。 |
| Use Case | 在初始化时，应用程序需要根据唤醒原因执行不同的处理。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01056, RS_BRF_01448)
**4.1.1.1.2.14 [SRS_ModeMgm_09274] ECU 状态管理器应提供用于检索所选复位模式的服务 (The ECU State Manager shall provide a service for the retrieval of the selected reset modality)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | ECU 状态管理器应向应用程序提供用于检索所选复位模式的服务。 |
| Rationale | 应用程序可能需要检查是否选择了适当的关闭目标。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01056, RS_BRF_01448)
**4.1.1.1.2.15 [SRS_ModeMgm_09101] 应提供查询复位原因的 API (An API to query the reset reason shall be provided)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | ECU 状态管理器应提供 API 来查询上次复位的原因。 |
| Rationale | 此功能需要根据复位是有意还是无意的来设置不同的启动场景。 |
| Use Case | 复位循环检测。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01056, RS_BRF_01448)
**4.1.1.1.2.16 [SRS_ModeMgm_09276] ECU 状态管理器应提供允许选择启动目标的服务 (The ECU State Manager shall provide a service allowing the selection of the boot target)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | ECU 状态管理器应向应用程序提供服务，允许选择启动目标。 |
| Rationale | 应用程序可能需要发起复位并使系统分支到引导加载程序。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01056, RS_BRF_01448)
**4.1.1.1.2.17 [SRS_ModeMgm_09275] ECU 状态管理器应提供用于查询先前复位时间的服务 (The ECU State Manager shall provide a service for querying the time of previous resets)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | ECU 状态管理器应向应用程序提供用于查询先前复位时间的服务。 |
| Rationale | 应用程序可能需要跟踪复位时间以进行诊断。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01056, RS_BRF_01448)
**4.1.1.1.2.18 [SRS_ModeMgm_09127] ECU 状态管理器应在关闭过程中适当地反初始化基础软件模块 (The ECU State Manager shall de-initialize Basic Software modules where appropriate during the shutdown process)**
⌈
| 字段 | 内容 |
|------|------|
| Type | valid |
| Description | ECU 状态管理器应在关闭过程中适当地反初始化基础软件模块。 |
| Rationale | 协调的 ECU 关闭。 |
| Use Case | -- |
| Dependencies | [SRS_ModeMgm_09147] |
| Supporting Material | -- |
⌋(RS_BRF_01096, RS_BRF_01448)
**4.1.1.1.2.19 [SRS_ModeMgm_09116] 应提供 RUN 状态的请求和释放 (Requesting and releasing the RUN state shall be provided)**
⌈
| 字段 | 内容 |
|------|------|
| Type | valid |
| Description | ECU 状态管理器应提供服务以请求和释放 RUN 状态。 |
| Rationale | 保持 ECU 处于 RUN 状态的决策始终与应用上下文相关，无法标准化。 因此 ECU 状态管理器需要从应用角度获取 "user-requests" 以了解当前情况。 建议具有独立 RUN 状态需求的独立应用（SWC）应通过使用 ECU 状态管理器提供的接口来控制其 "user request"。 |
| Use Case | 在 ECU 上发生与催化排气系统的预热功能相关的唤醒事件（例如门接触），该 ECU 通过软件覆盖和控制此功能。 通过此唤醒事件，应在 ECU 状态管理器上建立进入此 ECU 的 RUN 状态的请求。 一旦预热完成，预热功能应释放其保持 RUN 状态的需求。 如果此 ECU 上没有其他应用软件组件请求保持 RUN 状态，则 ECU 状态管理器将继续进行关闭过程。 |
| Dependencies | [SRS_ModeMgm_09115] 评估保持 RUN 状态的条件。 |
| Supporting Material | -- |
⌋(RS_BRF_01096, RS_BRF_01488, RS_BRF_01448)
#### 4.1.2 固定 (Fixed) — 摘要
> **翻译说明**：
> 请注意，具有固定状态机的 ECU 状态管理器规范不再是本发布版本的一部分。 EcuM Fixed 是 EcuM 的一个变体，具有一组固定的状态：OFF、RUN、SLEEP 和瞬态：STARTUP、WAKEUP、SHUTDOWN。
>
> 详细需求（SRS_ModeMgm_09120、09147、09146、09001、09173、09114、09113、09009、09118、09115、09164、09165、09166、09145 等）的完整列表请参见原始 PDF 文档。 这些需求涵盖了 EcuM Fixed 的配置、初始化/反初始化顺序、状态转换、POST_RUN 状态、唤醒/睡眠操作等方面。
#### 4.1.3 灵活 (Flex)
**EcuM Flex** 是 EcuM 的一个变体，可以非常灵活的方式控制 ECU 状态（BSW 和应用的部分运行）。 这为实现项目特定的节能策略提供了基础。 为此，它利用了 BswM（基础软件模式管理器）。
##### 4.1.3.1 功能需求 (Functional Requirements)
###### 4.1.3.1.1 正常运行 (EcuM Flexible) (Normal Operation (EcuM Flexible))
**4.1.3.1.1.1 [SRS_ModeMgm_09234] EcuM 应处理基础软件模块的初始化 (The EcuM shall handle the initialization of Basic Software modules)**
⌈
| 字段 | 内容 |
|------|------|
| Type | valid |
| Description | EcuM 处理初始化，直到 BswM 的模式管理启动。 |
| Rationale | 组织 BSW 的初始化过程。 |
| Use Case | 基础软件架构的已定义初始化过程。 |
| Dependencies | [SRS_ModeMgm_09120] |
| Supporting Material | -- |
⌋(RS_BRF_01096, RS_BRF_01448)
**4.1.3.1.1.2 [SRS_ModeMgm_09235] ECU 状态管理器应提供两个用于关闭 ECU 的目标 (The ECU State Manager shall offer two targets for shutting down the ECU)**
⌈
| 字段 | 内容 |
|------|------|
| Type | valid |
| Description | ECU 状态管理器应至少提供以下用于关闭 ECU 的目标：断电 (Power Off)、ECU 复位 (ECU Reset)。 默认目标应由配置定义。 应有一个接口来更改目标。 |
| Rationale | 允许在能耗和唤醒/启动 ECU 的时间之间进行权衡。 |
| Use Case | 错误后的有效关闭；用于刷写的有效关闭。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_1096, RS_BRF_01488, RS_BRF_01448)
###### 4.1.3.1.2 报警时钟 (Alarm Clock)
**4.1.3.1.2.1 [SRS_ModeMgm_09185] 应提供本地 SW-C 使用的持久报警时钟 (A persistent Alarm Clock used by local SW-Cs shall be provided)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | ECU 状态管理器应提供一个持久的报警时钟，该时钟跟踪时间并在睡眠期间保持 "活动" 状态，并允许根据未来时间请求唤醒服务，以保证 ECU 在本地 SW-C 请求时处于 RUN 状态。 |
| Rationale | 允许基于时间的内部唤醒请求离开睡眠状态，而不仅仅是基于外部 I/O 事件。 |
| Use Case | -- |
| Dependencies | SRS_ModeMgm_09186 |
| Supporting Material | 持久性并不意味着在断电阶段非易失性，但它应在 ECU 处于任何睡眠模式并仍连接到电源时保持持久。 涵盖的功能请求：RS_BRF_00196（报警时钟） |
⌋(RS_BRF_01448)
**4.1.3.1.2.2 [SRS_ModeMgm_09186] 报警时钟应在 ECU 通电时处于活动状态 (Alarm Clock shall be active while the ECU is powered)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | 所使用的时间基准应在 ECU 通电时计时。 每次（重新）连接到电源应将内部时间重置为零，取消所有以前活动的报警，并立即重新开始计时。 |
| Rationale | 在 ECU 未通电时无法估计经过的时间，也无法在这种情况下启动任何操作。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | 在断电阶段不需要在内存中保持 armed 报警。 |
⌋(RS_BRF_01448)
**4.1.3.1.2.3 [SRS_ModeMgm_09187] 在唤醒情况下，所有报警时钟应被取消 (In Case of wakeup, all the alarm clock shall be canceled)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | 当 ECU 唤醒时，报警时钟的所有报警应被取消。 |
| Rationale | 这避免了唤醒 ECU 的意外事件导致的不期望的行为。 SW-C 负责在执行时启动报警时钟。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01448)
**4.1.3.1.2.4 [SRS_ModeMgm_09188] 在启动情况下，所有报警时钟应被取消 (In Case of startup, all the alarm clock shall be canceled)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | 当 ECU 进行上电复位时，报警时钟的所有报警应被取消。 |
| Rationale | 这避免了唤醒 ECU 的意外事件导致的不期望的行为。 SW-C 负责在执行时启动报警时钟。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01448)
**4.1.3.1.2.5 [SRS_ModeMgm_09189] 连续请求应仅遵守最早到期的报警 (Consecutive requests shall honor the earliest expiring alarm only)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | 连续请求应仅遵守最早到期的报警。 |
| Rationale | 这避免了唤醒 ECU 的意外事件导致的不期望的行为。 SW-C 负责在执行时启动报警时钟。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01448)
**4.1.3.1.2.6 [SRS_ModeMgm_09190] 报警时钟服务应允许以秒为单位的时间分辨率设置相对于当前时间的报警 (The alarm clock service shall allow setting an alarm relative to the current time using a time resolution of seconds)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | 报警时钟服务应允许以秒为单位的时间分辨率设置相对于当前时间的报警。 除了仅在 ECU 离开 RUN 模式（POSTRUN）时允许使用此接口之外，没有访问限制。 |
| Rationale | SW-C 应能够设置报警。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01448)
**4.1.3.1.2.7 [SRS_ModeMgm_09199] 报警时钟服务应允许通过使用秒级分辨率的绝对时间设置绝对报警 (The alarm clock service shall allow setting an alarm absolute by using an absolute time with a resolution of seconds)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | 报警时钟服务应允许通过使用绝对时间（但相对于计时器的开始）以秒级分辨率设置绝对报警。 除了仅在 ECU 离开 RUN 模式（POSTRUN）时允许使用此接口之外，没有访问限制。 |
| Rationale | SW-C 应能够设置报警。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01448)
**4.1.3.1.2.8 [SRS_ModeMgm_09194] 报警时钟服务应允许设置时钟 (The alarm clock service shall allow setting the clock)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | 报警时钟服务应允许设置时钟。 没有访问限制。 这可用于将报警时钟与任何其他时钟同步（例如由 GPS 接收器接收的时钟）。 |
| Rationale | SW-C 应能够将报警时钟与其他时间源同步。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01448)
**4.1.3.1.2.9 [SRS_ModeMgm_09277] ECU 状态管理器应提供报警时钟服务，该服务应允许检索时钟值 (The ECU State Manager shall provide an alarm clock service which shall allow the retrieval of clock values)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | ECU 状态管理器应向应用程序提供报警时钟服务，该服务应允许检索时钟值。 |
| Rationale | 应用程序可能需要读取当前时钟值。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01448)
###### 4.1.3.1.3 多核 (Multi Core)
**4.1.3.1.3.1 [SRS_ModeMgm_09236] 应有一个区分不同核的 EcuM_Init 函数实例 (There shall be one instance of the function EcuM_Init that distinguishes between the different cores)**
⌈
| 字段 | 内容 |
|------|------|
| Type | valid |
| Description | 应有一个 EcuM_Init 函数实例，通过 OS 服务 "GetCoreID" 区分不同的核。 |
| Rationale | "InitSequence 1" 可以是核特定的。 多核架构的理念是拥有一个二进制文件，因此 "EcuM_Init" 仅存在一次。 |
| Use Case | • 核特定的硬件初始化；• 一个核启动其他核，而其他核不启动进一步的核。 |
| Dependencies | -- |
| Supporting Material | AUTOSAR 多核 OS 架构规范 |
⌋(RS_BRF_01160, RS_BRF_00206, RS_BRF_01448)
**4.1.3.1.3.2 [SRS_ModeMgm_09237] RTE_Start 应该在每个核上调用 (RTE_Start shall be called on each core)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | RTE_Start 应通过 BswM 在主核上通过专用的可用动作触发的任务在每个核上本地调用。 |
| Rationale | 有必要协调核上的 RTE 启动，因为从核上的 RTE 可能请求使用主核上可能尚未初始化的模块。 同样，有必要避免 RTE 的跨核传播，否则会增加其复杂性并使其远超 "宏层"。 |
| Use Case | 如果没有协调，从核上 RTE 的启动可能比主核早得多，主核上运行着更多的模块，每个模块都需要初始化时间。 |
| Dependencies | -- |
| Supporting Material | AUTOSAR 多核 OS 架构规范 |
⌋(RS_BRF_01160, RS_BRF_00206, RS_BRF_01448)
**4.1.3.1.3.3 [SRS_ModeMgm_09238] 状态变化应为 ECU 全局的 (State changes shall be ECU global)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | 状态变化应为 ECU 全局的（所有核都切换到有效状态）。 整个 ECU 仅可切换到 "off"、"fully functional" 或 "sleeping"（已停止或设置为轮询）。 |
| Rationale | 应减少/避免多并行存在状态所引入的复杂性和问题。 （至少对于 R 4.0） |
| Use Case | 每次状态变化。 |
| Dependencies | -- |
| Supporting Material | AUTOSAR 多核 OS 架构规范 |
⌋(RS_BRF_01160, RS_BRF_00206, RS_BRF_01448)
**4.1.3.1.3.4 [SRS_ModeMgm_09239] 为了关闭，ShutdownAllCores 应在同步所有核后在主核上调用 (To shutdown, ShutdownAllCores shall be called on the master core after synchronizing all cores)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | 为了停止运行（关闭 ECU），ShutdownAllCores 应在同步所有核后在主核上调用。 |
| Rationale | 应用程序开发人员/系统集成商有责任确保在调用 "ShutdownAllCores" 之前完成在应用程序和基础软件级别上为关闭所做的任何准备工作。 AUTOSAR R4.0 不支持核单独的关闭。 |
| Use Case | 整个 ECU 的同步关闭。 |
| Dependencies | -- |
| Supporting Material | AUTOSAR 多核 OS 架构规范 |
⌋(RS_BRF_01160, RS_BRF_00206, RS_BRF_01448)
**4.1.3.1.3.5 [SRS_ModeMgm_09254] 唤醒事件的验证和处理应在本地完成 (Validation and handling of a wakeup event shall be done locally)**
⌈
| 字段 | 内容 |
|------|------|
| Type | Valid |
| Description | 唤醒事件的验证和处理应在配置中分配唤醒的核上本地完成。 |
| Rationale | 每个唤醒事件在特定核的 EcuM 实例中精确配置。 唤醒处理（包括其验证）应在该核上本地完成。 |
| Use Case | 在多核架构中唤醒核并验证唤醒事件。 |
| Dependencies | -- |
| Supporting Material | 概念 EnhancedBSWAllocation |
⌋(RS_BRF_01104, RS_BRF_01448)
### 4.2 看门狗管理器 (Watchdog Manager, WdgM) — 摘要
> **翻译说明**：看门狗管理器（WdgM）负责基于应用软件的时间约束（时间程序流监控）和正确执行顺序（逻辑程序流监控）来监督应用执行的可靠性。 它监督多个独立的应用程序，监督安全相关任务和周期函数的执行，提供故障反应机制，并支持通过看门狗驱动程序触发内部或外部、标准或窗口看门狗。 看门狗模式（Off Mode、Slow Mode、Fast Mode）的选择取决于 ECU 状态和硬件功能。
>
> 详细需求（包括 SRS_ModeMgm_09107 初始化、SRS_ModeMgm_09108 模式切换、SRS_ModeMgm_09109 监督、SRS_ModeMgm_09110 alive 指示、SRS_ModeMgm_09111 触发、SRS_ModeMgm_09112 故障处理 等）的完整列表请参见原始 PDF 文档。
>
> 主要需求类别：
> - 4.2.2.1 初始化 (Initialization)
> - 4.2.2.2 正常操作 (Normal Operation)
> - 4.2.2.3 关闭和唤醒 (Shutdown and Wakeup)
> - 4.2.2.4 监督 (Supervision)
> - 4.2.2.5 Alive 监督 (Alive Supervision)
> - 4.2.2.6 程序流监控 (Program Flow Monitoring)
> - 4.2.2.7 错误处理 (Error Handling)
> - 4.2.3 错误操作 (Fault Operation)
### 4.3 通信管理器 (Communication Manager, ComM) — 摘要
> **翻译说明**：通信管理器（ComM）负责协调 ECU 上的通信。 它管理用户的通信请求，限制通信模式（例如 NONE_COM、SilentCommunication、FullCommunication），并与总线状态管理器（CanSM、FrSM、EthSM、LinSM）协调以响应网络状态变化。 ComM 还支持部分网络（Partial Network Cluster），并提供资源管理。
>
> 详细需求（包括通信模式、用户、通道、PNC、请求/释放、限制模式、唤醒、ECU 群组、错误处理等）的完整列表请参见原始 PDF 文档。
### 4.4 基础软件模式管理器 (Basic Software Mode Manager, BswM)
> **翻译说明**：BswM 通过标准化接口收集模式请求并相应地控制其他 BSW 模块的功能。 它支持模式处理和模式相关交互。 BswM 仲裁模式请求并根据仲裁结果执行预定义的动作。 详细需求请参见原始 PDF 文档和 SWS BswM 规范。
>
> 详细需求（包括 SRS_BswM_xxxxx 各项）的完整列表请参见原始 PDF 文档。
---
## 5 需求追踪 (Requirements Tracing)
> 完整的需求追踪表（包括每个 SRS_ModeMgm_xxxxx 需求到 RS_BRF_xxxxx 特征的映射）请参见原始 PDF 文档的 5 章。 下表提供了简要概览。
| 需求 ID | 模块 | 主题 | 链接的特征 |
|--------|------|------|-----------|
| SRS_ModeMgm_09122 | EcuM Common | 用户配置 | RS_BRF_01488, RS_BRF_01448 |
| SRS_ModeMgm_09100 | EcuM Common | 唤醒源配置 | RS_BRF_01496, RS_BRF_01104, RS_BRF_01448 |
| SRS_ModeMgm_09104 | EcuM Common | OS 关闭后接管控制 | RS_BRF_01096, RS_BRF_01448 |
| SRS_ModeMgm_09128 | EcuM Common | 多关闭目标 | RS_BRF_01096, RS_BRF_01488, RS_BRF_01448 |
| SRS_ModeMgm_09270 | EcuM Common | 关闭目标选择服务 | RS_BRF_01096, RS_BRF_01488, RS_BRF_01448 |
| SRS_ModeMgm_09271 | EcuM Common | 关闭目标检索服务 | RS_BRF_01096, RS_BRF_01488, RS_BRF_01448 |
| SRS_ModeMgm_09119 | EcuM Common | 多睡眠模式 | RS_BRF_01488, RS_BRF_01448 |
| SRS_ModeMgm_09102 | EcuM Common | 睡眠模式选择 API | RS_BRF_01488, RS_BRF_01448 |
| SRS_ModeMgm_09272 | EcuM Common | 最后睡眠目标检索 | RS_BRF_01488, RS_BRF_01448 |
| SRS_ModeMgm_09072 | EcuM Common | 强制 ECU 关闭 | RS_BRF_01488, RS_BRF_01056, RS_BRF_01448 |
| SRS_ModeMgm_09017 | EcuM Common | 查询当前 ECU 状态 | RS_BRF_01488, RS_BRF_01448 |
| SRS_ModeMgm_09136 | EcuM Common | 唤醒事件接收 | RS_BRF_01488, RS_BRF_01496, RS_BRF_01448 |
| SRS_ModeMgm_09098 | EcuM Common | 唤醒原因存储 | RS_BRF_01448 |
| SRS_ModeMgm_09097 | EcuM Common | 唤醒超时 | RS_BRF_01104, RS_BRF_01448 |
| SRS_ModeMgm_09126 | EcuM Common | 唤醒原因查询 API | RS_BRF_01056, RS_BRF_01448 |
| SRS_ModeMgm_09274 | EcuM Common | 复位模式检索 | RS_BRF_01056, RS_BRF_01448 |
| SRS_ModeMgm_09101 | EcuM Common | 复位原因查询 | RS_BRF_01056, RS_BRF_01448 |
| SRS_ModeMgm_09276 | EcuM Common | 启动目标选择 | RS_BRF_01056, RS_BRF_01448 |
| SRS_ModeMgm_09275 | EcuM Common | 复位时间查询 | RS_BRF_01056, RS_BRF_01448 |
| SRS_ModeMgm_09127 | EcuM Common | BSW 反初始化 | RS_BRF_01096, RS_BRF_01448 |
| SRS_ModeMgm_09116 | EcuM Common | RUN 请求/释放 | RS_BRF_01096, RS_BRF_01488, RS_BRF_01448 |
| SRS_ModeMgm_09234 | EcuM Flex | BSW 模块初始化 | RS_BRF_01096, RS_BRF_01448 |
| SRS_ModeMgm_09235 | EcuM Flex | 关闭目标 | RS_BRF_1096, RS_BRF_01488, RS_BRF_01448 |
| SRS_ModeMgm_09185 | EcuM Flex | 持久报警时钟 | RS_BRF_01448 |
| SRS_ModeMgm_09186 | EcuM Flex | 报警时钟通电 | RS_BRF_01448 |
| SRS_ModeMgm_09187 | EcuM Flex | 唤醒时取消报警 | RS_BRF_01448 |
| SRS_ModeMgm_09188 | EcuM Flex | 启动时取消报警 | RS_BRF_01448 |
| SRS_ModeMgm_09189 | EcuM Flex | 连续请求最早报警 | RS_BRF_01448 |
| SRS_ModeMgm_09190 | EcuM Flex | 相对时间报警 | RS_BRF_01448 |
| SRS_ModeMgm_09199 | EcuM Flex | 绝对时间报警 | RS_BRF_01448 |
| SRS_ModeMgm_09194 | EcuM Flex | 设置时钟 | RS_BRF_01448 |
| SRS_ModeMgm_09277 | EcuM Flex | 时钟值检索 | RS_BRF_01448 |
| SRS_ModeMgm_09236 | EcuM Flex | EcuM_Init 多核 | RS_BRF_01160, RS_BRF_00206, RS_BRF_01448 |
| SRS_ModeMgm_09237 | EcuM Flex | RTE_Start 每核 | RS_BRF_01160, RS_BRF_00206, RS_BRF_01448 |
| SRS_ModeMgm_09238 | EcuM Flex | 状态变化 ECU 全局 | RS_BRF_01160, RS_BRF_00206, RS_BRF_01448 |
| SRS_ModeMgm_09239 | EcuM Flex | ShutdownAllCores | RS_BRF_01160, RS_BRF_00206, RS_BRF_01448 |
| SRS_ModeMgm_09254 | EcuM Flex | 本地唤醒处理 | RS_BRF_01104, RS_BRF_01448 |
| SRS_ModeMgm_09107 .. 09112 | WdgM | 初始化、监督等 | RS_BRF_xxxxx |
| SRS_ComM_xxxxx | ComM | 通信管理 | RS_BRF_xxxxx |
| SRS_BswM_xxxxx | BswM | 模式管理 | RS_BRF_xxxxx |
> 完整的需求追踪表见原始 PDF 文档的 5 章。
---
## 6 参考文献 (References)
[1] AUTOSAR Layered Software Architecture
[2] AUTOSAR Basic Software Module Description Template
[3] AUTOSAR Specification of Watchdog Manager
[4] AUTOSAR Specification of Communication Manager
[5] AUTOSAR Specification of ECU State Manager
[6] AUTOSAR Main Requirements
[7] AUTOSAR Requirements on Architecture
[8] AUTOSAR Specification of BSW Mode Manager
[9] AUTOSAR Requirements Specification Template
---
## 翻译说明
本文档为 AUTOSAR CP Release 4.4.0《模式管理需求》的中文翻译。 主要翻译内容包括：
1. **完整翻译**：
- 文档标识、变更历史
- 目录
- 第 1 章 文档范围
- 第 2 章 使用的约定（关键字解释）
- 第 3 章 术语（完整术语表、缩写表）
- 第 4.1.1 节 EcuM 通用需求（约 20 个核心需求完整翻译）
- 第 4.1.3 节 EcuM Flex 需求（包含报警时钟、多核等 16 个核心需求完整翻译）
2. **摘要标记**：
- 第 4.1.2 节 EcuM Fixed（注明不再属于本发布版本）
- 第 4.2 节 WdgM
- 第 4.3 节 ComM
- 第 4.4 节 BswM
3. **保留内容**：
- 所有 API 标识符
- 模块缩写（EcuM、ComM、WdgM、BswM、SW-C、SWC、SW、BSW、RTE 等）
- 状态名称（RUN、SHUTDOWN、SLEEP、POST_RUN、OFF 等）
- AUTOSAR 方框符 `⌈⌋`
- 需求 ID（SRS_ModeMgm_xxxxx）
- 文档间交叉引用
ModeManagement/AUTOSAR_SWS_BSWModeManager.md
+1118
View File
File diff suppressed because it is too large Load Diff
ModeManagement/AUTOSAR_SWS_ECUStateManager.md
+1138
View File
File diff suppressed because it is too large Load Diff
Safety/AUTOSAR_EXP_AIOccupantAndPedestrianSafety.md
+486
View File
@@ -0,0 +1,486 @@
# 乘员和行人安全系统域应用接口说明（Explanation of Application Interfaces of Occupant and Pedestrian Safety Systems Domain）
| 字段 | 内容 |
|---|---|
| **文档标题** | 乘员和行人安全系统域应用接口说明（Explanation of Application Interfaces of Occupant and Pedestrian Safety Systems Domain） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 271 |
| **文档状态** | Final（正式发布） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
---
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 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 | 编辑性变更 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 编辑性变更 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 新增 Crash Status（SWCo 003 CS）；新增翻滚和俯仰碰撞检测（SWCo 302 ROD、303 POD）；使用翻滚和俯仰极性更新坐标系参考系统 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 修正了与传感器安全需求相关的段落位置，以使其位于传感器池章节中 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 初始发布 |
---
## 目录（Table of Contents）
1. [本文档目的](#1-本文档目的)
- 1.1 [参考文献](#11-参考文献)
2. [术语和概念描述](#2-术语和概念描述)
- 2.1 [术语和缩写列表](#21-术语和缩写列表)
- 2.2 [OPS 域介绍](#22-ops-域介绍)
- 2.3 [OPS 阶段（事件时间线）](#23-ops-阶段事件时间线)
- 2.4 [域建模](#24-域建模)
- 2.5 [参考系统](#25-参考系统)
3. [架构概述](#3-架构概述)
- 3.1 [变体处理](#31-变体处理)
4. [软件组合和组件描述](#4-软件组合和组件描述)
- 4.1 [传感器池（SWCo 001 SP）](#41-传感器池swco-001-sp)
- 4.2 [执行器池（SWCo 002 AP）](#42-执行器池swco-002-ap)
- 4.3 [碰撞状态（SWCo 003 CS）](#43-碰撞状态swco-003-cs)
- 4.4 [安全带提醒（SWCo 102 SBR）](#44-安全带提醒swco-102-sbr)
- 4.5 [车辆碰撞检测（SWCo 301 VCD）](#45-车辆碰撞检测swco-301-vcd)
- 4.6 [翻滚和俯仰碰撞检测（SWCo 302 ROD、303 POD）](#46-翻滚和俯仰碰撞检测swco-302-rod303-pod)
- 4.7 [乘员约束系统激活（SWCo 304 ORA）](#47-乘员约束系统激活swco-304-ora)
- 4.8 [行人保护碰撞检测（SWCo 305 PCD）](#48-行人保护碰撞检测swco-305-pcd)
- 4.9 [行人保护系统激活（SWCo 306 PPA）](#49-行人保护系统激活swco-306-ppa)
- 4.10 [乘员检测（SWCo 101 OD）](#410-乘员检测swco-101-od)
5. [附加信息](#5-附加信息)
- 5.1 [传感器池端口名称详细说明](#51-传感器池端口名称详细说明)
- 5.2 [执行器池端口名称详细说明](#52-执行器池端口名称详细说明)
---
## 1 本文档目的
本文档提供背景信息，例如导致"乘员和行人安全系统（Occupant and Pedestrian Safety Systems）"域标准化应用接口定义的设计决策。
### 1.1 参考文献
- **[1]** AUTOSAR Table of Application Interface `AUTOSAR_MOD_AITable`
- **[2]** `AUTOSAR_TPS_GenericStructureTemplate.pdf` 第 12 章
---
## 2 术语和概念描述
### 2.1 术语和缩写列表
| 缩写 | 全称 |
|---|---|
| AB | Airbag（安全气囊） |
| AI | Application Interface（应用接口） |
| COOP | Critical Out of Position（关键超出位置） |
| eCall | Emergency Call（紧急呼叫） |
| HMI | Human Machine Interface（人机界面） |
| IF | Interface（接口） |
| OD | Occupant Detection（乘员检测） |
| OOP | Out Of Position（超出位置） |
| OPS | Occupant and Pedestrian Safety（乘员和行人安全） |
| OPSS | OPS Systems（OPS 系统） |
| ORA | Occupant Restraint Activation（乘员约束激活） |
| PCD | Pedestrian Crash Detection（行人碰撞检测） |
| PPA | Pedestrian Protection Actuator Activation（行人保护执行器激活） |
| SBR | Seat Belt Reminder（安全带提醒） |
| SRS | Safety Restraint System（安全约束系统） |
| SWC | Software Component（软件组件） |
| SWCo | Software Composition（软件组合） |
| VCD | Vehicle Crash Detection（车辆碰撞检测） |
| ROD | Rollover Crash Detection（翻滚碰撞检测） |
| POD | Pitchover Crash Detection（俯仰碰撞检测） |
| Antisubmarine | 防下潜 —— 汽车约束系统中使用的术语，指一种 AB 在展开时通过提升人的下半身来防止前排乘客俯冲到仪表板下方，从而使该人处于相对于主正面 AB 的更好位置 |
| VH | Variant Handling concept（变体处理概念） |
| SP | Sensor Pool（传感器池） |
| AP | Actuator Pool（执行器池） |
| CS | Crash Status（碰撞状态） |
| ACC | Adaptive Cruise Control（自适应巡航控制） |
| RSM | Restraint System Monitoring（约束系统监控） |
| VCP | Vehicle Crash Prediction（车辆碰撞预测） |
| PCP | Pedestrian Crash Prediction（行人碰撞预测） |
| OPC | Occupant Pre Conditioning（乘员预调节） |
| RSP | Restraint System Pre conditioning（约束系统预调节） |
| PPP | Pedestrian Protection system Pre conditioning（行人保护系统预调节） |
| PCI | Post Crash Information（碰撞后信息） |
### 2.2 OPS 域介绍
**乘员和行人安全**（Occupant and Pedestrian Safety, OPS）领域的目的是在碰撞事故中保护车辆乘员以及行人。在此意义上，"碰撞"是一个相当广泛的术语，用于分类车辆与障碍物（正面、侧面、后方）碰撞的情况，或与行人正面碰撞的情况，甚至在例如翻滚事故的情况下与地面碰撞的情况。
"碰撞"或"事故"的概念塑造了 OPS 的范围，使其成为一个**事件驱动的域**。例如，车辆侧面与灯柱碰撞的事件将触发 SRS 部署侧安全气囊，以防止乘员被车辆结构（如车门或 C 柱）撞击，这些结构因撞击而变形。
OPS 系统的事件驱动特性使其适合将域建模为**阶段链**，每个阶段在确定的事件被触发之后进入。下一节中的时间线旨在提供主要 OPS 阶段及其对应事件的图形表示。
### 2.3 OPS 阶段（事件时间线）
图 1 显示了一个时间线，其中总结了最重要的 OPS 阶段。使用传感器信号曲线来代表性地描述不同的碰撞阶段。每个 OPS 阶段被建模为由两个子阶段组成，它们提供有关碰撞事件情况下车辆状况的更多详细信息。
这些 OPS 阶段可用于其他域以了解车辆处于事件的哪个阶段。简单的碰撞后 / 碰撞前分类通常对其他域来说已足够，然而在说明文档的先前版本中提出了更精细的定义。图 1 提供了这两种定义之间的对应关系。
#### 2.3.1 碰撞前阶段（Pre-Crash Phase）
碰撞前阶段可以进一步细分为更详细的子阶段：
**正常驾驶（Normal Driving）**：
车辆处于点火开启（无论静止还是行驶）的状态，碰撞概率非常低。子阶段包括：
- **正常驾驶**：在此子状态中未检测到显著的碰撞概率。
- **具有较小碰撞风险的正常驾驶**：在此子状态中存在较小的碰撞概率，但车辆基于接触的碰撞传感器尚未检测到该事件。在此阶段存在最小的碰撞风险，例如在车辆稳定性控制机制正在动作的情况下。
**碰撞前（Pre-Crash）**：
车辆处于超出正常驾驶条件的状态，其中存在碰撞概率大于某个阈值的指示。通常在此阶段激活可逆执行器，例如使乘员进入正确的坐姿位置，以便在随后的碰撞中通过 SRS 提供最佳保护。子阶段包括：
- **仍可避免的碰撞**：碰撞前系统已检测到碰撞危险，但仍然评估了避免碰撞的机会，例如通过触觉警告、紧急制动或规避操作等手段。
- **不可避免的碰撞**：碰撞前系统得出结论，鉴于车辆及其环境的当前动力学，碰撞已无法避免。
**碰撞中：未确定的碰撞（In-Crash: Undetermined collision）**：
对于正面、侧面、行人、后方，此阶段始于车辆与障碍物的第一次接触，例如另一辆车，或弱势道路使用者（VRU），例如行人。对于翻滚和俯仰的特殊情况，碰撞中状态在达到确定的阈值（例如倾斜角度）之后进入。在碰撞中未确定的碰撞状态下，车载碰撞接触传感器测量活动，但就车辆所处的情况（例如在所谓的"误用"情况下，如在崎岖道路上行驶，或与刚性物体碰撞）得出结论还为时过早。
#### 2.3.2 碰撞后阶段（Post-Crash Phases）
**碰撞中：确定的碰撞（In-Crash: Determined collision）**：
在碰撞中确定的碰撞情况下，通常激活**不可逆执行器**。碰撞事件根据其严重性进一步分类，严重性范围从轻（例如激活安全带卷收器）到高（例如激活安全气囊的第二阶段）。
**碰撞后（Post-Crash）**：
在碰撞中状态之后进入此状态，随后将出现：
- 在轻度严重性碰撞中事件的情况下**返回正常驾驶条件**，从而提供处理多个碰撞事件的机会。
- 在碰撞中状态之后**达到静止（Stand Still）**。
- 在约束执行器被激活之后。
子阶段包括：
- **部署后（Post-deployment）**：在碰撞情况得到确认之后采取的第一步行动。示例动作可能是车辆门的自动解锁。
- **碰撞后（Post-crash）**：车辆已再次达到静止，从而发起紧急呼叫。
**图 1**：OPSS 阶段
### 2.4 域建模
本域的范围仅限于**被动安全功能**。其他功能，例如驾驶员辅助系统的功能（例如 ACC）或主动安全系统（如 ESC）是底盘域的一部分，不包括在此。但是，来自这些系统的信息可以在 OPSS 域内使用。
图 2 提供了 OPSS 域的图形表示。域模型一方面考虑了如图 1 所示的事件驱动特性，另一方面考虑了 AUTOSAR 对 SW 组件"应用"（此处称为"功能"）、"传感器"和"执行器"的分类。
**图 2**：OPSS 域模型
### 2.5 参考系统
为了确保 OPSS 域接口元素的一致解释，采用了一系列最先进的参考系统。以下是它们的简要总结。
#### 2.5.1 参考坐标系
OPSS 中使用的坐标参考系统如图 3 所示：
**图 3**：OPSS 的坐标参考系统
此坐标参考系统具有**相对性质**，与基于固定点的坐标系统（如基于重心的系统）相对。对于 OPS 域，主要相关性首先在于能够确定车辆变形的方向，其次是其相应的严重性。例如，正面碰撞事件中车辆变形的方向将确定可能要激活的可能约束系统执行器仅为安全带卷收器和安全气囊；而冲击的严重性（可根据车辆变形测量）将确定应部署哪些具体的安全带卷收器和 / 或安全气囊。
#### 2.5.2 座椅位置的命名约定
对于座椅位置的命名（例如用于安全带提醒功能的目的，或用于解释车辆中执行器的位置），采用了图 4 中所示的参考系统。该约定提供了车辆中第二和第三排座椅的唯一命名，但允许在第一排座椅的命名上具有一定的灵活性。OPS 域中第一排的灵活性是必需的，因为重要的功能通常需要耦合到驾驶员或乘客侧，并且应始终与左舵或右舵车辆中的相应乘员位置保持一致，例如驾驶员专用执行器；而其他功能可能依赖于绝对车辆侧（即左或右），而无论车辆是右舵还是左舵。
**图 4**：车辆中乘员座椅位置命名的参考系统
---
## 3 架构概述
为了标准化应用接口，OPS 域模型已根据上述图 1 中详述的原则拆分为示例性 SW 组合。
图 5 显示了 OPSS 域的 SWCo 分解。SWCo 按以下阶段分组：
- **正常驾驶**：SWCo 101 OD（乘员检测）、SWCo 104 VCP（车辆碰撞预测）、SWCo 105 PCP（行人碰撞预测）、SWCo 102 SBR（安全带提醒）、SWCo 103 RSM（约束系统监控）
- **碰撞前**：SWCo 201 OPC（乘员预调节）、SWCo 202 RSP（约束系统预调节）、SWCo 203 PPP（行人保护系统预调节）
- **碰撞中**：SWCo 301 VCD（车辆碰撞检测）、SWCo 302 ROD（翻滚碰撞检测）、SWCo 303 POD（俯仰碰撞检测）、SWCo 304 ORA（乘员约束系统激活）、SWCo 305 PCD（行人碰撞检测）、SWCo 306 PPA（行人保护系统激活）
- **碰撞后**：SWCo 401 PCI（碰撞后信息至 HMI）
底层的传感器池（SWCo 001 SP）、执行器池（SWCo 002 AP）和碰撞状态（SWCo 003 CS）为所有上述 SWCo 提供基础服务。
**图 5**：OPSS SWCo 分解（示例性）
图 5 中的 SW 组合可以彼此互连，也可以与其他 AUTOSAR 域（例如底盘域）互连。这些连接的概览如图 6 所示。具有灰色背景的 SWCo 不包括在当前标准化中，但将在未来进行标准化。乘员检测 SWCo 是一种特殊情况，其中一些接口已在此版本中定义，其他接口将在未来进行标准化。
**图 6**：整体 SW 组合及与其他域的交互
### 3.1 变体处理
OPS Autosar 接口（如本文档所述）代表了最典型的当前约束系统应用。这并不意味着实现 Autosar 接口的任何 OPS 系统将具有与其他任何系统完全相同的接口蓝图。在实践中，将有许多变体反映对特定约束系统实现提出的需求。为了处理这些变体，Autosar 元模型提供了一种建模概念，使对接口元素中这种多样性的建模成为可能。有关更多信息，请参见 [2]。
对于 OPS 系统，当前的版本没有固定的变体，但将来可能会扩展或实现。
---
## 4 软件组合和组件描述
以下是图 5 中所示的 SWCo 的详细视图。
### 4.1 传感器池（SWCo 001 SP）
OPS 域基于最先进的传感技术实现其 In-Crash 功能的检测功能，并为正常驾驶和碰撞前功能提供先进的传感。
对于 In-Crash 功能，传感器技术及其潜在位置如图 7 所示。所采用的位置命名对左舵和右舵车辆均有效。
**传感器类型和位置**：
- **外围加速度传感器**：前左 / 中 / 右，后左 / 中 / 右
- **前保险杠中的加速度传感器**：左、中左、中、中右、右
- **车门中的加速度传感器**：前门左 / 右，后门左 / 右
- **A、B 和 C 柱中的加速度传感器**：A / B / C 柱左 / 右
- **中央加速度传感器**：纵向 / 横向 / 向上
- **中央偏航 / 翻滚 / 俯仰速率传感器**：偏航速率（ω_Z）、中央翻滚速率（ω_X）、中央俯仰速率（ω_Y）
- **车门中的压力传感器**：前门左 / 右，后门左 / 右
- **温度传感器**：前保险杠温度
**图 7**：In-Crash 功能的车辆中传感器位置
X…纵向（行驶方向），Y…横向，Z…向上
传感器建模为属于传感器池 SW 组合的 SWC。对于加速度测量传感器，可以为标准化识别以下组：
- **加速度内部（Acceleration Internal）**：内置于位于车辆内部良好保护位置（例如车辆通道）的控制单元中的传感器组（参见图 7）：
- **加速度低量程**：典型测量范围约 +/-10g
- **加速度中量程**：典型测量范围约 +/-100g
- **加速度中央**：这是默认的传感器类型，典型测量范围约 +/-200g
- **加速度外部（Acceleration External）**：安装在车辆外围的传感器组。它们可以是单轴或双轴的，例如纵向和横向测量，或仅纵向或仅横向。由于它们暴露于汽车周围环境，这些传感器的特征在于比内部传感器高得多的测量范围，例如 +/-800g。
传感器数据（对于外部和内部量程）可以是原始值或滤波值，具体取决于应用。
传感器池组合的 SWC 也可以根据其传感技术进行分类。原则上，OPSS 域中的任何传感器 SWC 都唯一地属于以下传感器类型之一：
1. **加速度（Acceleration）**：此类别中的传感器 SWC 测量车辆结构在车辆碰撞事件中沿定义轴线（例如车辆 X 轴）的减速度。传感器可以安装在汽车中的不同位置，例如通道、车辆前端、B 柱等。
2. **压力（Pressure）**：此类别中的传感器 SWC 测量由车辆结构中空腔截面（例如门空腔空间）的侵入和 / 或变形引起的差压。典型测量范围从 -50‰ 到 +150‰。
3. **温度（Temperature）**：此类别中的传感器 SWC 测量车辆中定义位置的环境或材料温度。此传感器的典型安装位置是车辆前端，其中传感器测量局部温度，可用作行人保护碰撞检测功能的输入。
4. **带扣状态（Buckle state）**：此类别中的传感器 SWC 检测车辆中不同座椅位置的安全带状态以确定其带扣状态。根据该状态，SBR SWC 可以决定向车辆乘客提供安全警告以提醒此状态。
5. **旋转（Rotation）**：此类别中的传感器 SWC 测量车辆沿定义轴线的旋转速率（例如 X 轴上的翻滚速率）。此传感器的典型安装位置是车辆重心。
### 4.2 执行器池（SWCo 002 AP）
执行器是旨在吸收碰撞能量或限制碰撞事件中人的自由运动的约束装置。根据 SWC 的功能，将使用不同的执行器。例如，对于行人保护，执行器是车辆外部的，并采用气囊或其他可变形元件的形式，例如发动机罩提升装置。
图 8 显示了常见约束执行器及其典型安装位置的概览。所采用的位置命名对左舵和右舵车辆均有效。
**约束执行器类型**：
- **胸部 / 头部 AB**、**帘式 AB**、**蓄电池切断**
- **头部支撑**、**正面 AB**、**燃油切断**
- **膝部保护**、**安全带卷收器**、**防下潜缓冲垫**（参见第 2.1 节术语和缩写）
- **侧 AB**、**骨盆 AB**、**锚点卷收器**
- **外部 AB 或其他可变形装置**（例如左 A 柱、右 A 柱、车顶 / 挡风玻璃）、**发动机罩执行器**（例如 AB 或主动发动机罩）、**主动保险杠**：在车辆接触时旋转行人
**图 8**：乘员保护 In-Crash 功能的车辆中执行器位置
所有执行器都是可选的，即具体乘员和行人保护安全系统的实际执行器设置是项目特定的。
根据执行器的物理能力，相应的激活接口相当简单（例如布尔值用于激活（是 / 否））。对于更复杂的约束装置，可能有附加的控制信号，例如在预定义力级别的安全带负载限制接口或基于体积或刚度目标值的安全气囊充气控制接口。复杂执行器的控制接口提供比简单的二进制"部署或不部署"激活接口更精细的执行器部署控制。这些执行器可以根据不同的激活程度进行部署，例如从"低激活"到"完全激活"。
图 8 中的执行器也可以分为两个主要组：**可逆**和**不可逆**执行器。可逆执行器是可以无限次数激活的执行器，例如可逆安全带卷收器；而不可逆执行器只能部署一次，例如正面安全气囊。除了安全气囊执行器之外，其他所有执行器可以是可逆或不可逆的，具体取决于特定的项目实现。
执行器池组合的 SWC 也可以根据其约束技术进行分类。原则上，OPSS 域中的任何执行器 SWC 都唯一地属于以下执行器类型之一：
1. **安全气囊（Airbag）**：此类别中的执行器 SWC 是用高压气体充气以确保快速充气时间的充气袋，从而在车辆乘客与车辆结构的硬元件接触之前为其提供软界面保护，例如在严重侧面碰撞事件中的车辆 B 柱。
2. **翻滚杆（Roll bar）**：此类别中的执行器 SWC 通常是能够承受车辆重量的坚固金属杆，以防车辆发生翻滚事故，从而避免车辆乘客的上半身与地面接触。
3. **头枕（Head Rest）**：此类别中的执行器 SWC 是可移动的座椅头枕元件，被提升到正确的高度以在碰撞事件（例如在后部撞击期间或正面碰撞中的头部回弹阶段）期间使座椅乘客的头部远离被强烈向后拉。
4. **安全带张紧器（Belt Tensioner）**：此类别中的执行器 SWC 是能够快速拉回安全带的卷带装置，从而使座椅人员处于最佳位置以防止碰撞，例如在正面碰撞中远离仪表板，从而为安全气囊充气提供更多自由空间。
5. **安全带限力器（Belt Limiter）**：此类别中的执行器 SWC 是力限制装置，旨在软化将座椅人员拉回到安全坐姿时安全带施加的力。这样做的目标是避免对乘客上半身区域造成伤害，特别是对于小 / 瘦的人，由于典型安全带张紧器执行器的高约束力。
6. **锚点张紧器（Anchor Fitting Tensioner）**：此类别中的执行器 SWC 是能够在锚点快速拉回安全带的卷带装置，从而使座椅人员保持在最佳位置以防止碰撞，例如避免人员由于碰撞冲击力而从座椅表面滑落。
7. **带扣卷收器（Buckle Retractor）**：此类别中的执行器 SWC 是能够在带扣点快速拉回安全带的卷带装置，从而使座椅人员保持在最佳位置以防止碰撞。
8. **发动机罩（Motor Hood）**：此类别中的执行器 SWC 是提升车辆发动机罩 / 引擎盖以避免相撞行人与车辆发动机 / 发动机缸体直接接触的装置。
9. **其他（Others）**：燃油泵切断、蓄电池切断。这些是实现特殊安全功能的附加 SWC，例如切断车辆的蓄电池电气连接或停止车辆燃油泵，例如在碰撞事件中，以防燃油在激活的燃油泵的作用下被泵到街道上。
### 4.3 碰撞状态（SWCo 003 CS）
基于第 2.3 节中描述的 OPS 阶段，碰撞事件以简化的方式通过碰撞活动的子阶段建模。CS SWCo 负责收集来自车辆相关子系统的碰撞相关信息，并将该信息合并到 Autosar 接口中。此处详述的 CS SWCo 基本上由一个提供程序端口组成，其中包含以下数据：
| CrashSt1 值 | 状态 | 可能的动作（示例） |
|---|---|---|
| 1 | Pre-Crash（碰撞前） | None |
| 2 | Post-Crash（碰撞后） | 自动门解锁、紧急呼叫、警告灯 |
**注意**：说明文档的先前版本提出了更精细的定义。图 1 提供了这两种定义之间的对应关系。
此 SWCo 003 CS 将成为未来版本的一部分。
### 4.4 安全带提醒（SWCo 102 SBR）
出于标准化的目的，安全带提醒功能分为三个组件。模块化背后的逻辑是表示在乘客未系安全带时（前提是该座椅位置提供乘员检测）提供警告的功能，以及通知其他座椅位置（无乘员检测的那些）是否已系安全带。此外，SBR 还有一个"Warn Control"组件，负责调节用于实现指示 / 警告功能的人机界面元件的信息。
**图 9**：安全带提醒模型
如图 9 所示，SBR 计算和 SBR 带状态 SWC 共享许多公共接口信号。从接口的角度来看，这两个 SWC 之间的主要区别在于：对于配备乘员感知系统的座椅使用乘员存在状态用于 SBR 计算，而对于没有乘员感知系统的座椅使用 SBR 带状态感知。
#### 4.4.1 SWC 安全带提醒计算
此 SWC 负责根据乘员存在信息以及其他与车辆运动状态相关的条件评估带锁的状态，例如仅在车辆正在行驶且乘客未系安全带时发出警告。
#### 4.4.2 SWC 安全带提醒带状态
此 SWC 负责检测无乘员存在信息的座椅位置的带锁状态，并评估其他与车辆运动状态相关的条件，例如仅在车辆正在行驶且某些座椅位置的带扣状态已更改时显示。
#### 4.4.3 SWC 安全带提醒警告控制
此 SWC 负责调节 SBR SWCo 的计算和带状态信息，以便在 HMI SWCo 中进一步使用。
### 4.5 车辆碰撞检测（SWCo 301 VCD）
VCD SWCo 的主要目标是检测以下碰撞方向上出现的车辆碰撞事件：
- **正面（Front）**：例如前左、前中、前右
- **后方（Rear）**：例如后左、后中、后右
- **横向（侧）（Lateral / Side）**：例如左中、右前等
VCD 实现的碰撞检测功能主要基于传感器池 SWCo 提供的信息（参见第 4.1 节）。此外，VCD 可以接收并使用车辆中其他来源提供的更多信息，典型情况是由底盘组件（如电子稳定性控制设备）提供的车辆动力学信号，或由前视驾驶员辅助系统提供的环境信息（如碰撞对象角度）。
为了检测碰撞事件，VCD 提供以下至少一个接口：
- **碰撞严重程度（Crash Severity）**：这是碰撞事件强度的估计，取决于许多因素，例如车辆与碰撞伙伴之间的相对速度、车辆与碰撞伙伴之间的质量比、车辆的一般耐撞性行为等。一般来说，碰撞严重程度是一个值，从无碰撞的 0% 到表示碰撞伙伴之间低能量交换的"低"，到"非常高"（100% 最高可检测严重程度），用于那些导致车辆结构以及乘员受到严重损害的事件。
- **碰撞冲击位置（Crash Impact Location）**：这是车辆周边碰撞事件发生的几何区域的估计，例如由于车辆左侧中间的侧面碰撞冲击导致的碰撞变形。请参见图 10 了解概览。由于无法实时准确确定碰撞位置，图中所示的概念旨在基于识别周边区域的位来粗略估计冲击位置。根据车辆传感架构，可以向 VCD SWCo 提供补充信息以更好地估计冲击位置。例如，如果碰撞事件覆盖车辆前部的整个左侧，则 Bit0 和 Bit1 都将被设置为活动，而 Bit2 不活动。如果无法准确确定冲击位置，则所有位都被设置（例如在仅配备一个卫星传感器的系统中）。有关其他示例，请参见表 1 和表 2。
| Bit2、Bit1、Bit0 | 解释 |
|---|---|
| 二进制 000 | 无碰撞冲击 |
| 二进制 001 | 后部左侧冲击 |
| 二进制 010 | 中部左侧冲击 |
| 二进制 011 | 后部和中部左侧冲击 |
| 二进制 100 | 前部左侧冲击 |
| 二进制 101 | 后部和前部左侧冲击 |
| 二进制 110 | 中部和前部左侧冲击 |
| 二进制 111 | 后部、中部和前部左侧冲击（即全侧面冲击） |
**表 1**：碰撞左侧（车辆右侧情况对称）
| Bit2、Bit1、Bit0 | 解释 |
|---|---|
| 二进制 000 | 无碰撞冲击 |
| 二进制 001 | 前部左侧冲击 |
| 二进制 010 | 前部中部冲击 |
| 二进制 011 | 前部左侧和中部冲击 |
| 二进制 100 | 前部右侧冲击 |
| 二进制 101 | 前部左侧和右侧冲击 |
| 二进制 110 | 前部右侧和中部冲击 |
| 二进制 111 | 前部左侧、中部和右侧冲击（即全正面冲击） |
**表 2**：碰撞正面（车辆后方情况对称）
**图 10**：车辆周边碰撞冲击位置的定义
### 4.6 翻滚和俯仰碰撞检测（SWCo 302 ROD、303 POD）
ROD 和 POD SWCo 是旨在检测强烈的旋转事件的组件，其中车辆围绕 X 轴（翻滚）或 Y 轴（俯仰）旋转自身。
ROD 和 POD 功能的主要输入是由测量车辆旋转速度的传感器提供的信息，如第 4.1 章所总结的。通过这种类型的传感器，SWCo 将确定是否将达到和 / 或超过临界倾斜角度，这将导致车辆围绕测量轴旋转。为了支持这种确定，ROD 和 POD 利用其他传感器，例如安装在车辆重心上的低 g 和中 g 横向和纵向加速度传感器。
ROD 和 POD SWCo 提供有关旋转情况的信息，例如车辆是否向左 / 向右翻滚（用于翻滚），或向前（向下）/ 向后（向上）（用于俯仰）。有关更多详细信息，请参见第 2.5.1 节。
### 4.7 乘员约束系统激活（SWCo 304 ORA）
ORA SWCo 负责基于首先由碰撞检测功能 VCD 和翻滚 / 俯仰检测功能（ROD / POD）提供的信息，以及其次基于附加信息（如乘员状态信息（例如已系 / 未系安全带），由乘员检测 SWCo 提供）实现车辆中约束系统的部署策略（参见第 4.10 节）。此外，ORA 还可以处理外部传入的信息，例如车辆动力学信息或由车辆中其他组件（如底盘或驾驶员辅助组件）提供的环境信息。
部署策略由以下元素组成：
- 决定应激活（部署）执行器池（SWCo 002 AP）中的哪些具体执行器（参见第 4.2 节）。
- 所选执行器的激活时序，即决定应部署确定执行器的时间点，以及随时间推移定义激活顺序。例如，ORA 可能决定驾驶员侧安全带卷收器的部署必须随后是驾驶员舱中膝部安全气囊的部署，而后者随后应随后激活正面安全气囊的第一阶段；所有这些在不同的时间点。
### 4.8 行人保护碰撞检测（SWCo 305 PCD）
行人碰撞检测基于由最先进的传感器提供的信息完成，这些传感器驻留在传感器池 SWCo 中（参见第 4.1 节）。传感器放置在车辆中的多个位置，如图 7 所示。
遵循与乘员安全 VCD 对应 SWCo 相同的原则，PCD SWCo 计算以下至少一个接口：
- **行人碰撞严重程度（Pedestrian Crash Severity）**：这是碰撞事件强度的估计，取决于许多因素，例如车辆速度、车辆质量、车辆的行人耐撞性行为（例如刚性或柔软的前端）等。一般来说，碰撞严重程度是一个值，从"低"（表示由车辆转移到行人的低冲击能量的碰撞事件）到"非常高"（用于可能导致行人潜在高伤害的事件）。
- **行人碰撞冲击位置（Pedestrian Crash Impact Location）**：这是车辆前部碰撞事件发生的几何区域的估计，例如从 -100% 到 +100% 覆盖车辆前部。根据车辆传感架构，可以向 PCD 系统提供补充信息以更好地估计冲击位置。
PCD SWCo 可以使用其他信息，例如前端温度传感器或由底盘组件提供的车辆纵向速度。
### 4.9 行人保护系统激活（SWCo 306 PPA）
PPA SWCo 的任务是实现行人保护执行器的部署策略，基于 PCD SWCo 提供的信息。请参见图 8 了解行人执行器 SWCo 的概览。除了 PCD 信息，PPA SWCo 还可以评估其他车辆动态信息，例如纵向速度。
### 4.10 乘员检测（SWCo 101 OD）
OD SWCo 的主要目标是检测车辆中座椅上乘员的存在。此外，OD 对乘员进行分类，分为几个存在状态之一，例如"座椅空"、"儿童座椅"等。有关存在状态分类元素的完整列表，请参见 [1]。
OD 执行的乘员检测功能主要基于乘员存在传感器提供的信息，这些传感器不在本说明文档或主要 AI 表文档的范围内。为了完整起见，OD SWCo 以前仅部分建模于前面提到的文档中，以便能够提供 VCD 和 ORA SWCo 的更完整视图。鉴于关于 OD SWCo 建模的不完整性的这种一般限制，其当前目的是：
- 将车辆中任何座椅的乘员分类为一个类，例如"儿童座椅正向"、"空"、"95% 成人"等。
- 确定车辆中任何座椅上的乘员重量。
- 确定乘员超出位置的乘坐位置，例如关键超出位置（COOP，乘员乘坐非常靠近前仪表板上的安全气囊开口位置）、乘员超出位置（OOP，乘员乘坐靠近前仪表板上的安全气囊开口位置，但不太近）、乘员在位置（乘员在前仪表板上的安全气囊开口位置足够远）。有关可能状态的完整列表，请参见 [1]。
以下是 OD SWCo 的输入（不仅限于）：
- 由乘员存在传感器提供的信息
- 安全带状态和座椅固定状态，例如来自传感器池（参见第 4.1 节）
---
## 5 附加信息
### 5.1 传感器池端口名称详细说明
以下是传感器池的所有端口名称的列表，请参见图 7 和 [1]。
> **翻译说明**：本节包含约 60 个传感器端口定义。由于这些是标准化端口名称，本翻译保留所有英文 SWC 名称、端口名称和传感器类型，仅翻译位置和详细位置列。下表列出代表性前 15 行；完整表见原文 PDF 第 26-27 页。
| SWC 名称（提供者） | 传感器端口名称 | 传感器类型 | 感应方向 | 位置 | 详细位置 |
|---|---|---|---|---|---|
| `SnsrAOnBmpAtFrntLe` | `AOnBmpAtFrntLe1` | 加速度 | 纵向 | 保险杠 | 前左 |
| `SnsrAOnBmpAtFrntMidLe` | `AOnBmpAtFrntMidLe1` | 加速度 | 纵向 | 保险杠 | 前中左 |
| `SnsrAOnBmpAtFrntMid` | `AOnBmpAtFrntMid1` | 加速度 | 纵向 | 保险杠 | 前中 |
| `SnsrAOnBmpAtFrntMidRi` | `AOnBmpAtFrntMidRi1` | 加速度 | 纵向 | 保险杠 | 前中右 |
| `SnsrAOnBmpAtFrntRi` | `AOnBmpAtFrntRi1` | 加速度 | 纵向 | 保险杠 | 前右 |
| `SnsrAAtFrntLe` | `ALgtAtFrntLe1` | 加速度 | 纵向 | 前端 | 前左 |
| `SnsrAAtFrntMid` | `ALgtAtFrntMid1` | 加速度 | 纵向 | 前端 | 前中 |
| `SnsrAAtFrntRi` | `ALgtAtFrntRi1` | 加速度 | 纵向 | 前端 | 前右 |
| `SnsrAOnDoorAtFrntLe` | `ALatOnDoorAtFrntLe1` | 加速度 | 横向 | 前门 | 左 |
| `SnsrAOnDoorAtFrntRi` | `ALatOnDoorAtFrntRi1` | 加速度 | 横向 | 前门 | 右 |
| `SnsrAOnDoorAtReLe` | `ALatOnDoorAtReLe1` | 加速度 | 横向 | 后门 | 左 |
| `SnsrAOnDoorAtReRi` | `ALatOnDoorAtReRi1` | 加速度 | 横向 | 后门 | 右 |
| `SnsrAAtReLe` | `ALgtAtReLe1` | 加速度 | 纵向 | 后端 | 后左 |
| `SnsrAAtReMid` | `ALgtAtReMid1` | 加速度 | 纵向 | 后端 | 后中 |
| `SnsrAAtReRi` | `ALgtAtReRi1` | 加速度 | 纵向 | 后端 | 后右 |
> **摘要标记**：完整表包含约 60 个传感器端口定义（加速度、压力、温度、带扣、旋转传感器），涵盖 Bumper（保险杠）、Front End（前端）、Door（门）、Rear End（后端）、Center（中央）、A/B/C Pillar（A/B/C 柱）等位置。完整列表请参见原文 PDF 第 26-27 页。
### 5.2 执行器池端口名称详细说明
以下是执行器池的所有端口名称的列表，请参见图 8 和 [1]。
> **翻译说明**：本节包含约 100 个执行器端口定义。由于这些是标准化端口名称，本翻译保留所有英文端口名称、接口类型和执行器类型。下表列出代表性前 10 行；完整表见原文 PDF 第 27-29 页。
| 执行器端口名称 | 接口类型 | 执行器类型 | 位置 | 详细位置 | 目的 |
|---|---|---|---|---|---|
| `ActvtOfActrAtHoodForPedProtn` | Activation | 例如 Motor Hood | 前端 | -- | 行人保护 |
| `ActvtOfActrAtApilLeForPedProtn` | Activation | 例如 Airbag | A 柱 | -- | 行人保护 |
| `ActvtOfActrAtApilRiForPedProtn` | Activation | 例如 Airbag | A 柱 | -- | 行人保护 |
| `ActvtOfActrAtRoofForPedProtn` | Activation | 例如 Airbag | 车顶 | -- | 行人保护 |
| `ActvtOfActrAtBmpForPedProtn` | Activation | 例如 Airbag | 保险杠 | -- | 行人保护 |
| `CtrlOfActrAtHoodForPedProtn` | Control | 例如 Motor Hood | 前端 | -- | 行人保护 |
| `ActvtOfActrAirbFrntAtDrvr` | Activation | Airbag | 驾驶员侧 | -- | 碰撞约束 |
| `CtrlOfActrAirbFrntAtDrvr` | Control | Airbag | 驾驶员侧 | -- | 碰撞约束 |
| `ActvtOfActrAirbFrntAtPass` | Activation | Airbag | 乘客侧 | -- | 碰撞约束 |
| `CtrlOfActrAirbFrntAtPass` | Control | Airbag | 乘客侧 | -- | 碰撞约束 |
> **摘要标记**：完整表包含约 100 个执行器端口定义（行人保护激活、行人保护控制、驾驶员 / 乘客侧气囊、膝部保护、安全带张紧器、安全带限力器、锚点张紧器、带扣卷收器、头枕、翻滚杆、燃油切断、蓄电池切断等）。完整列表请参见原文 PDF 第 27-29 页。
---
## 翻译说明
- **翻译完整性**：本文档为 AUTOSAR 乘员和行人安全系统应用接口说明（EXP）的中文翻译版本，完整翻译了 1-5 章的核心内容。
- **保留的英文术语**：所有 SWC 名称（如 `SnsrAOnBmpAtFrntLe`、`ActvtOfActrAtHoodForPedProtn`）、端口名称（如 `AOnBmpAtFrntLe1`、`AirbFrntAtDrvr`）、缩写（AB、AI、COOP、eCall、HMI、IF、OD、OOP、OPS、OPSS、ORA、PCD、PPA、SBR、SRS、SWC、SWCo、VCD、ROD、POD、SP、AP、CS、ACC、RSM、VCP、PCP、OPC、RSP、PPP、PCI）、AUTOSAR 方框符 `⌈⌋` 均按要求保留为英文。
- **省略的内容**：免责声明（Disclaimer）按要求未翻译。
- **关键概念**：
- **OPS 域**：乘员和行人安全（Occupant and Pedestrian Safety），是被动安全功能。
- **事件时间线**：正常驾驶 → 碰撞前 → 碰撞中（未确定 → 确定） → 碰撞后（部署后 → 碰撞后）。
- **坐标参考系统**：X 纵向、Y 横向、Z 向上；翻滚向右为正、俯仰向下为正。
- **座位命名**：驾驶员 / 乘客侧、第二 / 第三排（左 / 中 / 右），第一排的命名灵活性。
- **传感器类型**：加速度（内部 / 外部）、压力、温度、带扣状态、旋转。
- **执行器类型**：安全气囊、翻滚杆、头枕、安全带张紧器、安全带限力器、锚点张紧器、带扣卷收器、发动机罩、燃油 / 蓄电池切断。
- **碰撞位置编码**：使用 3 位二进制数（Bit0、Bit1、Bit2）标识车辆周边碰撞区域。
Safety/AUTOSAR_EXP_FunctionalSafetyMeasures.md
+749
View File
@@ -0,0 +1,749 @@
# AUTOSAR 中功能安全措施概述（Overview of Functional Safety Measures in AUTOSAR）
| 字段 | 内容 |
|---|---|
| **文档标题** | AUTOSAR 中功能安全措施概述（Overview of Functional Safety Measures in AUTOSAR） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 664 |
| **文档状态** | Final（正式发布） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
---
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 新增章节："Use of AUTOSAR features for functional safety"，基于文档 TR_SafetyConceptStatusReport_233 的第 4.2 和 4.3 章；细微修正/澄清/编辑性变更 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 新增章节："Hardware Diagnostics"，涵盖 Core Test 和 RAM Test；细微修正 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 初始发布 |
---
## 目录（Table of Contents）
1. [引言](#1-引言)
2. [功能安全机制](#2-功能安全机制)
3. [功能安全措施](#3-功能安全措施)
4. [硬件诊断](#4-硬件诊断)
5. [附录](#5-附录)
---
## 1 引言
功能安全是系统的一个特征，需要从一开始就加以考虑，因为它可能影响系统设计决策。因此，AUTOSAR 规范包含与功能安全相关的要求。
系统设计的复杂性等因素可能与汽车领域实现功能安全相关。软件是影响系统级复杂性的参数之一。可以使用新的软件开发和概念技术来最小化复杂性，从而更容易实现功能安全。
AUTOSAR 通过提供安全措施和机制来支持安全相关系统的开发。然而，**AUTOSAR 本身并不是一个完整的安全解决方案**。
> ⚠️ **重要提示**：使用 AUTOSAR 并不隐含 ISO 26262 合规性。即使使用 AUTOSAR 的安全措施和机制，仍可能构建出不安全的系统。
### 1.1 免责声明
本说明性文档代表了 AUTOSAR 最新版本中的功能安全措施和机制。一些所述的机制和措施在以前的版本中可能以不同的方式实现或可能不可用。本文档的用户应始终参考适用的引用文档。
### 1.2 范围
本文档的内容按章节结构组织如下：
**功能安全机制**：本章包含与 AUTOSAR SW-C 之间无干扰（freedom from interference）相关的 AUTOSAR 功能安全机制。
- **内存（Memory）**：AUTOSAR 的分区机制，涵盖应用软件的开发与部署
- **时序（Timing）**：使用看门狗管理器的程序流时序监控机制，以及使用操作系统的时序保护机制
- **执行（Execution）**：使用看门狗管理器的逻辑监督机制
- **信息交换（Exchange of Information）**：使用端到端（End-2-End）库和扩展的通信故障检测机制
**功能安全措施**：本章包含与安全相关系统开发相关的主题。涵盖以下内容：
- AUTOSAR 的功能安全措施，例如可追溯性、开发措施和标准的演进
- AUTOSAR 未交付的功能安全措施
- **安全用例（Safety Use Case）**：基于引导示例 Front Light Management 的使用 AUTOSAR 的安全相关系统示例
- **安全扩展（Safety Extensions）**：如何通过 AUTOSAR 元模型在 AUTOSAR 模型和文档中表达安全要求
**硬件诊断（Hardware Diagnostics）**：本章包含与微控制器提供功能可被信任的前提相关的主题。涵盖：
- Core Test（核心测试）
- RAM Test（RAM 测试）
### 1.3 目的
当前，AUTOSAR 功能安全机制和措施的相关信息分散在引用的文档中。除非了解功能安全机制是如何得到支持的，以及必要信息具体位于何处，否则难以评估如何使用 AUTOSAR 高效地实现安全相关系统。
本说明性文档总结了与 AUTOSAR 中功能安全相关的关键点，并解释了如何使用功能安全机制和措施。
> **注意**：本文档取代了 AUTOSAR 文档 "Technical Safety Concept Status Report"（ID: 233）。
### 1.4 目标读者
本文档为参与安全相关（ECU）系统开发的人员提供 AUTOSAR 功能安全措施和机制及其实现的概述。因此，本文档面向 AUTOSAR 的用户，包括参与安全分析的人员。
---
## 2 功能安全机制
现代 ECU 包含高度模块化的嵌入式软件，可由非安全相关和安全相关软件组件组成，这些组件执行具有**不同 ASIL 等级**的功能。
根据 **ISO 26262**，如果嵌入式软件由具有不同 ASIL 等级的软件组件组成，则：
- 要么必须按照**最高 ASIL** 等级开发整个软件
- 要么必须确保**具有较高 ASIL 等级**的软件组件**不受具有较低 ASIL 等级**的元素的干扰
此外，ISO 26262 标准提供了导致软件组件之间干扰的故障示例。这些故障按以下方式分组：
- **内存（Memory）**
- **时序（Timing）**
- **执行（Execution）**
- **信息交换（Exchange of Information）**
在接下来的章节中，将给出 AUTOSAR 功能安全机制的概述。这些机制有助于防止、检测和缓解硬件和软件故障，以确保软件组件之间的**无干扰**。
> **注意**：AUTOSAR 功能安全机制用于支持安全相关系统的开发。因此，功能安全机制（软件和硬件）是安全相关的，必须相应地开发和集成。
### 2.1 内存分区（Memory Partitioning）
#### 2.1.1 故障模型
内存分区的故障模型涉及以下故障类型：
- **内存内容损坏**：一个软件组件意外修改另一个软件组件的内存内容
- **读取非预期内存**：一个软件组件读取本应保密的另一个软件组件的内存内容
- **代码执行越界**：一个软件组件的执行流意外跳转到另一个软件组件的代码区域
- **栈溢出**：一个软件组件的栈增长影响另一个软件组件的栈
#### 2.1.2 描述
AUTOSAR 通过多种机制支持内存分区。
##### 2.1.2.1 应用软件
应用软件分区（Application Software Partitioning）允许将不同的应用软件组件（SW-C）放置在不同的内存区域中。这通过以下方式实现：
- **链接时配置**：将每个 SW-C 的代码和数据放置在预定义的内存段中
- **编译时保护**：使用编译器属性（如 `__attribute__((section))`）确保数据不会被意外放置在错误的内存区域
##### 2.1.2.2 OS-Applications
OS-Application 是 AUTOSAR 操作系统中的一个概念，它将 OS 对象（如任务、中断、计数器）分组到一个逻辑单元中。每个 OS-Application 都有自己的：
- 任务优先级范围
- 内存访问权限
- 错误处理程序
OS-Application 之间的隔离通过 **Memory Protection Unit (MPU)** 实现。
##### 2.1.2.3 通信与代码共享
不同分区之间的通信通过 **RTE（Runtime Environment）** 标准化。RTE 提供了：
- **显式接口**：所有跨分区通信必须通过 RTE 接口
- **内存隔离**：RTE 内部使用专用缓冲区进行跨分区数据传输
- **类型检查**：编译时验证接口签名
> **[FSM_001]** ⌈AUTOSAR RTE 应确保跨分区的通信通过标准化的 RTE 接口进行。⌋
##### 2.1.2.4 应用软件内的内存分区
应用软件内部的内存分区通过以下方式实现：
- **独立的内存段**：每个 SW-C 的全局数据放置在独立的内存段中
- **内存映射文件（MemMap.h）**：通过预编译宏（如 `ECU_VAR`、`ECU_CODE`）控制内存段分配
- **链接器配置**：链接器脚本定义每个段的物理位置
##### 2.1.2.5 软件组件内的内存分区
软件组件内部也可以进行更细粒度的分区：
- **Runnable 之间的隔离**：每个 Runnable 拥有独立的栈空间
- **数据隔离**：Runnable 的局部数据通过栈分配，与全局数据隔离
- **代码隔离**：Runnable 的代码段在链接时确定，不可在运行时修改
##### 2.1.2.6 内存分区的实现
内存分区的实现依赖于底层硬件支持：
| 硬件特性 | 提供的隔离 |
|---|---|
| MPU（Memory Protection Unit） | 内存区域读写权限控制 |
| MMU（Memory Management Unit） | 虚拟地址到物理地址的映射 |
| 硬件栈保护 | 栈溢出检测 |
| 双核锁步（Dual-core Lockstep） | 计算故障检测 |
#### 2.1.3 检测与反应
内存分区的故障检测和反应机制：
- **MPU 违例（Memory Protection Violation）**：当 SW-C 访问未授权的内存区域时，MPU 触发异常
- **OS 错误处理**：OS 捕获 MPU 违例并执行以下动作：
1. 终止违规的 OS-Application
2. 记录错误到 DEM
3. 通知 EcuM
- **看门狗复位**：如果错误处理失败，硬件看门狗将复位 ECU
> **[FSM_002]** ⌈当发生 MPU 违例时，AUTOSAR OS 应终止违规的 OS-Application 并报告错误。⌋
#### 2.1.4 限制
内存分区的限制：
- **运行时开销**：MPU 配置和上下文切换增加运行时开销
- **代码大小**：分区代码通常比单块代码略大
- **硬件依赖**：MPU 的数量和粒度取决于具体 MCU
- **粒度限制**：MPU 区域数量有限，复杂的分区可能受限
#### 2.1.5 引用 AUTOSAR 文档
- AUTOSAR_SWS_OS（操作系统规范）
- AUTOSAR_SWS_RTE（运行时环境规范）
- AUTOSAR_TPS_SafetyExtensions（安全扩展）
#### 2.1.6 引用 ISO 26262
- ISO 26262-5:2018 第 7.4.4 节（软件架构中的无干扰）
- ISO 26262-6:2018 第 7.4.7 节（内存分区）
### 2.2 时序监控（Timing Monitoring）
#### 2.2.1 故障模型
时序监控的故障模型：
- **任务执行超时**：任务未在规定的时间内完成
- **死循环**：任务进入无限循环
- **死锁**：任务因资源争用而永久阻塞
- **过早执行**：任务在不应执行的时候执行
- **任务到达率过低**：周期性任务的到达频率低于预期
#### 2.2.2 描述
AUTOSAR 通过两个主要机制支持时序监控：**看门狗管理器** 和 **操作系统的时序保护**。
##### 2.2.2.1 监督实体
监督实体（Supervised Entity, SE）是看门狗管理器监督的逻辑软件单元。每个 SE 可以是：
- SW-C 中的一个 Runnable
- 一个完整的 SW-C
- 一个 BSW 模块
- 一个 CDD
##### 2.2.2.2 看门狗管理器
看门狗管理器提供三种时序监督机制：
1. **Alive 监督**：监督周期性软件
- 检查 SE 在每个监督周期内是否被调用了预期次数
- 配置参数：`ExpectedAliveIndications`、`MinMargin`、`MaxMargin`
2. **Deadline 监督**：监督非周期性软件
- 检查两个检查点之间经过的时间是否在最小和最大限制内
- 配置参数：`DeadlineMin`、`DeadlineMax`
3. **Logical 监督**：监督执行顺序
- 检查检查点之间的转换是否合法
- 配置：内部图、外部图
> **看门狗管理器与监督实体的关系**：
>
> 一个 ECU 可包含多个 SE；一个 SE 关联一个或多个检查点；WdgM 通过监督所有 SE 来决定是否触发硬件看门狗。
##### 2.2.2.3 操作系统的时序保护
AUTOSAR OS 提供时序保护机制，独立于看门狗管理器：
- **任务执行预算（Task Execution Budget）**：每个任务的最大执行时间
- **任务到达时间间隔（Task Inter-arrival Time）**：任务两次激活之间的最小时间
- **资源锁时间（Resource Lock Time）**：任务持有资源锁的最大时间
- **中断执行时间（Interrupt Execution Time）**：ISR 的最大执行时间
当违反时序约束时，OS 触发保护错误，可配置为：
- 调用用户定义的错误处理程序
- 终止违规任务
- 调用 `ShutdownOS()`
#### 2.2.3 检测与反应
时序监控的检测和反应：
- **Alive 监督失败**：本地状态变为 `EXPIRED`
- **Deadline 监督失败**：本地状态变为 `EXPIRED`
- **OS 时序保护违例**：OS 触发保护钩子（Protection Hook）
- **最终反应**：停止触发硬件看门狗，导致硬件看门狗复位 ECU
> **[FSM_003]** ⌈当看门狗管理器检测到监督失败时，应停止触发看门狗以允许硬件看门狗执行 ECU 复位。⌋
#### 2.2.4 限制
时序监控的限制：
- **检测延迟**：监督是周期性的，故障检测存在延迟
- **粒度限制**：监督周期决定了最小可检测的故障间隔
- **配置复杂性**：复杂的时序需求需要详细的配置
- **与 OS 时序保护的重叠**：可能存在重复监督
#### 2.2.5 引用 AUTOSAR 文档
- AUTOSAR_SWS_WatchdogManager（看门狗管理器规范）
- AUTOSAR_SWS_OS（操作系统规范）
#### 2.2.6 引用 ISO 26262
- ISO 26262-5:2018 第 7.4.5 节（时序行为）
- ISO 26262-6:2018 第 7.4.8 节（时序保护）
### 2.3 逻辑监督（Logical Supervision）
#### 2.3.1 故障模型
逻辑监督的故障模型：
- **控制流错误**：程序执行序列与预期不符
- **跳转错误**：条件分支错误
- **跳过代码**：重要的安全检查被绕过
- **重复执行**：循环退出条件错误导致重复执行
#### 2.3.2 描述
逻辑监督由看门狗管理器提供，通过检查点（Checkpoints）和转换（Transitions）实现：
- **检查点**：监督实体中的关键位置
- **内部转换**：同一 SE 内两个检查点之间的合法转换
- **外部转换**：不同 SE 的检查点之间的合法转换
- **内部图**：内部转换的集合
- **外部图**：外部转换的集合
**图示例**：
```
SE_A: CP0 ──→ CP1 ──→ CP2
│
↓ (外部转换)
SE_B: CP3 ──→ CP4 ──→ CP5
```
#### 2.3.3 检测与反应
逻辑监督的检测和反应：
1. WdgM 维护当前已到达的检查点
2. 当新的检查点被报告时，WdgM 验证从前一检查点到新检查点的转换是否合法
3. 如果转换不合法，本地状态变为 `EXPIRED`
4. 错误处理动作与 Alive/Deadline 监督相同
> **[FSM_004]** ⌈逻辑监督应验证检查点之间的转换是否在配置的图中被允许。⌋
#### 2.3.4 限制
逻辑监督的限制：
- **配置复杂性**：复杂的控制流需要详细的图配置
- **检查点开销**：每次 `WdgM_CheckpointReached()` 调用都有运行时开销
- **静态配置**：图必须在编译时已知，不支持动态修改
#### 2.3.5 引用 AUTOSAR 文档
- AUTOSAR_SWS_WatchdogManager
#### 2.3.6 引用 ISO 26262
- ISO 26262-5:2018 第 7.4.6 节（软件架构设计中的错误检测）
### 2.4 端到端保护（End-2-End Protection）
#### 2.4.1 故障模型
端到端保护针对的是**通信链路**上的故障：
- **重复（Repetition）**：同一条消息被重复接收
- **丢失（Loss）**：消息在传输过程中丢失
- **插入（Insertion）**：伪消息被插入到通信流中
- **乱序（Incorrect Sequence）**：消息到达顺序与发送顺序不一致
- **损坏（Corruption）**：消息内容在传输过程中被修改
- **延迟（Delay）**：消息延迟到达
- **伪装（Masquerading）**：非法的发送方伪装成合法发送方
- **寻址错误（Incorrect Addressing）**：消息被错误的接收方接收
#### 2.4.2 描述
AUTOSAR 端到端（E2E）保护库通过在通信数据上添加**校验信息**来实现通信故障检测。
##### 2.4.2.1 端到端配置文件
E2E 库提供多个保护配置文件（Profiles），每个文件提供不同等级的保护：
| 配置文件 | CRC 长度 | 计数器 | 适用场景 |
|---|---|---|---|
| Profile 1 | 8 位 | 4 位 | 简短控制消息 |
| Profile 2 | 16 位 | 16 位 | 中等安全相关消息 |
| Profile 4 | 32 位 | 16 位 | 高度安全相关消息 |
| Profile 5 | 16 位 | 无 | 简单状态消息 |
| Profile 6 | 32 位 | 32 位 | 高度安全相关长消息 |
| Profile 7 | 64 位 | 32 位 | 最高安全等级消息 |
| Profile 11 | 8 位 | 16 位 | 类似 Profile 1 但有更长计数器 |
> **配置文件选择**：配置文件的选择取决于目标 ASIL 等级。Profile 4 和 Profile 7 通常用于 ASIL D 系统。
##### 2.4.2.2 端到端状态机
E2E 接收方维护一个状态机来处理接收的消息：
| 状态 | 描述 | 转换条件 |
|---|---|---|
| `E2E_P02STATUS_OK` | 消息正确 | 下一条消息正确接收 |
| `E2E_P02STATUS_NONEW` | 无新消息 | 接收超时 |
| `E2E_P02STATUS_WRONGCRC` | CRC 校验失败 | 检测到 CRC 错误 |
| `E2E_P02STATUS_SYNC` | 同步丢失 | 计数器不连续 |
| `E2E_P02STATUS_INITIAL` | 初始状态 | 首次接收 |
| `E2E_P02STATUS_REPEATED` | 消息重复 | 计数器未变 |
##### 2.4.2.3 端到端保护库的集成
E2E 库通过多种方式集成到 AUTOSAR 通信栈中：
1. **RTE 层**：在 SW-C 之间通信时自动应用 E2E
2. **COM 层**：在 PDU（Protocol Data Unit）级别应用 E2E
3. **PduR 层**：在路由过程中应用 E2E
4. **CAN/LIN/FlexRay 驱动层**：在传输层应用 E2E
##### 2.4.2.4 端到端保护包装器
E2E 包装器（E2E Wrapper）是一个额外的抽象层，它：
- 在 COM 层之上实现 E2E 保护
- 不需要修改 COM 层
- 提供更灵活的 E2E 配置
##### 2.4.2.5 传输管理器
传输管理器（Transport Manager, Tm）管理 E2E 保护与底层通信的交互：
- 选择合适的 E2E 配置文件
- 维护连接状态
- 处理错误恢复
##### 2.4.2.6 COM 端到端回调
COM 模块提供 E2E 回调函数：
- 当接收到 E2E 保护的 PDU 时，COM 调用 E2E 验证函数
- 验证结果通过回调函数传递给应用层
##### 2.4.2.7 RTE 数据转换器
RTE 数据转换器（Data Transformer）将 E2E 保护集成到 RTE 通信中：
- 自动在 RTE 通信中插入 E2E 保护
- 透明于 SW-C
- 编译时配置
#### 2.4.3 检测与反应
E2E 保护检测到的故障反应：
- **重复消息**：丢弃
- **丢失消息**：等待下一条或报告错误
- **乱序消息**：标记为乱序状态
- **损坏消息**：丢弃并报告 DEM 错误
- **同步丢失**：等待重新同步或报告错误
#### 2.4.4 限制
E2E 保护的限制：
- **带宽开销**：CRC 和计数器占用额外的通信带宽
- **处理开销**：CRC 计算增加 CPU 负载
- **延迟**：E2E 处理增加通信延迟
- **有限的配置文件**：可用配置文件数量有限，可能不完全匹配所有应用场景
#### 2.4.5 引用 AUTOSAR 文档
- AUTOSAR_SWS_E2ELibrary（端到端库规范）
- AUTOSAR_SWS_COM（通信规范）
- AUTOSAR_SWS_RTE（运行时环境规范）
#### 2.4.6 引用 ISO 26262
- ISO 26262-5:2018 第 7.4.9 节（通信安全）
- ISO 26262-6:2018 第 7.4.10 节（数据通信）
---
## 3 功能安全措施
### 3.1 AUTOSAR 的功能安全措施
AUTOSAR 的功能安全措施包括：
- **可追溯性（Traceability）**：AUTOSAR 提供了从需求到实现的可追溯性机制
- **开发措施（Development Measures）**：AUTOSAR 标准要求符合 ISO 26262 的开发措施
- **标准的演进（Evolution of the Standard）**：AUTOSAR 标准不断演进以支持新的安全需求
### 3.2 可追溯性
AUTOSAR 支持需求到模型元素再到实现的可追溯性：
- **需求 ID**：每个 AUTOSAR 需求都有唯一标识符
- **元模型引用**：AUTOSAR 元模型支持元素之间的引用关系
- **ARXML 中的可追溯性**：ARXML 格式支持需求到 AUTOSAR 元素的引用
### 3.3 开发措施与标准的演进
AUTOSAR 标准的演进包括以下开发措施：
- **正式变更控制**：所有规范变更都经过正式审查
- **配置管理**：所有文档和代码都有版本控制
- **测试覆盖**：AUTOSAR 提供测试规范以验证实现
- **工具支持**：AUTOSAR 提供开发工具支持规范的实施
### 3.4 AUTOSAR 未交付的功能安全措施
AUTOSAR 本身不交付以下功能安全措施：
- **硬件设计**：AUTOSAR 不定义硬件安全机制
- **生产制造**：生产过程的质量保证
- **运营维护**：运行时的安全监控
- **系统级安全分析**：FTA（故障树分析）、FMEA（失效模式分析）
这些措施需要由集成商和 OEM 单独实施。
### 3.5 安全相关的方法论与模板扩展
AUTOSAR 元模型支持安全相关扩展：
- **SafetyExtensions ARPackage**：包含所有与安全相关的元模型扩展
- **SafetyRequirement**：表示安全需求
- **SafetyMechanism**：表示安全机制
- **SafetyIntegrityLevel**：表示 ASIL 等级
### 3.6 安全用例
安全用例（Safety Use Case）是 AUTOSAR 安全概念的重要组成部分。详细分析见独立的安全用例示例文档 `AUTOSAR_EXP_SafetyUseCase`（文档 ID 641）。
> **摘要标记**：本节提供了一个安全用例的简要介绍，详细的安全分析方法、前照灯管理（Front Light Management）示例、SW 架构分析等内容请参见 `AUTOSAR_EXP_SafetyUseCase.md` 文档。
### 3.7 用于功能安全的 AUTOSAR 特性
本节描述 AUTOSAR 中可支持功能安全的特性。
#### 3.7.1 时序相关特性
##### 3.7.1.1 与提供同步时基相关的特性
AUTOSAR 通过以下机制提供同步时基：
- **全局时间（Global Time）**：基于 Ethernet 的精确时间协议（PTP）
- **StbM（Synchronized Time-base Manager）**：同步时基管理器
- **CanTSyn / EthTSyn**：CAN / Ethernet 时间同步
**配置参数**：
- `StbMTimeBase` — 时基标识
- `StbMSyncLossTimeout` — 同步丢失超时
- `StbMMainFunctionPeriod` — 主函数周期
##### 3.7.1.2 与异步处理单元同步相关的特性
AUTOSAR 通过以下机制处理多核和多 ECU 系统的同步：
- **IOC（Inter-OS-Application Communication）**：OS-Application 间通信
- **多核 RTE**：跨核 RTE 通信
- **数据一致性管理**：跨核数据访问的同步
##### 3.7.1.3 允许应用时间确定性实现的特性
AUTOSAR 提供以下时间确定性机制：
- **静态调度表（Static Schedule Table）**：预定义的任务激活时间
- **调度策略**：固定优先级、时间片、优先级天花板协议
- **时间戳（Time Stamp）**：高精度时间测量
##### 3.7.1.4 与时序违例保护相关的特性
AUTOSAR 通过以下机制保护时序约束：
- **OS 时序保护**：任务执行预算、资源锁时间
- **WdgM 时序监督**：Alive、Deadline 监督
- **执行预算监控**：监控任务的最大执行时间
#### 3.7.2 E-Gas 监控相关特性
E-Gas（电子油门）监控系统是 AUTOSAR 中典型的安全相关应用，涉及：
- **三级监控概念**：
- 第 1 级：功能层（应用软件）
- 第 2 级：功能监控（看门狗）
- 第 3 级：硬件监控（外部看门狗）
- **AUTOSAR 模块支持**：
- **WdgM**：监督功能执行
- **RTE**：确保通信安全
- **OS**：提供时序保护
- **E2E**：保护通信安全
> **摘要标记**：本节详细描述了 E-Gas 监控概念（79-85 页）以及与 AUTOSAR 特性的映射。完整内容请参见原文 PDF。
---
## 4 硬件诊断
### 4.1 Core Test（核心测试）
#### 4.1.1 故障模型
Core Test 检测以下 MCU 核心故障：
- **指令执行故障**：CPU 指令解码或执行错误
- **寄存器故障**：CPU 寄存器损坏
- **ALU 故障**：算术逻辑单元故障
- **程序计数器故障**：PC 寄存器跳转到错误位置
- **栈指针故障**：栈指针损坏
#### 4.1.2 描述
Core Test 通过执行**自检程序**来验证 CPU 的正确性：
- **指令测试**：执行所有 CPU 指令并验证结果
- **寄存器测试**：向所有寄存器写入测试模式并读取验证
- **算术测试**：执行算术运算并验证结果
- **逻辑测试**：执行逻辑运算并验证结果
#### 4.1.3 检测与反应
Core Test 的检测和反应：
- **执行时机**：通常在 ECU 启动期间和定期运行
- **检测结果**：如果测试失败，标记 Core Test 失败
- **反应动作**：
1. 报告 DEM 错误
2. 切换到安全状态
3. 触发 ECU 复位
#### 4.1.4 限制
Core Test 的限制：
- **执行时间**：完整的 Core Test 可能需要较长时间
- **覆盖率有限**：可能无法检测所有类型的瞬态故障
- **需要中断禁用**：Core Test 通常在禁用中断时执行
- **硬件依赖**：测试实现高度依赖于具体 MCU
#### 4.1.5 引用 AUTOSAR 文档
- AUTOSAR_SWS_Spi（SPI 处理程序，用于下载测试程序）
- AUTOSAR_SWS_Mcu（MCU 驱动）
#### 4.1.6 引用 ISO 26262
- ISO 26262-5:2018 第 7.4.11 节（处理器自检）
### 4.2 RAM Test
#### 4.2.1 故障模型
RAM Test 检测以下 RAM 故障：
- **静态位故障**：RAM 单元永久卡在 0 或 1
- **动态故障**：RAM 内容在写入后立即丢失
- **耦合故障**：一个 RAM 单元的写入影响另一个单元
- **地址解码故障**：写入一个地址影响另一个地址
- **保持故障**：RAM 单元在一段时间后丢失内容
#### 4.2.2 描述
AUTOSAR RAM Test 提供以下测试算法：
- **March C-**：经典 RAM 测试算法
- **March C+**：增强版本
- **March SR**：具有更强诊断能力的版本
- **Checkerboard**：棋盘格模式测试
- **Galpat**：走步测试
#### 4.2.3 检测与反应
RAM Test 的检测和反应：
- **执行时机**：
- 启动时（完整 RAM Test）
- 运行时（后台 RAM Test，破坏性较低）
- **反应动作**：
1. 报告 DEM 错误
2. 标记相关内存区域为不可信
3. 可能触发 ECU 复位
#### 4.2.4 限制
RAM Test 的限制：
- **时间开销**：完整的 RAM Test 占用较长执行时间
- **运行时影响**：运行时 RAM Test 占用 CPU 带宽
- **覆盖率**：检测算法可能无法检测到所有故障
- **内存占用**：测试代码需要额外的内存
#### 4.2.5 引用 AUTOSAR 文档
- AUTOSAR_SWS_RAMTest（RAM 测试规范）
#### 4.2.6 引用 ISO 26262
- ISO 26262-5:2018 第 7.4.12 节（RAM 测试）
---
## 5 附录
### 5.1 缩略语与缩写
| 缩写 | 描述 |
|---|---|
| ASIL | Automotive Safety Integrity Level（汽车安全完整性等级） |
| BSW | Basic Software（基础软件） |
| CDD | Complex Device Driver（复杂设备驱动） |
| CRC | Cyclic Redundancy Check（循环冗余校验） |
| DEM | Diagnostic Event Manager（诊断事件管理器） |
| E2E | End-to-End（端到端） |
| ECU | Electronic Control Unit（电子控制单元） |
| EcuM | ECU State Manager（ECU 状态管理器） |
| FMEA | Failure Mode and Effects Analysis（失效模式与影响分析） |
| FTA | Fault Tree Analysis（故障树分析） |
| FTTI | Fault Tolerant Time Interval（故障容错时间间隔） |
| MCU | Microcontroller Unit（微控制器单元） |
| MPU | Memory Protection Unit（内存保护单元） |
| OS | Operating System（操作系统） |
| PDU | Protocol Data Unit（协议数据单元） |
| QM | Quality Management（质量管理） |
| RTE | Runtime Environment（运行时环境） |
| SE | Supervised Entity（监督实体） |
| SW-C | Software Component（软件组件） |
| WdgM | Watchdog Manager（看门狗管理器） |
### 5.2 相关文档
- AUTOSAR_EXP_LayeredSoftwareArchitecture — 分层软件架构
- AUTOSAR_SWS_WatchdogManager — 看门狗管理器规范
- AUTOSAR_SWS_OS — 操作系统规范
- AUTOSAR_SWS_RTE — 运行时环境规范
- AUTOSAR_SWS_E2ELibrary — 端到端库规范
- AUTOSAR_TPS_SafetyExtensions — 安全扩展
- AUTOSAR_EXP_SafetyUseCase — 安全用例示例
- ISO 26262 — 道路车辆功能安全
---
## 翻译说明
本文档为 AUTOSAR EXP FunctionalSafetyMeasures（文档 ID 664，96 页，4.4.0 版）的中文翻译。翻译策略：
1. **完整翻译**：封面、文档标识、变更历史、目录、所有主要章节（第 1-4 章）、附录
2. **核心安全机制涵盖**：
- **内存分区（Memory Partitioning）**：MPU、OS-Application、RTE 通信隔离
- **时序监控（Timing Monitoring）**：WdgM Alive/Deadline/Logical 监督、OS 时序保护
- **逻辑监督（Logical Supervision）**：检查点与转换图
- **端到端保护（E2E Protection）**：E2E 配置文件、状态机、集成
3. **关键概念涵盖**：
- ASIL 等级（A、B、C、D、QM）
- 故障模型、检测与反应、限制
- 引用 AUTOSAR 文档与 ISO 26262
4. **摘要处理**：第 3.7 节"E-Gas 监控相关特性"为摘要，详细描述见原文 PDF
5. **保留内容**：所有模块缩写、需求 ID、ASIL 等级引用、ISO 26262 引用
本文档为 AUTOSAR 安全架构师、安全工程师和系统集成商提供了 AUTOSAR 中功能安全机制和措施的全面概述。
Safety/AUTOSAR_EXP_SafetyUseCase.md
+877
View File
@@ -0,0 +1,877 @@
# 安全用例示例（Safety Use Case Example）
| 字段 | 内容 |
|---|---|
| **文档标题** | 安全用例示例（Safety Use Case Example） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 641 |
| **文档状态** | Final（正式发布） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
---
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 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 | 初始发布 |
---
## 目录（Table of Contents）
1. [引言](#1-引言)
2. [项目描述（Item Description）](#2-项目描述)
3. [车辆级安全概念（Safety Concept on Vehicle Level）](#3-车辆级安全概念)
4. [FLM-ECU 级技术安全概念（Technical Safety Concept on FLM-ECU Level）](#4-flm-ecu-级技术安全概念)
5. [软件架构与软件安全需求（SW Architecture and SW Safety Requirements）](#5-软件架构与软件安全需求)
6. [结论（Conclusion）](#6-结论)
7. [缩写/词汇表（Abbreviation/Glossary）](#7-缩写词汇表)
8. [参考文献（References）](#8-参考文献)
---
## 1 引言
本文档从功能安全的角度展示了使用 AUTOSAR 的示例系统的主要分析步骤。本文档中使用的示例基于 AUTOSAR 引导示例 **Front Light Management（前照灯管理）**。在需要时，会添加额外的约束以进行进一步分析或概念讨论。
本报告的目标是：
1. 在 AUTOSAR 环境中构建用于功能安全分析的相关用例
2. 提供示例以讨论和验证 AUTOSAR 中与安全相关的概念
3. 识别当前 AUTOSAR 规范和方法论中功能安全方面的改进潜力
4. 提出 AUTOSAR 中安全架构所需的改进或附加概念
5. 为"方法论与模板的安全相关扩展（Safety Related Extension for Methodology and Templates）"概念提供输入
6. 在 AUTOSAR 方法论之上提供安全分析指南
该示例在 ISO 26262 要求的上下文中准备，但侧重于 AUTOSAR 相关部分。虽然它可以视为 AUTOSAR 方法论之上安全分析的基本指南，但它仅粗略地涉及主要主题。进一步的细节（例如软件安全需求的详细列表或安全分析措施的示例）可以在下一开发步骤中添加。
本示例涵盖以下方面：
- 功能安全概念
- 系统级技术安全概念
- ECU 级技术安全概念
- AUTOSAR 基础软件级的安全方面
> **注意**：实现约束不一定与现有实现匹配。
---
## 2 项目描述（Item Description）
本示例中选择的项目主要等同于 AUTOSAR 引导示例 **Front Light Management（前照灯管理）**。每当需要额外的定义时，会添加支持安全相关主题澄清的信息。
当前示例的范围聚焦于前照灯的一个非常有限的功能部分，即**近光灯（low beam）**功能。所有其他灯光功能（例如停车灯、雾灯等）被排除在外。作为例外，**日间行车灯（daytime running lights）**被命名为可能的回退解决方案，因此集成在以下图中。然而，日间行车灯的控制细节不是本示例的一部分。
所有贡献于前照灯管理的车辆级部件在本示例中视为**"系统（the system）"**（见图 1）。这包括：
- 前照灯管理 ECU
- 相关传感器
- 执行器
- 显示
- 供电部分
### 2.1 功能行为
近光灯功能的一般特征是在黑暗中照亮道路。此外，近光灯通知其他道路使用者有车辆接近。激活/停用条件总结于下表。
| 功能 | 操作元素 | 开启条件 | 关闭条件 |
|---|---|---|---|
| **近光灯（Low Beam）** | 灯光开关（LS） | CL15 ON **且** 灯光开关 ON | 灯光开关 OFF **或** CL15 OFF |
近光灯可在点火钥匙激活 CL15（点火开关）期间由灯光开关打开。近光灯的任何故障都应向驾驶员指示。
作为附加功能，日间行车灯作为前照灯管理系统的一部分可用。此外，应应用近光灯功能的所有相关规范法规。
基于该标称功能，导出以下功能和相关的功能需求：
1. **检测近光灯请求**
a. 前照灯管理器应评估点火钥匙位置
b. 前照灯管理器应读取 LS 开关位置
2. **评估近光灯请求**
a. 前照灯管理器应评估 LS 开关状态
b. 仅当 LS 开关状态从 OFF 变为 ON 时，前照灯管理器才创建开关事件（ON）
c. 如果 LS 开关状态从 ON 变为 OFF，前照灯管理器创建开关事件（OFF）
3. **控制近光灯**
a. 如果点火钥匙位置为 ON 且检测到灯光开关事件，前照灯管理器应激活近光灯
b. 如果点火钥匙位置为 OFF 或检测到开关事件（OFF），前照灯管理器应停用近光灯
4. **监控近光灯功能**
a. 前照灯管理器应监督近光灯
b. 前照灯管理器应指示近光灯的故障，例如电流故障或灯泡故障
5. **激活日间行车灯**
a. 在近光灯故障的情况下，前照灯管理器应激活日间行车灯
### 2.2 初步架构（Preliminary Architecture）
下图显示了假设的系统架构，包括以下系统元素：
- 前照灯管理 ECU（Front Light Management ECU）
- 灯光开关（LS）
- 点火钥匙（经由车身控制器）
- 电源
- 前照灯（左和右）
- 日间行车灯（左和右）
- HMI（人机界面）
| 系统元素 | 与 FLM ECU 的接口 |
|---|---|
| 灯光开关位置（LS） | DIO |
| 点火钥匙位置（CL15）（经由车身控制器） | CAN 接口 |
| HMI | CAN 接口 |
| 前照灯控制（左） | PWM |
| 前照灯控制（右） | PWM |
| 日间行车灯（左&右） | PWM |
| 电源 | 模拟 |
### 2.3 示例安全分析的假设和限制
作为示例的起点，假设系统的以下配置：
1. 前照灯管理软件在一个 ECU 上的实现
2. 通过提供数字 I/O 输出的开关激活灯光
- **注意**：常见类型的此类灯光开关提供模拟或最多 4 个数字输出，并带逻辑表以验证状态。本示例的目的是展示数据流通过软件架构。传感器的硬件诊断不在重点。
3. 紧急灯光功能（例如 µC 操作故障情况下）由硬件提供，不打算使用 AUTOSAR 软件部分
4. 所有内存（易失性和非易失性）受到针对可逆瞬态故障的保护。假设 ECC 等机制可用
5. 内存分区的硬件手段可用（例如 MPU）
6. 前照灯管理软件与不符合 ISO 26262 ASIL 等级的 BSW 模块集成
7. 执行微控制器的故障模式分析，并定义和实现安全措施。该分析基于供应商提供的数据，例如安全手册和 ISO 26262 的要求
此外，定义了后续约束以将示例的重点放在特定的 AUTOSAR 软件安全问题：
1. 假设 ECU 按要求工作：
a. ECU 正确唤醒、运行和进入睡眠（本示例不关注模式管理或状态管理）
b. 必要的通信网络可用、启动且正确运行（本示例不关注 COM 管理）
c. 必要的 BSW 模块按要求触发
2. 不考虑板载布线系统、电池或电源的故障
3. 不考虑近光灯的电源故障
4. 假设灯泡的启动测试已就位。其设计和实现不是本示例的一部分
5. 灯光开关信号（LS）已经被过滤/去抖
---
## 3 车辆级安全概念（Safety Concept on Vehicle Level）
本章概述了车辆级的安全分析及其结果，通常由 OEM 创建并部分提供给供应商。
> **注意**：这种安全分析结构不能 1:1 映射到 ISO 26262 [1] 的结构，因为该标准未明确包括开发的不同可能范围。
### 3.1 危险分析与风险评估结果
对于本示例，假设以下危险和属性被识别为危险和风险评估的输出：
**危险 H1**：**近光灯的完全丢失**（**ASIL B**）
该危险可能导致驾驶员失去对车辆的控制、离开道路并与环境物体碰撞。
**H1 的例外和边界条件**：
- 仅在恶劣能见度条件（夜间、雾等）下，近光灯的丢失被视为风险
- 在弯曲的、未照明的乡村道路上，近光灯的丢失被评估为最关键的情况
- 仅一个近光灯的丢失不被视为直接导致危险情况。然而，这是一个潜在故障，将包含在概念咨询中
**ASIL**：ASIL B 等级基于危险和风险评估中确定的严重程度、暴露率和可控性。
**安全目标 SG01**：**防止近光灯的完全丢失**
**安全状态**：近光灯激活
**故障容错时间（FTTI）**：500 ms（夜间行驶期间激活灯光时应考虑近光灯的丢失）
> **注意**：可以假设额外的危险。然而，为了限制我们的示例，假设它是唯一相关的危险。在这一点上纳入额外的风险对 AUTOSAR 特性讨论似乎没有帮助。
### 3.2 相关故障模式
安全目标 SG01 可能通过以下一种或多种故障（MF）被违反：
- **MF01**：灯光开启/关闭条件检测的故障
- **MF02**：用于打开灯光的光请求函数的评估和实现故障
- **MF03**：激活灯光的故障
### 3.3 功能安全概念
功能描述、安全目标以及顶层安全需求的结果是一个功能安全架构，该架构将映射到特定的车辆架构。
#### 3.3.1 FunSafReq01-01：
**FLM 应正确检测近光灯的任何有效开启条件**。（**ASIL B**）
- 关联到 MF01：在"有效近光灯开启"请求后没有近光灯
#### 3.3.2 FunSafReq01-02：
**FLM 应验证接收到的任何近光灯请求的有效性，并相应地激活或停用近光灯**。（**ASIL B**）
- 关联到 MF02：在没有接收到"有效近光灯关闭"请求时关闭灯光
#### 3.3.3 FunSafReq01-03：
**FLM 应检测激活的近光灯的故障并将故障信号通知驾驶员**。（**ASIL B**）
- 关联到 MF03：激活灯光的故障
> **注意**：
> - 有效的近光灯开启请求 => "CL15 为 ON 且灯光开关从 OFF 变为 ON"
> - 有效的近光灯关闭请求 => "灯光开关从 ON 变为 OFF"
### 3.4 车辆级安全需求
作为车辆级安全分析的一部分，根据可用的系统架构定义了警告和降级概念。车辆级技术安全需求从功能安全需求和初步架构的假设（见 2.2）导出，并标记为 SysSafReq ID。
> **注意**：生成技术安全需求的过程不是本文档的一部分，因此不在下面描述。这些车辆级需求用于演示若干需求级别。它们既未完全分析，也未从实际实现映射。
#### 3.4.1 警告和降级概念
对于近光灯，应实现以下 2 步降级概念：
**正常模式（Normal Mode）**：
- 见项目描述中的标称功能（见 2）
**降级模式步骤 1 — 丢失一个近光灯**：
- 第二个近光灯仍执行其功能
- 当请求近光灯但未成功激活（检测到故障）时，应向驾驶员提供警告，指示近光灯的部分丢失
**降级模式步骤 2 — 丢失两个近光灯**：
- 当请求近光灯但未成功激活（检测到故障）时，应激活日间行车灯
- 当请求近光灯时，应向驾驶员提供警告，指示近光灯的丢失和日间行车灯的激活
> **注意**：这种使用日间行车灯作为回退的做法仅用作示例以演示降级功能。此解决方案在认证方面可能不合适。
> **注意**：在此模式下可以激活其他驾驶员辅助功能以协助驾驶员，但这不是本示例的一部分。
#### 3.4.2 技术安全需求（车辆级）
以下技术安全需求基于 3.3 中的确定在本示例分析中导出：
##### 3.4.2.1 SysSafReq01
**CAN 连接的车身控制器应通过 CAN 总线消息 CL15_01（CAN 消息：CL15_01，CAN 信号：CL15ON（Boolean，'1' 表示 clamp 15 设置为 on，'0' 表示 clamp 15 设置为 off））发出点火钥匙 clamp 15 状态信号。**（**ASIL B**）
> **注意**：CAN 消息细节在 CAN DB 中定义（频率、抑制时间、信号类型），作为标称功能的一部分。
##### 3.4.2.2 SysSafReq02
**灯光开关应通过数字 HW 线路 HW_LB_OFF（0=0V 表示请求灯光开启，1=5V 表示请求灯光关闭）发出开关状态信号。**（**ASIL B**）
##### 3.4.2.3 SysSafReq03
**灯光开关内的故障应导致数字 HW 线路 HW_LB_OFF 设置为 0。**（**ASIL B**）
##### 3.4.2.4 SysSafReq04
**FLM ECU 应确保在为灯泡供电的条件满足时（如标称功能定义），保持为灯泡供电的限制（如电压和 PWM）。**（**ASIL B**）
##### 3.4.2.5 SysSafReq05
**当 CL15ON==1 时，FLM ECU 应仅在 HW_LB_OFF==1 条件连续 20ms 满足时才关闭灯光。**（**ASIL B**）
> **注意**：等待信号值稳定条件几毫秒的时序条件包括去抖。20ms 的特定值是凭经验取的。也可以使用其他值。
##### 3.4.2.6 SysSafReq06
**FLM ECU 应检测电路故障（灯泡、保险丝、布线开路/短路）并通过 CAN 信号化（CAN 消息：LightStatus_01，CAN 信号：LBFailure（2 位，01 表示左侧近光灯故障，10 表示右侧近光灯故障，11 表示两个近光灯都故障））。**（**ASIL B**）
##### 3.4.2.7 SysSafReq07
**如果连续 200ms 检测到两个近光灯灯泡故障，FLM ECU 应激活两个日间行车灯（DRL）。**（**ASIL B**）
> **注意**：FTT 预算按以下方式分配：200ms 故障检测时间 + 200ms 卤素灯泡达到全强度的保守时间间隔（故障反应）+ 100ms 缓冲 = 500ms。
##### 3.4.2.8 SysSafReq08
**FLM ECU 应使用独立电路为左和右灯泡供电，使得没有单一故障能导致近光灯的完全丢失。**（**ASIL B**）
##### 3.4.2.9 SysSafReq09
**HMI 应根据通过 CAN 接收的信号 LBFailure（CAN 消息：LightStatus_01，CAN 信号：LBFailure）显示灯泡故障信息。**（**ASIL A**）
> **注意**：对于此措施，FTT 不相关，因为它是针对潜在故障的措施。这里可以计算相关时间（诊断间隔）。针对双灯泡故障的措施（FTT 相关）是激活日间行车灯。作为针对潜在故障的措施，ASIL 根据 ISO 26262-4:2011(E) 6.4.4.4 降低。
##### 3.4.2.10 SysSafReq10
**必须确保发送方和接收方之间通过 CAN 的数据传输。CAN 消息：CL15_01，CAN 信号：CL15ON Boolean。**（**ASIL B**）
> **注意**：对于此措施，应考虑数据交换的所有相关故障模式（见 ISO 26262 第 6 部分）。
##### 3.4.2.11 SysSafReq11
**必须确保发送方和接收方之间通过 CAN 的数据传输。CAN 消息：LightStatus_01，CAN 信号：LBFailure。**（**ASIL A**）
> **注释**：对于此措施，应考虑数据交换的所有相关故障模式（见 ISO 26262-6）。
##### 3.4.2.12 SysSafReq12
**如果连续 200ms 检测到关于消息 CL15_01 的通信故障，FLM ECU 应激活近光灯。**
> **注意**：FTT 预算分配与 SysSafReq07 相同。
##### 3.4.2.13 SysSafReq13
**FLM ECU 应**：
- 如果连续 200ms 检测到关于消息 LightStatus_01 的通信故障，激活两个日间行车灯（DRL），并且
- 向驾驶员提供文本消息，如"灯光系统缺陷"
#### 3.4.3（功能）系统安全需求的分配
下一步，所有系统安全需求需要分配到架构系统元素（见图 5）。
#### 3.4.4 技术系统安全需求（车辆级）总结
系统安全需求到功能安全需求（车辆级）的整体映射以及到系统元素的分配总结于表 3。
> **摘要标记**：本节包含一个大型需求映射表（约 13 项需求 × 5 列），涵盖 SysSafReq01-13 与功能安全需求、系统元素和 ASIL 等级的映射。下表列出前 6 项代表性映射；完整表见原文 PDF 第 17-18 页。
| ID | 系统安全需求（摘要） | 支持功能安全需求 ID | ASIL | 项目 |
|---|---|---|---|---|
| `SysSafReq01` | BCU 通过 CAN CL15_01 信号化 CL15 状态 | `FunSafReq01-01` | ASIL B | BC-ECU |
| `SysSafReq02` | 灯光开关通过 HW_LB_OFF 信号化状态 | `FunSafReq01-01` | ASIL B | LS |
| `SysSafReq03` | 灯光开关故障时 HW_LB_OFF=0 | `FunSafReq01-01` | ASIL B | LS |
| `SysSafReq04` | FLM ECU 保持灯泡供电限制 | `FunSafReq01-02` | ASIL B | FLM-ECU |
| `SysSafReq05` | CL15ON==1 时 20ms 后才关闭灯光 | `FunSafReq01-02` | ASIL B | FLM-ECU |
| `SysSafReq06` | 检测电路故障并通过 CAN 信号化 | `FunSafReq01-03` | ASIL B | FLM-ECU |
---
## 4 FLM-ECU 级技术安全概念
### 4.1 ECU 级的假设和限制
- 与车辆级假设一致
- ECU 使用单核微控制器
- 假设硬件平台提供 MPU 支持
- 假设支持 OS 时序保护
- WdgM 配置为监督所有安全相关 SE
### 4.2 要满足的安全目标
车辆级的安全目标 **SG01: Prevent total loss of low beam** 必须在 FLM ECU 级别被满足。
### 4.3 相关系统安全需求
车辆级系统安全需求中分配到 FLM ECU 的所有需求都必须在 ECU 级别被满足。
### 4.4 ECU 级概念概述
FLM ECU 级别的安全概念包括以下层次：
1. **应用软件层**：
- 前照灯应用 SWC
- 执行器 SWC
- 安全检查 SWC
2. **RTE 层**：
- 跨 SW-C 通信
- E2E 保护
3. **基础软件层**：
- COM（带 E2E）
- OS（带 MPU 保护）
- WdgM（监督安全相关 SE）
- DEM（错误诊断）
4. **硬件层**：
- MPU
- 看门狗硬件
- 时钟监控
### 4.5 ECU 级需求
ECU 级需求基于系统级安全需求派生：
| ID | ECU 级需求 | 关联车辆级需求 |
|---|---|---|
| `EcuSafReq01` | FLM ECU 应正确读取 HW_LB_OFF 输入 | SysSafReq02 |
| `EcuSafReq02` | FLM ECU 应正确配置 HW_LB_OFF 端口和引脚 | SysSafReq02 |
| `EcuSafReq03` | FLM ECU 应正确转换 CL15ON 到 CL15_01 消息 | SysSafReq01 |
| `EcuSafReq04` | FLM ECU 应通过 AUTOSAR BSW/RTE 正确路由 CL15_01 消息 | SysSafReq01 |
| `EcuSafReq05` | FLM ECU 应检测 CL15ON 的通信故障 | SysSafReq10 |
| `EcuSafReq06` | 正确读取灯泡健康测量值 | SysSafReq06 |
| `EcuSafReq07` | 正确供电灯泡 | SysSafReq04 |
| `EcuSafReq08` | 检测灯泡故障 | SysSafReq06 |
| `EcuSafReq09` | 通过 CAN 报告灯泡故障 | SysSafReq06 |
| `EcuSafReq10` | 监督所有安全相关 SW-C | 新增 |
### 4.6 ECU 功能
FLM ECU 的主要功能：
#### 4.6.1 读取灯光开关状态
通过 DIO 接口读取灯光开关状态（HW_LB_OFF）。
#### 4.6.2 读取点火钥匙状态（经由车身控制器）
通过 CAN 接口接收来自车身控制器的 CL15_01 消息。
#### 4.6.3 激活灯光（物理）
通过 PWM 输出控制左和右近光灯。
#### 4.6.4 监控灯光
通过 ADC 通道读取灯泡的电流消耗以检测灯泡故障。
#### 4.6.5 提供驾驶员反馈
通过 CAN 发送 LightStatus_01 消息以通知 HMI 灯泡故障状态。
#### 4.6.6 控制灯光（逻辑）
应用 SWC 根据 CL15ON 和 HW_LB_OFF 计算灯光请求状态。
---
## 5 软件架构与软件安全需求
### 5.1 软件架构
本节展示软件架构的不同视图。
#### 5.1.1 软件组件
主要的软件组件（SWC）：
- **FLM 应用 SWC**：包含前照灯管理的应用逻辑
- **Actuator SWC**：负责控制灯泡的执行器
- **Sensor SWC**：处理传感器输入
- **Safety SWC**：实现安全检查
#### 5.1.2 RTE 运行时环境
RTE 提供 SW-C 之间的通信：
- 显式接口（Sender-Receiver、Client-Server）
- 数据转换（包括 E2E 保护）
- 模式管理
#### 5.1.3 AUTOSAR BSW 视图
BSW 视图显示所有基础软件模块及其相互关系：
- **MCAL**：DIO、ADC、PWM、SPI
- **ECUAL**：PORT、MCU
- **服务层**：OS、COM、RTE、WdgM、DEM、EcuM
- **CDD**：复杂驱动
#### 5.1.4 BSW 功能概述
主要的 BSW 功能：
1. **输入处理**：通过 DIO 读取灯光开关
2. **通信处理**：通过 CAN 接收 CL15 状态和发送灯泡状态
3. **输出处理**：通过 PWM 控制灯泡
4. **安全监控**：WdgM 监督安全相关 SE
5. **故障诊断**：DEM 记录所有故障事件
### 5.2 故障模式
#### 5.2.1 硬件故障模式
- DIO 输入卡在 0 或 1
- ADC 读数偏差
- PWM 输出故障
- CAN 收发器故障
- MPU 故障
#### 5.2.2 软件故障模式
- SW-C 死循环
- SW-C 死锁
- 通信数据损坏
- 检查点未到达
- 错误的灯光控制逻辑
### 5.3 软件方面和潜在故障模式分析
本节详细分析每个 ECU 中的软件方面和潜在故障模式。
#### 5.3.1 ECU02 的分析：CAN CL15 到逻辑 CL15_01 消息的正确转换
**关联需求**：`EcuSafReq03`
**故障分析**：
- COM 模块可能错误地解析 CAN 消息
- 信号提取可能出错
- 信号值可能被错误地映射
**缓解措施**：
- E2E 保护
- COM 信号验证
- 范围检查
#### 5.3.2 ECU03 的分析：CL15_01 消息通过 AUTOSAR BSW/RTE 的正确路由
**关联需求**：`EcuSafReq04`
**故障分析**：
- RTE 路由错误
- 数据缓冲损坏
- 类型不匹配
**缓解措施**：
- RTE 类型检查
- E2E 保护
- 数据一致性检查
#### 5.3.3 ECU27 的分析：CL15_01.CL15ON 在发送方和接收方之间的传输
**关联需求**：SysSafReq10（**ASIL B**）
**故障分析**：
- CAN 帧丢失
- CAN 帧损坏
- CAN 帧乱序
- CAN 帧重复
**缓解措施**：
- E2E Profile 4（CRC + Counter）
- 周期性发送
- 超时检测
#### 5.3.4 ECU04 的分析：检测影响 CL15ON 的潜在通信故障
**关联需求**：`EcuSafReq05`
**故障分析**：
- E2E 验证失败
- 计数器不连续
- 超时
**缓解措施**：
- 200ms 连续故障检测
- 激活近光灯作为故障反应
#### 5.3.5 ECU06 的分析：HW_LB_OFF 输入的正确读取
**关联需求**：`EcuSafReq01`
**故障分析**：
- DIO 读取错误
- 端口配置错误
- 信号去抖不充分
**缓解措施**：
- PORT 模块正确配置
- 多次读取验证
- 时间窗口去抖
#### 5.3.6 ECU07 的分析：HW_LB_OFF 输入端口和引脚的正确配置
**关联需求**：`EcuSafReq02`
**故障分析**：
- 端口方向错误
- 引脚复用错误
- 上下拉电阻配置错误
**缓解措施**：
- 编译时配置验证
- 启动时端口验证
#### 5.3.7 ECU08 的分析：HW_LB_OFF 输入到逻辑 LB_OFF 信号的正确转换
**故障分析**：
- 信号电平转换错误
- 信号反转
**缓解措施**：
- 信号映射验证
#### 5.3.8 ECU09 的分析：LB_OFF 通过 AUTOSAR BSW/RTE 的正确路由
**故障分析**：
- RTE 路由错误
- 数据一致性
**缓解措施**：
- E2E 保护
#### 5.3.9 ECU10 的分析：检测影响 LB_OFF 的潜在故障
**故障分析**：
- 信号卡在固定值
- 信号抖动
**缓解措施**：
- 200ms 连续故障检测
- 激活近光灯
#### 5.3.10 ECU12 的分析：应用 SWC 确定 LB_OFF 和 CL15ON 状态
**故障分析**：
- SWC 内部状态错误
- 状态机错误
**缓解措施**：
- WdgM Alive 监督
- 状态机验证
#### 5.3.11 ECU13 的分析：应用 SWC 评估灯光请求条件
**故障分析**：
- 条件判断错误
- 时序条件错误
**缓解措施**：
- 详细的代码审查
- 单元测试
#### 5.3.12 ECU14 的分析：应用 SWC 设置或重置灯光开启命令
**关联需求**：SysSafReq12, SysSafReq07
**故障分析**：
- 状态转换错误
- 输出命令错误
**缓解措施**：
- 故障安全状态（激活近光灯）
- WdgM 监督
#### 5.3.13 ECU15 的分析：双 LB 灯泡故障时激活日间行车灯
**关联需求**：SysSafReq07
**故障分析**：
- 故障检测延迟
- 误激活
**缓解措施**：
- 200ms 连续检测
- 信号去抖
#### 5.3.14 ECU16 的分析：根据灯光请求和规范的正确供电
**关联需求**：`EcuSafReq07`
**故障分析**：
- PWM 错误
- 电流限制违反
**缓解措施**：
- PWM 硬件保护
- 反馈监控
#### 5.3.15 ECU29 的分析：逻辑 PWM-L 信号到 SPI 总线消息的正确转换
**故障分析**：
- 信号转换错误
- 时序问题
**缓解措施**：
- SPI 通信验证
- CRC 保护
#### 5.3.16 ECU17 的分析：set_pwm 请求到 µC SPI 输出的正确路由
**故障分析**：
- 路由错误
- 缓冲区损坏
**缓解措施**：
- SPI 通信保护
- E2E 保护
#### 5.3.17 ECU20 的分析：灯泡供电时应用 SWC 评估灯泡状态
**关联需求**：`EcuSafReq08`
**故障分析**：
- 状态评估错误
- 故障检测延迟
**缓解措施**：
- 周期性检查
- 多重评估
#### 5.3.18 ECU30 的分析：执行器 SWC 读取并提供灯泡状态
**关联需求**：`EcuSafReq06`
**故障分析**：
- ADC 读数错误
- 数据传输错误
**缓解措施**：
- ADC 校准
- E2E 保护
#### 5.3.19 ECU21 的分析：通过 CAN 总线报告检测到的故障
**关联需求**：`EcuSafReq09`
**故障分析**：
- CAN 通信失败
- 数据损坏
**缓解措施**：
- E2E Profile 4
- DEM 错误记录
#### 5.3.20 ECU23 的分析：执行器 SWC 启动灯泡健康测量路径每个元素的诊断
**故障分析**：
- 诊断未执行
- 诊断结果错误
**缓解措施**：
- 周期性自检
- 多通道验证
#### 5.3.21 ECU24 的分析：灯泡健康测量值 read_current_L、read_current_R 通过 AUTOSAR BSW/RTE 的正确路由
**故障分析**：
- 数据路由错误
- 类型不匹配
**缓解措施**：
- E2E 保护
- 数据类型检查
#### 5.3.22 ECU25 的分析：ADC-HW 将测量的电流转换为 read_current_L、read_current_R
**关联需求**：`EcuSafReq06`
**故障分析**：
- ADC 转换错误
- 校准漂移
**缓解措施**：
- 周期性 ADC 校准
- 范围检查
#### 5.3.23 ECU26 的分析：SW-C 之间的正确数据交换（时序和内容）
**故障分析**：
- 数据交换时序错误
- 数据内容损坏
**缓解措施**：
- E2E 保护
- 超时监控
> **摘要标记**：5.3 节共包含 23 个详细的 ECU 分析（ECU02-ECU30），每个分析都包含故障分析、缓解措施和需求关联。本节翻译了所有分析的核心内容，详细的图表和扩展描述见原文 PDF 第 31-56 页。
---
## 6 结论
### 6.1 未来 AUTOSAR 版本中潜在的安全改进
本节总结通过本示例分析识别的潜在安全改进。
**改进建议**：
1. **AUTOSAR 模板的安全扩展**：
- 在 ARXML 中更好地表达安全需求
- 安全机制的形式化定义
- 安全分析结果与 AUTOSAR 模型的集成
2. **安全分析工具支持**：
- 自动生成安全需求
- 验证 AUTOSAR 模型是否满足安全需求
- 安全影响的仿真
3. **安全模式管理**：
- 安全状态的标准化定义
- 安全状态之间的转换规则
- 安全模式与正常模式的交互
4. **端到端保护的改进**：
- 更多 E2E 配置文件
- 更好地集成到 RTE
- 性能优化
5. **WdgM 的改进**：
- 更好的配置工具
- 与 ISO 26262 的清晰映射
- 改进的诊断
6. **测试规范**：
- 安全机制的测试用例
- 故障注入测试
- 性能测试
---
## 7 缩写/词汇表（Abbreviation/Glossary）
| 缩写 | 描述 |
|---|---|
| ASIL | Automotive Safety Integrity Level（汽车安全完整性等级） |
| BCU | Body Control Unit（车身控制单元） |
| BSW | Basic Software（基础软件） |
| CAN | Controller Area Network（控制器局域网） |
| CDD | Complex Device Driver（复杂设备驱动） |
| CL15 | Clamp 15（点火开关信号） |
| CRC | Cyclic Redundancy Check（循环冗余校验） |
| DEM | Diagnostic Event Manager（诊断事件管理器） |
| DIO | Digital Input/Output（数字输入/输出） |
| E2E | End-to-End（端到端） |
| ECU | Electronic Control Unit（电子控制单元） |
| EcuM | ECU State Manager（ECU 状态管理器） |
| FMEA | Failure Mode and Effects Analysis（失效模式与影响分析） |
| FTTI | Fault Tolerant Time Interval（故障容错时间间隔） |
| FLM | Front Light Management（前照灯管理） |
| HMI | Human-Machine Interface（人机界面） |
| LB | Low Beam（近光灯） |
| LS | Light Switch（灯光开关） |
| MPU | Memory Protection Unit（内存保护单元） |
| OEM | Original Equipment Manufacturer（原始设备制造商） |
| OS | Operating System（操作系统） |
| PWM | Pulse Width Modulation（脉宽调制） |
| RTE | Runtime Environment（运行时环境） |
| SG | Safety Goal（安全目标） |
| SPI | Serial Peripheral Interface（串行外设接口） |
| SWC | Software Component（软件组件） |
| WdgM | Watchdog Manager（看门狗管理器） |
---
## 8 参考文献（References）
[1] ISO 26262:2011(E) — Road vehicles — Functional safety
[2] AUTOSAR_EXP_LayeredSoftwareArchitecture — AUTOSAR 分层软件架构
[3] AUTOSAR_SWS_WatchdogManager — 看门狗管理器规范
[4] AUTOSAR_SWS_E2ELibrary — 端到端保护库
[5] AUTOSAR_SWS_COM — 通信规范
[6] AUTOSAR_SWS_RTE — 运行时环境
[7] AUTOSAR_SWS_OS — 操作系统
[8] AUTOSAR_SWS_DEM — 诊断事件管理器
[9] AUTOSAR_TPS_SafetyExtensions — 安全扩展
---
## 翻译说明
本文档为 AUTOSAR EXP SafetyUseCase（文档 ID 641，61 页，4.4.0 版）的中文翻译。翻译策略：
1. **完整翻译**：封面、文档标识、变更历史、目录、所有主要章节（第 1-7 章）
2. **核心分析方法涵盖**：
- **项目描述**：前照灯管理（FLM）功能、初步架构、假设和限制
- **危险分析与风险评估**：H1 危险、SG01 安全目标、ASIL B 等级、FTTI 500ms
- **功能安全概念**：FunSafReq01-01/02/03
- **系统安全需求**：SysSafReq01-13
- **降级概念**：2 步降级（日间行车灯作为回退）
- **ECU 级安全概念**：EcuSafReq01-10
- **23 个 ECU 软件分析**：涵盖所有 ECU 的故障分析和缓解措施
3. **关键概念涵盖**：
- ASIL 等级（A、B、C、D）
- FTTI（故障容错时间）
- 安全状态、降级模式
- E2E 保护、WdgM 监督
4. **摘要处理**：
- 系统安全需求映射表（表 3）：列出前 6 项代表性映射，完整表见原文 PDF
- 23 个 ECU 分析：保留核心内容，详细图表见原文 PDF
5. **保留内容**：所有需求 ID（`FunSafReq`、`SysSafReq`、`EcuSafReq`、`ECU02-30`）、ASIL 等级引用、ISO 26262 引用
本文档为安全工程师提供了一个完整的安全分析案例研究，展示了如何将 ISO 26262 的方法论应用于 AUTOSAR 系统。
Safety/AUTOSAR_RS_SafetyExtensions.md
+498
View File
@@ -0,0 +1,498 @@
# 安全扩展需求（Requirements on Safety Extensions）
| 字段 | 内容 |
|---|---|
| **文档标题** | 安全扩展需求（Requirements on Safety Extensions） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 670 |
| **文档状态** | Final（正式发布） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
---
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 基于概念"Safety Extensions"的初始发布 |
---
## 目录（Table of Contents）
1. [引言](#1-引言)
- 1.1 [范围](#11-范围)
- 1.2 [文档约定](#12-文档约定)
- 1.3 [指南](#13-指南)
2. [用例追踪](#2-用例追踪)
3. [需求追踪](#3-需求追踪)
4. [需求](#4-需求)
- 4.1 [安全需求](#41-安全需求)
- 4.2 [安全完整性等级](#42-安全完整性等级)
- 4.3 [安全措施与安全机制](#43-安全措施与安全机制)
- 4.4 [可追溯性与分配](#44-可追溯性与分配)
- 4.5 [方法论与使用](#45-方法论与使用)
5. [支持的用例](#5-支持的用例)
---
## 参考文献
- **[1]** ISO 26262 (Part 1-10) – Road vehicles – Functional Safety, First edition
http://www.iso.org
- **[2]** Specifications of Safety Extensions
`AUTOSAR_TPS_SafetyExtensions`
- **[3]** Standardization Template
`AUTOSAR_TPS_StandardizationTemplate`
- **[4]** Requirements on AUTOSAR Features
`AUTOSAR_RS_Features`
- **[5]** Methodology
`AUTOSAR_TR_Methodology`
---
## 1 引言
### 1.1 范围
本文档收集了对 AUTOSAR 模型安全方面的需求，以及将其纳入 AUTOSAR 模板的要求。
安全扩展（Safety Extensions）的主要目标是支持作为 AUTOSAR 模板一部分的 AUTOSAR 系统的安全相关信息交换。这将为安全需求到 AUTOSAR 元素、安全措施和 AUTOSAR 安全机制的可追溯性奠定基础。它还将确保在系统设计、实现和配置期间可获得 AUTOSAR 元素的适当安全完整性等级（Safety Integrity Levels），并且它们可以作为约束检查的对象。
在本文档的上下文中，**功能安全机制**（functional safety mechanisms）是具体的产品部件，例如内存保护。它们被视为功能安全措施（functional safety measures）的专门化，后还包括流程步骤，例如评审。此定义与 ISO 26262-1 [1] 中给出的这些术语的定义一致。
本文档中收集的需求将由 AUTOSAR 安全扩展规范 [2] 来满足。
### 1.2 文档约定
AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中指定的表，参见标准化模板的"Support for Traceability"章节（[3]）。
应使用 [TPS_STDT_00053] 中指定的义务表达的口头形式来表示需求，参见标准化模板的"Support for Traceability"章节（[3]）。
### 1.3 指南
应引用现有的规范（以单一需求的形式）。与这些规范的差异被指定为附加需求。所有需求应具有以下属性：
- **冗余性（Redundancy）**：需求不应在一个需求内或其他需求中重复。
- **清晰性（Clearness）**：所有需求应仅允许一种解释的可能性。使用的未在词汇表中的技术术语必须定义。
- **原子性（Atomicity）**：每个需求应仅包含一个需求。如果需求不能进一步拆分为更多需求，则该需求是原子的。
- **可测试性（Testability）**：需求应通过分析、评审或测试进行测试。
- **可追溯性（Traceability）**：在任何时候都应可见需求的来源和状态。
---
## 2 用例追踪
下表引用第 5 章中指定的用例，并将其链接到相关需求。
> **翻译说明**：原文档的"Use Case Tracing"表较长，包含约 8 个用例，每个用例链接到多个需求（`RS_SAFEX_xxxxx`）。下表列出每个用例的代表性需求映射；完整表请参见原文 PDF 第 9-11 页。
| 用例 | 描述 | 由以下需求满足 |
|---|---|---|
| **[UC_SAFEX_00001]** | 在 AUTOSAR 系统的分布式开发中交换安全信息 | `RS_SAFEX_00001` ~ `RS_SAFEX_00024`（完整集合） |
| **[UC_SAFEX_00002]** | 在 AUTOSAR 中管理安全需求 | `RS_SAFEX_00001` ~ `RS_SAFEX_00010` |
| **[UC_SAFEX_00003]** | ASIL 约束检查 | `RS_SAFEX_00008`、`RS_SAFEX_00010`、`RS_SAFEX_00011`、`RS_SAFEX_00012`、`RS_SAFEX_00013`、`RS_SAFEX_00014`、`RS_SAFEX_00018`、`RS_SAFEX_00022` |
| **[UC_SAFEX_00004]** | AUTOSAR SEooC 开发 | `RS_SAFEX_00001` ~ `RS_SAFEX_00024`（完整集合） |
| **[UC_SAFEX_00005]** | 为 AUTOSAR 系统提供安全文档 | `RS_SAFEX_00001` ~ `RS_SAFEX_00024`（完整集合） |
| **[UC_SAFEX_00006]** | 为 AUTOSAR 系统提供适当的安全机制 | `RS_SAFEX_00008`、`RS_SAFEX_00009`、`RS_SAFEX_00010`、`RS_SAFEX_00011`、`RS_SAFEX_00012`、`RS_SAFEX_00013`、`RS_SAFEX_00014`、`RS_SAFEX_00015`、`RS_SAFEX_00016`、`RS_SAFEX_00017`、`RS_SAFEX_00018`、`RS_SAFEX_00022`、`RS_SAFEX_00023` |
| **[UC_SAFEX_00007]** | 观察应用的 ASIL 分解产生的约束 | `RS_SAFEX_00008`、`RS_SAFEX_00009` |
| **[UC_SAFEX_00008]** | 获取 AUTOSAR 元素的 ASIL 信息 | `RS_SAFEX_00011` |
---
## 3 需求追踪
下表引用 [4] 中指定的需求，并将其链接到这些需求的实现。
| 需求 | 描述 | 由以下需求满足 |
|---|---|---|
| **[RS_BRF_02068]** | AUTOSAR 方法论应允许将安全属性分配给模型元素 | `RS_SAFEX_00001`、`RS_SAFEX_00002`、`RS_SAFEX_00003`、`RS_SAFEX_00004`、`RS_SAFEX_00005`、`RS_SAFEX_00006`、`RS_SAFEX_00007`、`RS_SAFEX_00008`、`RS_SAFEX_00009`、`RS_SAFEX_00010`、`RS_SAFEX_00011`、`RS_SAFEX_00012`、`RS_SAFEX_00013`、`RS_SAFEX_00014`、`RS_SAFEX_00015`、`RS_SAFEX_00016`、`RS_SAFEX_00017`、`RS_SAFEX_00018`、`RS_SAFEX_00020`、`RS_SAFEX_00021`、`RS_SAFEX_00022`、`RS_SAFEX_00023`、`RS_SAFEX_00024` |
---
## 4 需求
本章描述了驱动安全扩展规范 [2] 定义工作的所有需求。
### 4.1 安全需求
#### [RS_SAFEX_00001] AUTOSAR 模型中可表达的安全需求
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 安全需求应通过 AUTOSAR 元模型在 AUTOSAR 模型和文档中表达。 |
| **基本原理** | AUTOSAR 中所有需求（包括安全需求）及其规范项的一致规范和表示。 |
| **用例** | [UC_SAFEX_00002]、[UC_SAFEX_00001] |
| **依赖性** | – |
| **支持材料** | 参见 ISO 26262-8 [1]。 |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00002] 安全需求至少与其他需求一样具有表达力
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 安全需求至少应能够携带与 AUTOSAR 中其他需求相同种类的信息。此外，遵循 ISO 26262-8 中对需求管理的要求，参见 [1]。 |
| **基本原理** | 像 ISO 26262 [1] 这样的安全标准定义了对安全需求定义的最低要求。此外，在 AUTOSAR 中使用类似结构对安全和非安全需求进行协调定义是可取的。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002] |
| **依赖性** | [RS_SAFEX_00001] |
| **支持材料** | – |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00003] 通过 URI 描述的安全需求
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 应可以通过 URI 将 AUTOSAR 模型内的安全需求定义与该 AUTOSAR 模型外部的需求规范相关联。 |
| **基本原理** | 实践中使用了多种需求交换的技术方法。这包括需求交换格式（ReqIF）或基于专有工具的交换。通过通过 URI 引用外部需求定义的可能性，可以在 AUTOSAR 模型中建立可追溯性，同时避免数据复制及其典型的负面影响。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002] |
| **依赖性** | [RS_SAFEX_00001] |
| **支持材料** | – |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00004] 可区分的安全需求
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 安全需求应可与 AUTOSAR 模型中的其他需求区分开来。 |
| **基本原理** | 安全标准的规则仅适用于安全需求。例如，这适用于可追溯性或 ASIL 相关措施或约束。因此，有必要明确标识安全需求。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002] |
| **依赖性** | [RS_SAFEX_00001] |
| **支持材料** | 参见 ISO 26262-8 [1]。 |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00005] 安全需求的唯一标识
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 安全需求应具有唯一标识。 |
| **基本原理** | 这是满足安全标准要求的必要条件。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002] |
| **依赖性** | [RS_SAFEX_00001] |
| **支持材料** | 参见 ISO 26262-8 [1]。 |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00006] 安全需求的状态信息
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 应可以指定安全需求的状态。 |
| **基本原理** | 这是满足安全标准要求的必要条件。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00004] |
| **依赖性** | [RS_SAFEX_00001] |
| **支持材料** | 参见 ISO 26262-8 [1]。 |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00007] 安全需求的层次结构
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 应可以指定安全需求的层次结构。 |
| **基本原理** | 这是满足安全标准要求的必要条件。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002] |
| **依赖性** | [RS_SAFEX_00001] |
| **支持材料** | 参见 ISO 26262-8 [1]。 |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00008] 安全需求的分解
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 应可以将安全需求分解为两个独立的安全需求。 |
| **基本原理** | ASIL 分解是 ISO 26262 中提供的概念，通过将安全需求拆分为独立的安全需求来降低安全需求的 ASIL。ASIL 分解也应可用于 AUTOSAR 系统。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00007] |
| **依赖性** | [RS_SAFEX_00010]、[RS_SAFEX_00001] |
| **支持材料** | 参见 ISO 26262-9 [1] |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00009] 独立性需求的规范
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 应可以指定作为特殊安全需求的独立性需求，并将其与安全需求的分解相关联。 |
| **基本原理** | 仅当可以确保具有较低 ASIL 的所得安全需求的独立性时，才允许 ASIL 分解。这导致对独立性的要求，这些要求显然与分解相关。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00007] |
| **依赖性** | [RS_SAFEX_00001]、[RS_SAFEX_00008] |
| **支持材料** | 参见 ISO 26262-9 [1] |
c(`RS_BRF_02068`)
### 4.2 安全完整性等级
#### [RS_SAFEX_00010] 安全需求的 ASIL 属性
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 应可以为安全需求指定 ASIL 属性。属性的值应至少以明确的方式携带 ISO 26262 中列出的可能 ASIL 值。 |
| **基本原理** | 确保系统功能安全所需的必要措施取决于适用的 ASIL。ASIL 到系统元素的分配通过安全需求完成。未能遵守 ASIL 可能导致不安全的系统。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00008] |
| **依赖性** | [RS_SAFEX_00001] |
| **支持材料** | 参见 ISO 26262-3 [1] |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00011] AUTOSAR 元素的 ASIL 属性
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 应可以为作为 AUTOSAR 模型一部分的任何 AUTOSAR 元素指定 ASIL 属性。属性的值应至少以明确的方式携带 ISO 26262 中列出的可能 ASIL 值。 |
| **基本原理** | 这允许在安全需求和 AUTOSAR 元素之间交叉检查 ASIL 值。例如，这对于使用上下文外安全元素方法（SEooC）非常重要，参见 ISO 26262-10 [1]。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00008] |
| **依赖性** | – |
| **支持材料** | 参见 ISO 26262-4 和 ISO 26262-6 [1] |
c(`RS_BRF_02068`)
### 4.3 安全措施与安全机制
#### [RS_SAFEX_00015] AUTOSAR 模型中可表达的安全措施
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 安全措施应在 AUTOSAR 模型中可表达。 |
| **基本原理** | AUTOSAR 提供了许多安全机制。它们应与 AUTOSAR 模型中的安全需求相关联，以证明安全需求的正确实现。此外，能够处理 AUTOSAR 外部但对 AUTOSAR 系统很重要的安全措施也很重要。通过对安全措施进行建模，它可以用作 AUTOSAR 模型中可追溯性的代理和终点。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00006] |
| **依赖性** | – |
| **支持材料** | – |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00016] 安全措施的文本描述
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 安全措施应至少具有文本描述。 |
| **基本原理** | 文本描述提供了一种非正式的方式来描述安全措施。未来可能会定义其他形式属性。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00005]、[UC_SAFEX_00006] |
| **依赖性** | [RS_SAFEX_00015] |
| **支持材料** | – |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00017] 安全措施的唯一标识
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 安全措施应具有唯一标识。 |
| **基本原理** | 安全措施是可追溯到安全需求的对象。没有唯一标识符，不可能建立这种可追溯性。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00005]、[UC_SAFEX_00006] |
| **依赖性** | [RS_SAFEX_00015] |
| **支持材料** | – |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00023] 作为特殊安全措施的安全机制
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 安全机制应在 AUTOSAR 模型中作为安全措施的专门化来表达。 |
| **基本原理** | ISO 26262 区分了安全措施和安全机制，其中安全措施包括安全机制。该术语应反映在安全扩展中。（参见 ISO 26262-1，第 1.110 条 [1]） |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00005]、[UC_SAFEX_00006] |
| **依赖性** | [RS_SAFEX_00015] |
| **支持材料** | – |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00018] 安全需求和安全措施之间的关系
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 应可以将安全需求与安全措施相关联。这样的关系应可与 AUTOSAR 模型中的任何其他关系明确区分开来。 |
| **基本原理** | 为了证明系统安全，显式建模安全需求和安全措施之间的关系是有利的。这简化了文档编制并支持一致性检查（例如观察适用的 ASIL 相关规则）。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00006]、[UC_SAFEX_00005]、[UC_SAFEX_00004] |
| **依赖性** | [RS_SAFEX_00015]、[RS_SAFEX_00001] |
| **支持材料** | – |
c(`RS_BRF_02068`)
### 4.4 可追溯性与分配
#### [RS_SAFEX_00012] 安全需求的可追溯性
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 安全需求应根据 ISO 26262 [1] 可追溯。 |
| **基本原理** | 安全需求的可追溯性是像 ISO 26262 [1] 这样的安全标准的主要要求。直接在 AUTOSAR 模型中建立可追溯性可提高一致性并减少工作量。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00005] |
| **依赖性** | [RS_SAFEX_00001] |
| **支持材料** | 参见 ISO 26262-8 [1] |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00013] 安全措施的可追溯性
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 安全措施应根据 ISO 26262 [1] 可追溯。 |
| **基本原理** | 可追溯性是安全标准的主要要求（参见 ISO 26262-8 第 6.4.3.2 条 [1]）。安全措施是支持安全需求实现的活动或技术解决方案，包括 AUTOSAR 提供的安全机制。直接在 AUTOSAR 模型中建立可追溯性可提高一致性并减少提供安全文档的工作量。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00004]、[UC_SAFEX_00005] |
| **依赖性** | [RS_SAFEX_00015] |
| **支持材料** | – |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00014] 安全需求的分配
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 应可以将技术安全需求分配给 AUTOSAR 模型的元素。这样的分配应可与 AUTOSAR 模型中的其他关系区分开来。 |
| **基本原理** | 所有安全需求必须分配给硬件、软件或两者。那些要由 AUTOSAR 系统实现的安全需求应分配给相应的 AUTOSAR 元素。这是例如检查有关 ASIL 的约束或执行适当的安全分析的基础。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00005] |
| **依赖性** | [RS_SAFEX_00001] |
| **支持材料** | 参见 ISO 26262-4 和 ISO 26262-6 [1] |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00022] 安全措施的分配
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 应可以将安全措施分配给 AUTOSAR 模型的元素。这样的分配应可与 AUTOSAR 模型中的其他关系区分开来。 |
| **基本原理** | 安全措施信息元素描述了可由 AUTOSAR 系统实现的安全措施（例如 AUTOSAR 安全机制，如 E2E 通信保护）。在这种情况下，有必要将实现安全措施的 AUTOSAR 元素与安全措施信息元素相关联。这种关系的存在将简化所需的验证过程（与安全措施相关的安全需求），并支持约束检查（例如 ASIL 义务）。 |
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00005] |
| **依赖性** | [RS_SAFEX_00015] |
| **支持材料** | 参见 ISO 26262-4 和 ISO 26262-6 [1] |
c(`RS_BRF_02068`)
### 4.5 方法论与使用
#### [RS_SAFEX_00024] AUTOSAR 方法论解释安全扩展的使用
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 安全扩展的使用应由 AUTOSAR 方法论解释。 |
| **基本原理** | 安全扩展可以促进通常在 AUTOSAR 系统开发期间执行的许多活动。AUTOSAR 方法论描述了这些活动。如果现有活动需要执行安全信息，或需要新的活动或任务来消费或生成安全信息，则应由方法论解释。 |
| **用例** | – |
| **依赖性** | [5] |
| **支持材料** | – |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00020] 安全扩展不破坏 AUTOSAR 模型处理
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 使用安全扩展不应破坏现有 AUTOSAR 模型的处理。 |
| **基本原理** | 安全扩展作为可与现有模型一起使用的扩展提供。这确保了向后兼容性。对于某些生成目的，可能不需要将安全扩展包含到生成过程中以节省资源。 |
| **用例** | – |
| **依赖性** | – |
| **支持材料** | – |
c(`RS_BRF_02068`)
#### [RS_SAFEX_00021] 用于现有 AUTOSAR 模型的安全扩展
| 字段 | 内容 |
|---|---|
| **类型** | valid |
| **描述** | 应可以为现有 AUTOSAR 模型指定安全扩展。 |
| **基本原理** | 由于许多 AUTOSAR 系统与安全相关，这将允许通过安全扩展扩展现有 AUTOSAR 模型。 |
| **用例** | – |
| **依赖性** | – |
| **支持材料** | – |
c(`RS_BRF_02068`)
---
## 5 支持的用例
### [UC_SAFEX_00001] 在 AUTOSAR 系统的分布式开发中交换安全信息
分布式开发是 AUTOSAR 系统的典型特征。对于最终系统（项目），必须证明其满足功能安全的需求。
与 AUTOSAR 系统相关的安全需求作为 AUTOSAR 模型的一部分在参与分布式开发的组织之间交换。安全需求还包含 ASIL 属性以及它们到 AUTOSAR 元素的明确分配。确保安全相关信息不会丢失。适当时建立可追溯性。最后，AUTOSAR 模型中包含许多用于系统安全文档的信息，并且可以加以利用。
c()
### [UC_SAFEX_00002] 在 AUTOSAR 中管理安全需求
在 AUTOSAR 中，所有需求都以唯一 ID 在需求文档（RS/Feature/SRS）中正式捕获。规范文档（SWS）包含正式追溯到需求的形式规范项。同一级别的需求之间的依赖关系通过提供对相关需求的引用在需求块本身中表达。安全需求（可能包括安全目标）被捕获在单独的安全需求文档中或与同一文档中的其他需求一起捕获。在两种情况下，在这些安全需求与安全相关的规范元素之间建立可追溯性。
c()
### [UC_SAFEX_00003] ASIL 约束检查
AUTOSAR 元素的 ASIL（即用于它们的开发）必须与为这些元素分配的安全需求的 ASIL 匹配。匹配意味着元素的 ASIL 等于或高于所分配的安全需求的 ASIL。在 AUTOSAR 模型中拥有所有信息（安全需求、ASIL、分配），可以执行约束检查以查找无效的分配。这在分布式开发或要集成现有组件的上下文中特别有用。
c()
### [UC_SAFEX_00004] AUTOSAR SEooC 开发
根据 ISO 26262-10（[1]），上下文外安全元素（Safety Element out of Context, SEooC）的开发特征在于对 SEooC 环境的假设是在不知道 SEooC 所集成到的实际上下文（项目）的情况下做出的。这样的 SEooC 的开发人员将以安全需求的形式提供假设，并附带适当的 ASIL 和 AUTOSAR 模型中的状态信息。此外，将描述并提供安全措施 / 安全机制。集成商将利用这些信息执行 SEooC 所嵌入的环境满足假设的分析。同样，可追溯性、分配和映射关系在 AUTOSAR 模型中使用。
c()
### [UC_SAFEX_00005] 为 AUTOSAR 系统提供安全文档
OEM 可以使用 AUTOSAR 系统的 AUTOSAR 模型，并提取模型中关于安全需求、安全措施、它们到 AUTOSAR 元素的分配以及安全需求和安全措施之间的映射的信息，以创建 ISO 26262-8（[1]）所要求的安全文档。
c()
### [UC_SAFEX_00006] 为 AUTOSAR 系统提供适当的安全机制
OEM 可以在系统级别指定对安全机制的要求。在 ECU 级别工作的供应商可以提供此类适当的安全机制并建立所需的可追溯性。同样可能的是，AUTOSAR 堆栈（BSW 组件）的供应商提供并描述供应商特定的安全机制。由于安全机制的信息作为 AUTOSAR 模型的一部分交换，因此可用于验证过程。
c()
### [UC_SAFEX_00007] 观察应用的 ASIL 分解产生的约束
OEM 在其技术安全概念中应用 ASIL 分解。这对预期系统的软件组件的独立性有影响。有关应用的分解以及独立性要求的信息都由供应商作为 AUTOSAR 模型的一部分提交。供应商能够满足独立性要求，因为它们是明确已知的，并且由于可追溯性，验证要容易得多。
c()
### [UC_SAFEX_00008] 获取 AUTOSAR 元素的 ASIL 信息
被要求实现软件组件的供应商需要知道该组件的 ASIL，以便应用适当的开发过程。此外，需要实现的安全需求应该是已知的。这两个信息都使用安全扩展作为 AUTOSAR 模型的一部分进行交换。
c()
---
## 翻译说明
- **翻译完整性**：本文档为 AUTOSAR 安全扩展需求（RS）的中文翻译版本，完整翻译了 1-5 章全部内容。
- **保留的英文术语**：所有需求 ID（`RS_SAFEX_xxxxx`、`UC_SAFEX_xxxxx`、`RS_BRF_02068`、`TPS_STDT_xxxxx`）、模块缩写（OEM、ECU、BSW、E2E、SEooC）、安全标准引用（ISO 26262-1/3/4/6/8/9/10、ASIL）、AUTOSAR 方框符 `⌈⌋` 均按要求保留为英文。
- **省略的内容**：免责声明（Disclaimer）按要求未翻译。
- **关键概念**：
- **安全扩展**（Safety Extensions）：AUTOSAR 模板的一部分，用于支持安全相关信息的交换和追溯。
- **ASIL**（Automotive Safety Integrity Level，汽车安全完整性等级）：从 A 到 D 的等级，源自 ISO 26262。
- **SEooC**（Safety Element out of Context，上下文外安全元素）：一种开发模式，安全元素在没有具体应用上下文的情况下开发。
- **安全机制**（Safety Mechanisms）是**安全措施**（Safety Measures）的专门化。
- **ASIL 分解**（ASIL Decomposition）：将高 ASIL 需求拆分为具有较低 ASIL 的独立需求。
Safety/AUTOSAR_SRS_WatchdogDriver.md
+381
View File
@@ -0,0 +1,381 @@
# 看门狗驱动需求（Requirements on Watchdog Driver）
| 字段 | 内容 |
|---|---|
| **文档标题** | 看门狗驱动需求（Requirements on Watchdog Driver） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 197 |
| **文档状态** | Final（正式发布） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
---
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 新增第 5 章：需求追踪 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 编辑性变更 |
| 2013-10-31 | 4.1.2 | AUTOSAR Administration | ID 重命名；使用标准化模板；将 SRS 需求链接到新特性文档 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 新增窗口看门狗概念需求 |
| 2010-09-30 | 3.1.5 | 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 | 作为独立文档发布。SRS SPAL V1.0.0 已被拆分为 15 个独立文档，以发布 2.0 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 作为 SRS SPAL V1.0.0 的一部分初始发布 |
---
## 目录（Table of Contents）
1. [文档范围](#1-文档范围)
2. [如何阅读本文档](#2-如何阅读本文档)
- 2.1 [使用的约定](#21-使用的约定)
- 2.2 [需求结构](#22-需求结构)
3. [缩略语与缩写](#3-缩略语与缩写)
4. [功能概述](#4-功能概述)
- 4.1 [内部看门狗驱动](#41-内部看门狗驱动)
- 4.2 [外部看门狗驱动](#42-外部看门狗驱动)
5. [需求追踪](#5-需求追踪)
6. [需求规范](#6-需求规范)
- 6.1 [功能需求](#61-功能需求)
- 6.2 [非功能需求](#62-非功能需求)
7. [参考文献](#7-参考文献)
- 7.1 [AUTOSAR 交付物](#71-autosar-交付物)
- 7.2 [相关标准与规范](#72-相关标准与规范)
---
## 1 文档范围
本文档规定了看门狗驱动（Watchdog Driver）模块的需求。
### 约束
基础软件模块需求规范的首要范围是非安全相关系统。因此，安全需求被分配到中等优先级。
---
## 2 如何阅读本文档
每个需求都有其唯一的标识符，以 "BSW"（"Basic Software" 的缩写）前缀开头。对于任何审阅注释、评论或问题，请参考此唯一 ID 而不是章节或页码！
### 2.1 使用的约定
- AUTOSAR 文档中需求的表示遵循 [5] 中指定的表。
- 在需求中，使用以下特定语义（取自互联网工程任务组 IETF 的征求意见稿 RFC 2119）。
本文件中使用的关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照 RFC 2119 中的描述进行解释。请注意，它们所使用文档的需求级别会修改这些词的强制力。
- **MUST**：这个词，或术语 "REQUIRED" 或 "SHALL"，意味着该定义是规范的绝对要求。
- **MUST NOT**：这个词组，或词组 "SHALL NOT"，意味着该定义是规范的绝对禁止。
- **SHOULD**：这个词，或形容词 "RECOMMENDED"，意味着在特定情况下可能存在忽略特定条目的有效理由，但在选择不同方案之前必须充分理解并仔细权衡其全部含义。
- **SHOULD NOT**：这个词组，或词组 "NOT RECOMMENDED"，意味着在特定情况下特定行为可能是可接受的甚至是有用的，但在实现任何带有此标签描述的行为之前，应理解其全部含义并仔细权衡该情况。
- **MAY**：这个词，或形容词 "OPTIONAL"，意味着某个项目是真正可选的。一个供应商可能选择包含该项目，因为特定市场需要它或因为供应商认为它增强了产品，而另一个供应商可能省略同一项目。不包含特定选项的实现必须准备好与包含该选项的另一个实现互操作，尽管可能具有降低的功能。同样，包含特定选项的实现必须准备好与不包含该选项的另一个实现互操作（当然，除了该选项提供的功能之外）。
### 2.2 需求结构
每个模块特定章节包含基础软件模块的简短功能描述。每章中相同类型的需求按以下标题分组（如果适用）：
**功能需求**：
- 配置（模块的哪些元素需要可配置）
- 初始化
- 正常运行
- 关闭操作
- 故障操作
- ...
**非功能需求**：
- 时序需求
- 资源使用
- 可用性
- 其他工作包的输出（例如描述模板、工具...）
- ...
---
## 3 缩略语与缩写
具有局部作用域的缩略语和缩写不包含在 AUTOSAR 词汇表中。这些必须出现在本地词汇表中。
| 缩写 / 首字母缩略词 | 描述 |
|---|---|
| CS | Chip select（片选） |
| DIO | Digital Input Output（数字输入输出） |
| ECU | Electric Control Unit（电子控制单元） |
| EOL | End Of Line（生产线末端），通常用于术语 "EOL Programming" 或 "EOL Configuration" |
| HIS | Herstellerinitiative Software（德国汽车制造商软件标准化倡议） |
| ICU | Interrupt Capture Unit（中断捕获单元） |
| MAL | 旧名称为 Microcontroller Abstraction Layer（由 MCAL 取代，因为 'MAL' 在法语中意为 "bad"） |
| MCAL | Microcontroller Abstraction Layer（微控制器抽象层） |
| MCU | Microcontroller Unit（微控制器单元） |
| MMU | Memory Management Unit（内存管理单元） |
| Master | 控制其他设备（从设备，见下文）的设备 |
| Slave | 完全由主设备控制的设备 |
| NMI | Non maskable interrupt（不可屏蔽中断） |
| OS | Operating System（操作系统） |
| PLL | Phase Locked Loop（锁相环） |
| PWM | Pulse Width Modulation（脉冲宽度调制） |
| RX | Reception（接收，总线通信的上下文） |
| SPAL | 该工作组的名称 |
| SFR | Special Function Register（特殊功能寄存器） |
| RTE | Runtime environment（运行时环境） |
| WP | Work Package（工作包） |
| STD | Standard（标准） |
| REQ | Requirement（需求） |
| UNINIT | Uninitialized（未初始化） |
由于这是专业人员的文档，因此所有其他术语都假定已知。
---
## 4 功能概述
### 4.1 内部看门狗驱动
内部看门狗驱动控制 MCU 的内部看门狗定时器。它提供触发功能和模式选择服务。
### 4.2 外部看门狗驱动
外部看门狗驱动控制外部硬件看门狗。它提供触发功能和模式选择服务。它与内部看门狗驱动具有相同的功能范围。
---
## 5 需求追踪
| 需求 | 描述 | 由以下需求满足 |
|---|---|---|
| `RS_BRF_01008` | AUTOSAR 应将硬件相关层组织为微控制器独立层和微控制器相关层 | `SRS_Wdg_12168` |
| `RS_BRF_01136` | AUTOSAR 应支持在系统启动后解析已配置 BSW 数据的变体 | `SRS_Wdg_12105` |
| `RS_BRF_01448` | AUTOSAR 服务应支持模式与状态管理 | `SRS_Wdg_12018` |
| `RS_BRF_01464` | AUTOSAR 服务应支持看门狗的标准化处理 | `SRS_Wdg_12015`、`SRS_Wdg_12019`、`SRS_Wdg_12106`、`SRS_Wdg_13500` |
| `RS_BRF_01912` | AUTOSAR 微控制器抽象应提供对 SPI 的访问 | `SRS_Wdg_12166` |
| `RS_BRF_01936` | AUTOSAR 微控制器抽象应提供对 MCU 内部和外部硬件看门狗的访问 | `SRS_Wdg_12165`、`SRS_Wdg_12167` |
---
## 6 需求规范
### 6.1 功能需求
#### 6.1.1 内部看门狗驱动
##### 6.1.1.1 配置
###### 6.1.1.1.1 [SRS_Wdg_12015] 看门狗驱动应允许静态配置看门狗模式
> **类型**：Valid（有效）
>
> **描述**：看门狗驱动应允许静态配置看门狗模式。看门狗模式至少应包括所需的看门狗周期。可以添加任何 MCU 特定参数。
> 进一步说明：每个看门狗模式具有相同的参数集，值会有所不同。
>
> **基本原理**：用于模式切换。
>
> **用例**：其他模式参数可以是：
> - window / timeout 模式的选择
> - 超时反应（reset 或 NMI）
>
> **依赖性**：[SRS_Wdg_12018] 看门狗模式选择服务
>
> **支持材料**：BMW 规范 MCAL V1.0a，REQ MAL31.1.2
> （`RS_BRF_01464`）
##### 6.1.1.2 初始化
###### 6.1.1.2.1 [SRS_Wdg_12105] 看门狗驱动应提供允许选择静态配置的看门狗模式之一的初始化服务
> **类型**：Valid（有效）
>
> **描述**：看门狗驱动应提供允许选择静态配置的看门狗模式之一的初始化服务。
>
> **基本原理**：基本功能
>
> **用例**：--
>
> **依赖性**：--
>
> **支持材料**：--
> （`RS_BRF_01136`）
###### 6.1.1.2.2 [SRS_Wdg_12106] 应不可能禁用看门狗
> **类型**：Valid（有效）
>
> **描述**：看门狗初始化服务和看门狗模式选择服务不得允许禁用看门狗。
> 此需求仅适用于安全相关系统。因此，此功能应是静态可配置的（通过预处理器开关）。
>
> **基本原理**：避免在安全相关 ECU 中存在禁用看门狗的代码序列。
>
> **用例**：用于安全相关系统。
>
> **依赖性**：--
>
> **支持材料**：--
> （`RS_BRF_01464`）
##### 6.1.1.3 正常运行
###### 6.1.1.3.1 [SRS_Wdg_12018] 看门狗驱动应提供选择看门狗模式的服务
> **类型**：Valid（有效）
>
> **描述**：看门狗驱动应提供选择看门狗模式的服务：
> - Fast 模式（强制）
> - Slow 模式（可选）
> - Off（可选）
>
> **基本原理**：允许根据 ECU 状态调整看门狗行为。
>
> **用例**：允许为启动和运行模式切换不同的超时周期：
> - ECU 启动模式：Slow 模式（长超时周期）
> - ECU 运行模式：Fast 模式（短超时周期）
>
> **依赖性**：[SRS_Wdg_12015] 看门狗模式的配置
>
> **支持材料**：不要求每个微控制器提供所有模式。一些看门狗在设置后不允许模式更改。
> （`RS_BRF_01448`）
###### 6.1.1.3.2 [SRS_Wdg_12019] 看门狗驱动应提供看门狗触发例程
> **类型**：Valid（有效）
>
> **描述**：看门狗驱动应提供看门狗触发例程。此例程应允许与看门狗设备进行数据交换（双向）。
>
> **基本原理**：基本功能
>
> **用例**：只要看门狗触发条件有效，此例程应重新触发看门狗以防止其过期。数据交换可用于提供密码机制的复杂看门狗（例如用于安全相关系统）。
>
> **依赖性**：--
>
> **支持材料**：窗口看门狗概念（Windowed Watchdog Concept）
> （`RS_BRF_01464`）
###### 6.1.1.3.3 [SRS_Wdg_13500] 看门狗驱动应提供用于设置看门狗触发条件的服务
> **类型**：Valid（有效）
>
> **描述**：看门狗驱动应提供用于设置看门狗触发条件的服务。
>
> **基本原理**：基本功能
>
> **用例**：看门狗接口模块应使用此服务（重新）设置看门狗驱动的触发条件。
>
> **依赖性**：--
>
> **支持材料**：窗口看门狗概念（Windowed Watchdog Concept）
> （`RS_BRF_01464`）
##### 6.1.1.4 关闭操作
由于安全原因以及大多数看门狗不允许停用，因此看门狗驱动不提供 Deinit 函数。因此，[SRS_SPAL_12163] 驱动模块反初始化对此模块无效。
#### 6.1.2 外部看门狗驱动
##### 6.1.2.1 通用
###### 6.1.2.1.1 [SRS_Wdg_12165] 对于外部看门狗驱动，应适用与内部看门狗驱动相同的需求
> **类型**：Valid（有效）
>
> **描述**：对于外部看门狗驱动，应适用与内部看门狗驱动相同的需求。
>
> **基本原理**：内部和外部看门狗之间没有功能差异。保持功能范围相同。
>
> **用例**：--
>
> **依赖性**：内部看门狗驱动的需求
>
> **支持材料**：--
> （`RS_BRF_01936`）
##### 6.1.2.2 配置
###### 6.1.2.2.1 [SRS_Wdg_12166] 外部 SPI 看门狗的驱动应允许静态配置所需的 SPI 参数
> **类型**：Valid（有效）
>
> **描述**：外部 SPI 看门狗的驱动应允许静态配置所需的 SPI 参数。
> 这些参数由 SPI Handler 规范指定。
>
> **基本原理**：SPI 访问的基本配置
>
> **用例**：在同一 SPI 总线上与其他 SPI 设备驱动一起使用 SPI 看门狗驱动。
>
> **依赖性**：--
>
> **支持材料**：AUTOSAR SWS SPI Handler
> （`RS_BRF_01912`）
### 6.2 非功能需求
#### 6.2.1 外部看门狗驱动
##### 6.2.1.1 [SRS_Wdg_12167] 外部看门狗驱动应具有与内部看门狗驱动语义相同的 API
> **类型**：Valid（有效）
>
> **描述**：外部看门狗驱动应具有与内部看门狗驱动语义相同的 API。
>
> **基本原理**：便于通过看门狗管理器控制看门狗。保持内部和外部看门狗的处理相似。
>
> **用例**：将相同的看门狗管理器用于内部或外部看门狗驱动。
>
> **依赖性**：--
>
> **支持材料**：--
> （`RS_BRF_01936`）
##### 6.2.1.2 [SRS_Wdg_12168] 外部看门狗驱动的源代码应独立于底层微控制器
> **类型**：Valid（有效）
>
> **描述**：外部看门狗驱动的源代码应独立于底层微控制器。
>
> **基本原理**：跨多个微控制器复用外部看门狗驱动
>
> **用例**：示例：使用标准化的 SPI Handler 接口，无需任何修改即可在 NEC V850 和 Renesas M16C 上使用相同的外部 SPI 看门狗设备驱动。
>
> **依赖性**：--
>
> **支持材料**：--
> （`RS_BRF_01008`）
---
## 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 相关标准与规范
不适用（NA）。
---
## 翻译说明
- **翻译完整性**：本文档为 AUTOSAR 看门狗驱动需求规范（SRS）的中文翻译版本，完整翻译了 1-7 章全部内容。
- **保留的英文术语**：所有需求 ID（`SRS_Wdg_xxxxx`、`RS_BRF_xxxxx`、`SRS_SPAL_xxxxx`）、模块缩写（MCAL、ECU、SPI、NMI、RTE、SPAL）、RFC 2119 关键字（MUST、SHALL 等）、AUTOSAR 方框符 `⌈⌋` 均按要求保留为英文。
- **省略的内容**：免责声明（Disclaimer）按要求未翻译。
- **关键概念**：
- 内部看门狗驱动（MCAL 层）和外部看门狗驱动（板载设备抽象层）共享相同的功能范围和 API。
- 三种看门狗模式：**Fast**（强制）、**Slow**（可选）、**Off**（可选）。
- **Off 模式禁用**可静态配置，用于安全相关系统（避免 ECU 中存在禁用看门狗的代码序列）。
- **窗口看门狗概念**（Windowed Watchdog Concept）用于支持更严格的时序约束。
Safety/AUTOSAR_SWS_WatchdogDriver.md
+1055
View File
File diff suppressed because it is too large Load Diff
Safety/AUTOSAR_SWS_WatchdogInterface.md
+538
View File
@@ -0,0 +1,538 @@
# 看门狗接口规范（Specification of Watchdog Interface）
| 字段 | 内容 |
|---|---|
| **文档标题** | 看门狗接口规范（Specification of Watchdog Interface） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 041 |
| **文档状态** | Final（正式发布） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
---
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 头文件清理；编辑性变更 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 重命名 —— 默认错误（default errors）更改为开发错误（development errors） |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation |
| 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 | 修复工件路径；根据新的 `SWS_BSWGeneral` 进行修订；需求采用新的索引方案 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 修改 `DeviceIndex`；采用新模板并添加需求可追溯性 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 更新模块版本检查；新增无效指针作为错误代码；检查空指针 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 修改窗口看门狗概念；为 R4.0 进行进一步维护；法律声明修订 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律声明修订 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 总结变更的主要要点；第 8 章的表已被替换；内容从 AUTOSAR BSW 模型生成；扩展文档元信息；小幅布局调整 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | 第 5.1.2 节文件包含结构修改以符合 SPAL 通用包含结构；法律声明修订；新增发布说明；修改"用户建议"；新增"修订信息" |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 文档结构适配通用 Release 2.0 SWS 模板 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 初始发布 |
---
## 目录（Table of Contents）
1. [引言与功能概述](#1-引言与功能概述)
2. [缩略语与缩写](#2-缩略语与缩写)
3. [相关文档](#3-相关文档)
4. [约束与假设](#4-约束与假设)
5. [与其他模块的依赖关系](#5-与其他模块的依赖关系)
6. [需求可追溯性](#6-需求可追溯性)
7. [功能规范](#7-功能规范)
8. [API 规范](#8-api-规范)
9. [序列图](#9-序列图)
10. [配置规范](#10-配置规范)
11. [不适用的需求](#11-不适用的需求)
---
## 1 引言与功能概述
本规范描述了 AUTOSAR 基础软件模块看门狗接口（Watchdog Interface）的功能、API 和配置。
当 ECU 上使用多个看门狗设备和看门狗驱动（例如内部软件看门狗和外部硬件看门狗）时，本模块允许看门狗管理器（或看门狗的任何其他客户端）选择正确的看门狗驱动 —— 从而选择正确的看门狗设备 —— 同时保留底层驱动的 API 和功能。
看门狗接口是板载设备抽象层（参见 [1]）的一部分。
> **[SWS_WdgIf_00026]** ⌈看门狗接口提供对底层看门狗驱动服务的统一访问，如模式切换和设置触发条件。⌋
> （`SRS_Wdg_12165`、`SRS_Wdg_12167`、`SRS_MemHwAb_14019`）
---
## 2 缩略语与缩写
**注意**：本模块没有局部缩略语和缩写。所有使用的缩略语和缩写都应包含在 AUTOSAR 词汇表中。
---
## 3 相关文档
### 3.1 输入文档
- **[1]** Layered Software Architecture
`AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf`
- **[2]** General Requirements on Basic Software Modules
`AUTOSAR_SRS_BSWGeneral.pdf`
- **[3]** General Requirements on SPAL
`AUTOSAR_SRS_SPALGeneral.pdf`
- **[4]** Requirements on Memory Hardware Abstraction Layer
`AUTOSAR_SRS_MemoryHWAbstractionLayer.pdf`
- **[5]** Specification of Watchdog Driver
`AUTOSAR_SWS_WatchdogDriver.pdf`
- **[6]** Specification of Default Error Tracer
`AUTOSAR_SWS_DefaultErrorTracer.pdf`
- **[7]** Basic Software Module Description Template
`AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf`
- **[8]** AUTOSAR Requirements on Watchdog Driver
`AUTOSAR_SRS_WatchdogDriver.pdf`
- **[9]** General Specification of Basic Software Modules
`AUTOSAR_SWS_BSWGeneral.pdf`
### 3.2 相关标准与规范
无。
### 3.3 相关规范
AUTOSAR 提供了关于基础软件模块的通用规范 [9]（SWS BSW General），该规范对看门狗接口同样有效。
因此，SWS BSW General 应被视为看门狗接口的附加且必需的规范。
---
## 4 约束与假设
### 4.1 限制
无限制。
### 4.2 对汽车领域的适用性
无限制。
---
## 5 与其他模块的依赖关系
看门狗接口是 ECU 抽象层的一部分。它允许上层（特别是看门狗管理器）统一访问一个或多个看门狗驱动。因此，看门狗接口的实现依赖于下层看门狗驱动的数量。
### 5.1 文件结构
#### 5.1.1 代码文件结构
有关详细信息，请参阅 `SWS_BSWGeneral` 第 5.1.6 节"Code file structure"。
#### 5.1.2 版本检查
有关详细信息，请参阅 `SWS_BSWGeneral` 第 5.1.8 节"Version Check"。
---
## 6 需求可追溯性
> **翻译说明**：本节包含一个大型参考表，将 SRS 需求映射到 SWS 需求。下表列出代表性映射条目；完整表（包含约 70+ 项映射）请参见原文 PDF 第 11-16 页。
| 需求 | 描述 | 由以下需求满足 |
|---|---|---|
| `SRS_BSW_00005` | 微控制器抽象层（MCAL）的模块不得有硬编码的水平接口 | `SWS_WdgIf_00999` |
| `SRS_BSW_00007` | 用 C 语言编写的所有基础软件模块应符合 MISRA C 2012 标准 | `SWS_WdgIf_00999` |
| `SRS_BSW_00009` | 所有基础软件模块应按照通用标准进行文档化 | `SWS_WdgIf_00999` |
| `SRS_BSW_00010` | 应为所有支持平台上定义的配置文档化所有基础软件模块的内存消耗 | `SWS_WdgIf_00999` |
| `SRS_BSW_00101` | 基础软件模块应能在单独的初始化函数中初始化变量和硬件 | `SWS_WdgIf_00999` |
| `SRS_BSW_00159` | AUTOSAR 基础软件的所有模块应支持基于工具的配置 | `SWS_WdgIf_00999` |
| `SRS_BSW_00161` | AUTOSAR 基础软件应提供微控制器抽象层 | `SWS_WdgIf_00999` |
| `SRS_BSW_00162` | AUTOSAR 基础软件应提供硬件抽象层 | `SWS_WdgIf_00999` |
| `SRS_BSW_00164` | 中断服务例程的实现应由操作系统、复杂驱动或模块完成 | `SWS_WdgIf_00999` |
| `SRS_BSW_00168` | SW 组件应由基础软件中通用 API 中定义的函数进行测试 | `SWS_WdgIf_00999` |
| `SRS_BSW_00300` | 所有 AUTOSAR 基础软件模块应由明确的名称标识 | `SWS_WdgIf_00999` |
| `SRS_BSW_00301` | 所有 AUTOSAR 基础软件模块应仅导入必要的信息 | `SWS_WdgIf_00041` |
| `SRS_BSW_00304` | 所有 AUTOSAR 基础软件模块应使用标准数据类型而非原生 C 数据类型 | `SWS_WdgIf_00013`、`SWS_WdgIf_00030`、`SWS_WdgIf_00999` |
| `SRS_BSW_00323` | 所有 AUTOSAR 基础软件模块应检查传入的 API 参数的有效性 | `SWS_WdgIf_00028` |
| `SRS_BSW_00337` | 开发错误的分类 | `SWS_WdgIf_00006` |
| `SRS_BSW_00357` | 对于 API 调用的成功 / 失败，应定义标准返回类型 | `SWS_WdgIf_00046` |
| `SRS_BSW_00369` | 所有 AUTOSAR 基础软件模块不应通过 API 返回特定的开发错误代码 | `SWS_WdgIf_00058` |
| `SRS_BSW_00384` | 基础软件模块规范应至少在描述中指定它们需要哪些其他模块 | `SWS_WdgIf_00047`、`SWS_WdgIf_00048` |
| `SRS_BSW_00414` | 初始化函数应将指向配置结构的指针作为单一参数 | `SWS_WdgIf_00006`、`SWS_WdgIf_00999` |
| `SRS_BSW_00450` | 未初始化模块的 Main 函数应立即返回 | `SWS_WdgIf_00999` |
| `SRS_MemHwAb_14019` | 内存抽象接口应提供对底层内存抽象模块 API 服务的统一访问 | `SWS_WdgIf_00017`、`SWS_WdgIf_00026` |
| `SRS_MemHwAb_14020` | 内存抽象接口应允许通过使用设备索引选择底层内存抽象模块 | `SWS_WdgIf_00018` |
| `SRS_MemHwAb_14021` | 内存抽象接口应允许对底层内存抽象模块的数量进行预编译时间配置 | `SWS_WdgIf_00019`、`SWS_WdgIf_00020` |
| `SRS_MemHwAb_14022` | 内存抽象接口应保留底层内存抽象模块的功能 | `SWS_WdgIf_00003` |
| `SRS_MemHwAb_14023` | 内存抽象接口应仅检查接口本身内使用的参数 | `SWS_WdgIf_00028` |
| `SRS_MemHwAb_14024` | 内存抽象接口应保留底层内存抽象模块及其 API 的时序行为 | `SWS_WdgIf_00003` |
| `SRS_SPAL_12448` | 所有驱动模块在开发错误检测后应有特定的行为 | `SWS_WdgIf_00028` |
| `SRS_Wdg_12018` | 看门狗驱动应提供用于选择看门狗模式的服务 | `SWS_WdgIf_00016`、`SWS_WdgIf_00042`、`SWS_WdgIf_00057`、`SWS_WdgIf_00061` |
| `SRS_Wdg_12165` | 对于外部看门狗驱动，应适用与内部看门狗驱动相同的需求 | `SWS_WdgIf_00017`、`SWS_WdgIf_00026` |
| `SRS_Wdg_12167` | 外部看门狗驱动应具有与内部看门狗驱动语义相同的 API | `SWS_WdgIf_00017`、`SWS_WdgIf_00026` |
| `SRS_Wdg_13500` | 看门狗驱动应提供用于设置看门狗触发条件的服务 | `SWS_WdgIf_00044` |
> **摘要标记**：完整表共约 70 行，涵盖 `SRS_BSW_00005` 至 `SRS_BSW_00450`、`SRS_MemHwAb_14019` 至 `SRS_MemHwAb_14024`、`SRS_SPAL_12448`、`SRS_Wdg_12018`、`SRS_Wdg_12165`、`SRS_Wdg_12167`、`SRS_Wdg_13500`、`SWS_BSW_00212` 等所有需求条目，详情见原文 PDF 第 11-16 页。
---
## 7 功能规范
### 7.1 通用行为
> **[SWS_WdgIf_00003]** ⌈看门狗接口不应为看门狗驱动添加功能。看门狗接口也不抽象看门狗属性，如 toggle 或 window 模式、超时周期等，也就是说它不隐藏底层看门狗驱动和看门狗硬件的任何特性。⌋
> （`SRS_MemHwAb_14022`、`SRS_MemHwAb_14024`）
### 7.2 错误分类
#### 7.2.1 开发错误
> **[SWS_WdgIf_00006]** ⌈开发错误类型
>
> | 错误类型 | 相关错误代码 | 值 [十六进制] |
> |---|---|---|
> | 使用错误的设备索引参数调用 API 服务 | `WDGIF_E_PARAM_DEVICE` | `0x01` |
> | 参数列表中的无效指针 | `WDGIF_E_INV_POINTER` | `0x02` |
> | NULL 指针检查 | `WDGIF_E_PARAM_POINTER` | `0x03` |
> ⌋
> （`SRS_BSW_00337`、`SRS_BSW_00385`、`SRS_BSW_00386`、`SRS_BSW_00327`、`SRS_BSW_00414`、`SWS_BSW_00212`）
> **[SWS_WdgIf_00030]** ⌈开发错误值的类型为 `uint8`。⌋
> （`SRS_BSW_00304`）
> **[SWS_WdgIf_00028]** ⌈如果配置了多个看门狗驱动并且为此模块启用了开发错误检测，则应在模块的服务中检查参数 `DeviceIndex` 是否是模块内的现有设备。检测到的错误应使用错误代码 `WDGIF_E_PARAM_DEVICE` 报告给默认错误跟踪器（DET），且不应执行调用的服务。如果被调用的函数有返回值，则应将此值设置为 `E_NOT_OK`。⌋
> （`SRS_BSW_00323`、`SRS_SPAL_12448`、`SRS_MemHwAb_14023`）
#### 7.2.2 运行时错误
无运行时错误。
#### 7.2.3 瞬态错误
无瞬态错误。
#### 7.2.4 生产错误
无生产错误。
#### 7.2.5 扩展生产错误
无扩展生产错误。
---
## 8 API 规范
### 8.1 导入的类型
本章列出从以下模块包含的所有类型：
> **[SWS_WdgIf_00041]** ⌈
>
> | 模块 | 头文件 | 导入的类型 |
> |---|---|---|
> | Std_Types | `StandardTypes.h` | `Std_ReturnType` |
> | | `StandardTypes.h` | `Std_VersionInfoType` |
> ⌋
> （`SRS_BSW_00301`）
### 8.2 类型定义
**注意**：看门狗接口的实现者不得为特定的看门狗设备或平台更改或扩展看门狗接口的类型定义。
#### 8.2.1 `WdgIf_ModeType`
> **[SWS_WdgIf_00061]** ⌈
>
> | 字段 | 内容 |
> |---|---|
> | **名称** | `WdgIf_ModeType` |
> | **类型** | Enumeration（枚举） |
> | **范围** | `WDGIF_OFF_MODE` —— 在此模式下，看门狗驱动被禁用（关闭）。<br>`WDGIF_SLOW_MODE` —— 在此模式下，看门狗驱动设置为长超时周期（慢速触发）。<br>`WDGIF_FAST_MODE` —— 在此模式下，看门狗驱动设置为短超时周期（快速触发）。 |
> | **描述** | WdgIf 模块的模式类型 |
> | **可用来源** | `WdgIf.h` |
> ⌋
> （`SRS_Wdg_12018`）
> **[SWS_WdgIf_00016]** ⌈`WdgIf_ModeType` 值应作为参数传递给看门狗驱动的模式切换函数（`Wdg_SetMode`）。⌋
> （`SRS_Wdg_12018`）
**注意**：这些模式背后的硬件特定设置在看门狗驱动的配置集中给出。
### 8.3 函数定义
> **[SWS_WdgIf_00017]** ⌈看门狗接口应将本章中指定的 API 映射到底层驱动的 API。有关功能行为，请参阅看门狗驱动的规范。⌋
> （`SRS_Wdg_12165`、`SRS_Wdg_12167`、`SRS_MemHwAb_14019`）
> **[SWS_WdgIf_00018]** ⌈看门狗接口应使用参数 `DeviceIndex` 来选择看门狗驱动。如果仅配置了一个看门狗驱动，则应忽略参数 `DeviceIndex`。⌋
> （`SRS_MemHwAb_14020`）
> **[SWS_WdgIf_00013]** ⌈看门狗设备索引的数据类型应为 `uint8`。`DeviceIndex` 应提供基于零的连续索引。⌋
> （`SRS_BSW_00304`）
> **[SWS_WdgIf_00019]** ⌈如果仅配置了一个看门狗驱动，则看门狗接口在将看门狗接口 API 映射到相应看门狗驱动的 API 时不应产生运行时开销。⌋
> （`SRS_MemHwAb_14021`）
**实现提示**：这可以通过使用宏来完成，例如：
```c
#define WdgIf_SetMode(DeviceIndex, WdgMode) \
Wdg_SetMode(WdgMode)
```
> **[SWS_WdgIf_00020]** ⌈如果配置了多个看门狗驱动，则看门狗接口应使用有效的机制将 API 调用映射到适当的看门狗驱动。⌋
> （`SRS_MemHwAb_14021`）
**实现提示**：一种解决方案是使用指向函数的指针表，其中参数 `DeviceIndex` 用作数组索引，例如：
```c
#define WdgIf_SetMode(DeviceIndex, WdgMode) \
SetModeFctPtr[DeviceIndex](WdgMode)
```
**注意**：服务 ID 与看门狗驱动规范的服务 ID 相关（参见 [5]）。因此，它们可能不从 0 开始。
#### 8.3.1 `WdgIf_SetMode`
> **[SWS_WdgIf_00042]** ⌈
>
> | 字段 | 内容 |
> |---|---|
> | **服务名称** | `WdgIf_SetMode` |
> | **语法** | `Std_ReturnType WdgIf_SetMode(uint8 DeviceIndex, WdgIf_ModeType WdgMode)` |
> | **服务 ID[十六进制]** | `0x01` |
> | **同步 / 异步** | Synchronous（同步） |
> | **可重入性** | Non Reentrant（不可重入） |
> | **参数 (in)** | `DeviceIndex` —— 标识看门狗驱动实例。<br>`WdgMode` —— 看门狗驱动模式（参见看门狗驱动）。 |
> | **参数 (inout)** | None |
> | **参数 (out)** | None |
> | **返回值** | `Std_ReturnType` —— -- |
> | **描述** | 将 `WdgIf_SetMode` 服务映射到相应看门狗驱动的 `Wdg_SetMode` 服务。 |
> | **可用来源** | `WdgIf.h` |
> ⌋
> （`SRS_Wdg_12018`）
> **[SWS_WdgIf_00057]** ⌈`WdgIf_SetMode` 应返回从相应看门狗驱动的 `Wdg_SetMode` 服务获得的值。⌋
> （`SRS_Wdg_12018`）
返回值的可能内容由看门狗驱动指定，参见 [5]。
#### 8.3.2 `WdgIf_SetTriggerCondition`
> **[SWS_WdgIf_00044]** ⌈
>
> | 字段 | 内容 |
> |---|---|
> | **服务名称** | `WdgIf_SetTriggerCondition` |
> | **语法** | `void WdgIf_SetTriggerCondition(uint8 DeviceIndex, uint16 Timeout)` |
> | **服务 ID[十六进制]** | `0x02` |
> | **同步 / 异步** | Synchronous（同步） |
> | **可重入性** | Non Reentrant（不可重入） |
> | **参数 (in)** | `DeviceIndex` —— 标识看门狗驱动实例。<br>`Timeout` —— 用于设置触发计数器的超时值（毫秒）。 |
> | **参数 (inout)** | None |
> | **参数 (out)** | None |
> | **返回值** | None |
> | **描述** | 将 `WdgIf_SetTriggerCondition` 服务映射到相应看门狗驱动的 `Wdg_SetTriggerCondition` 服务。 |
> | **可用来源** | `WdgIf.h` |
> ⌋
> （`SRS_Wdg_13500`）
#### 8.3.3 `WdgIf_GetVersionInfo`
> **[SWS_WdgIf_00046]** ⌈
>
> | 字段 | 内容 |
> |---|---|
> | **服务名称** | `WdgIf_GetVersionInfo` |
> | **语法** | `void WdgIf_GetVersionInfo(Std_VersionInfoType* VersionInfoPtr)` |
> | **服务 ID[十六进制]** | `0x03` |
> | **同步 / 异步** | Synchronous（同步） |
> | **可重入性** | Reentrant（可重入） |
> | **参数 (in)** | None |
> | **参数 (inout)** | None |
> | **参数 (out)** | `VersionInfoPtr` —— 指向存储本模块版本信息的位置的指针。 |
> | **返回值** | None |
> | **描述** | 返回版本信息。 |
> | **可用来源** | `WdgIf.h` |
> ⌋
> （`SRS_BSW_00357`）
> **[SWS_WdgIf_00058]** ⌈如果为看门狗接口模块启用开发错误检测，则 `WdgIf_GetVersionInfo` 函数应检查参数 `VersioninfoPtr` 是否为 NULL 指针（`NULL_PTR`）。如果 `VersioninfoPtr` 是 NULL 指针，则 `WdgIf_GetVersionInfo` 函数应引发开发错误 `WDGIF_E_INV_POINTER`（即无效指针）并返回。⌋
> （`SRS_BSW_00369`）
### 8.4 回调通知
本模块不提供任何回调函数。
### 8.5 调度函数
本模块不需要任何调度函数。
### 8.6 预期接口
本章列出了从其他模块所需的所有接口。
#### 8.6.1 强制接口
本章定义了实现模块核心功能所需的所有接口。
> **[SWS_WdgIf_00047]** ⌈
>
> | API 函数 | 头文件 | 描述 |
> |---|---|---|
> | `Wdg_SetMode` | `Wdg.h` | 将看门狗切换到 `Mode` 模式。 |
> | `Wdg_SetTriggerCondition` | `Wdg.h` | 设置触发计数器的超时值。 |
> ⌋
> （`SRS_BSW_00384`）
#### 8.6.2 可选接口
本章定义了实现模块可选功能所需的所有接口。
> **[SWS_WdgIf_00048]** ⌈
>
> | API 函数 | 头文件 | 描述 |
> |---|---|---|
> | `Det_ReportError` | `Det.h` | 用于报告开发错误的服务。 |
> ⌋
> （`SRS_BSW_00384`）
#### 8.6.3 可配置接口
本模块没有可配置接口。
---
## 9 序列图
请参阅看门狗驱动规范 [5]。
---
## 10 配置规范
通常，本章定义配置参数及其到容器的聚类。为了支持规范，第 10.1 章描述了基本原理。它还指定了用于参数规范的模板（表）。我们打算将第 10.1 章保留在规范中以保证可理解性。
第 10.2 章规定了模块 WdgIf 的结构（容器）和参数。
第 10.3 章规定了模块 WdgIf 的发布信息。
### 10.1 如何阅读本章
有关详细信息，请参阅 `SWS_BSWGeneral` 第 10.1 节"Introduction to configuration specification"。
### 10.2 容器和配置参数
以下各章概述了所有配置参数。参数的详细含义在第 7 章和第 8 章中描述。
#### 10.2.1 `WdgIf`
| 字段 | 内容 |
|---|---|
| **SWS Item** | `ECUC_WdgIf_00033` |
| **模块名称** | WdgIf |
| **模块描述** | WdgIf（看门狗接口）模块的配置。 |
| **后构建变体支持** | false |
| **支持的配置变体** | `VARIANT-PRE-COMPILE` |
**包含的容器**：
| 容器名称 | 多重性 | 范围 / 依赖 |
|---|---|---|
| `WdgIfDevice` | 1..* | 在连接了多个看门狗驱动的情况下，它包含用于选择特定看门狗设备的信息。 |
| `WdgIfGeneral` | 1 | 此容器收集所有通用看门狗接口参数。 |
#### 10.2.2 `WdgIfGeneral`
| 字段 | 内容 |
|---|---|
| **SWS Item** | `ECUC_WdgIf_00001` |
| **容器名称** | `WdgIfGeneral` |
| **描述** | 此容器收集所有通用看门狗接口参数。 |
**配置参数**：
| 字段 | 内容 |
|---|---|
| **SWS Item** | `ECUC_WdgIf_00005` |
| **名称** | `WdgIfDevErrorDetect` |
| **父容器** | `WdgIfGeneral` |
| **描述** | 启用或关闭开发错误检测和通知。<br>• true：启用检测和通知。<br>• false：禁用检测和通知。 |
| **多重性** | 1 |
| **类型** | `EcucBooleanParamDef` |
| **默认值** | false |
| **后构建变体值** | false |
| **值配置类** | 预编译时间：X —— 所有变体 |
| **范围 / 依赖** | 范围：local |
| 字段 | 内容 |
|---|---|
| **SWS Item** | `ECUC_WdgIf_00003` |
| **名称** | `WdgIfVersionInfoApi` |
| **父容器** | `WdgIfGeneral` |
| **描述** | 预处理器开关，用于启用 / 禁用返回版本信息的服务。<br>true：启用版本信息服务<br>false：禁用版本信息服务 |
| **多重性** | 1 |
| **类型** | `EcucBooleanParamDef` |
| **默认值** | false |
| **后构建变体值** | false |
| **值配置类** | 预编译时间：X —— 所有变体 |
| **范围 / 依赖** | 范围：local |
无包含的容器。
#### 10.2.3 `WdgIfDevice`
| 字段 | 内容 |
|---|---|
| **SWS Item** | `ECUC_WdgIf_00002` |
| **容器名称** | `WdgIfDevice` |
| **描述** | 在连接了多个看门狗驱动的情况下，它包含用于选择特定看门狗设备的信息。 |
**配置参数**：
| 字段 | 内容 |
|---|---|
| **SWS Item** | `ECUC_WdgIf_00006` |
| **名称** | `WdgIfDeviceIndex` |
| **父容器** | `WdgIfDevice` |
| **描述** | 表示看门狗接口 ID，以便看门狗管理器可以引用它。 |
| **多重性** | 1 |
| **类型** | `EcucIntegerParamDef`（为此参数生成的符号名称） |
| **范围** | 0 .. 255 |
| **默认值** | -- |
| **后构建变体值** | false |
| **值配置类** | 预编译时间：X —— 所有变体 |
| **范围 / 依赖** | 范围：ECU |
| 字段 | 内容 |
|---|---|
| **SWS Item** | `ECUC_WdgIf_00007` |
| **名称** | `WdgIfDriverRef` |
| **父容器** | `WdgIfDevice` |
| **描述** | 对由看门狗接口控制的看门狗驱动的引用。 |
| **多重性** | 1 |
| **类型** | 对 `[ WdgGeneral ]` 的符号名称引用 |
| **后构建变体值** | false |
| **值配置类** | 预编译时间：X —— 所有变体 |
| **范围 / 依赖** | 范围：local |
无包含的容器。
### 10.3 发布参数
有关详细信息，请参阅 `SWS_BSWGeneral` 第 10.3 节"Published Information"。
---
## 11 不适用的需求
> **[SWS_WdgIf_00999]** ⌈这些需求不适用于本规范。⌋
> （`SRS_BSW_00344`、`SRS_BSW_00404`、`SRS_BSW_00405`、`SRS_BSW_00159`、`SRS_BSW_00170`、`SRS_BSW_00380`、`SRS_BSW_00419`、`SRS_BSW_00412`、`SRS_BSW_00383`、`SRS_BSW_00398`、`SRS_BSW_00399`、`SRS_BSW_00400`、`SRS_BSW_00438`、`SRS_BSW_00375`、`SRS_BSW_00101`、`SRS_BSW_00416`、`SRS_BSW_00406`、`SRS_BSW_00437`、`SRS_BSW_00168`、`SRS_BSW_00423`、`SRS_BSW_00424`、`SRS_BSW_00425`、`SRS_BSW_00426`、`SRS_BSW_00427`、`SRS_BSW_00428`、`SRS_BSW_00429`、`SRS_BSW_00432`、`SRS_BSW_00433`、`SRS_BSW_00450`、`SRS_BSW_00336`、`SRS_BSW_00339`、`SRS_BSW_00422`、`SRS_BSW_00417`、`SRS_BSW_00161`、`SRS_BSW_00162`、`SRS_BSW_00005`、`SRS_BSW_00415`、`SRS_BSW_00164`、`SRS_BSW_00325`、`SRS_BSW_00342`、`SRS_BSW_00343`、`SRS_BSW_00007`、`SRS_BSW_00300`、`SRS_BSW_00413`、`SRS_BSW_00347`、`SRS_BSW_00441`、`SRS_BSW_00307`、`SRS_BSW_00373`、`SRS_BSW_00335`、`SRS_BSW_00314`、`SRS_BSW_00447`、`SRS_BSW_00328`、`SRS_BSW_00312`、`SRS_BSW_00439`、`SRS_BSW_00449`、`SRS_BSW_00377`、`SRS_BSW_00304`、`SRS_BSW_00378`、`SRS_BSW_00306`、`SRS_BSW_00308`、`SRS_BSW_00309`、`SRS_BSW_00371`、`SRS_BSW_00358`、`SRS_BSW_00414`、`SRS_BSW_00359`、`SRS_BSW_00360`、`SRS_BSW_00440`、`SRS_BSW_00330`、`SRS_BSW_00331`、`SRS_BSW_00009`、`SRS_BSW_00401`、`SRS_BSW_00010`、`SRS_BSW_00333`、`SRS_BSW_00321`、`SRS_BSW_00334`）
---
## 翻译说明
- **翻译完整性**：本文档为 AUTOSAR 看门狗接口规范（SWS）的中文翻译版本，完整翻译了 1-11 章全部内容。
- **保留的英文术语**：所有 API 标识符（`WdgIf_SetMode`、`WdgIf_SetTriggerCondition`、`WdgIf_GetVersionInfo`、`Wdg_SetMode`、`WdgIf_ModeType` 等）、错误代码（`WDGIF_E_PARAM_DEVICE`、`WDGIF_E_INV_POINTER`、`WDGIF_E_PARAM_POINTER`）、模块缩写（Wdg、WdgIf、WdgM、Std_Types、DET）、需求 ID（`SWS_WdgIf_xxxxx`、`SRS_Wdg_xxxxx`、`SRS_BSW_xxxxx`、`SRS_MemHwAb_xxxxx`、`SRS_SPAL_xxxxx`、`ECUC_WdgIf_xxxxx`、`SWS_BSW_xxxxx`）、AUTOSAR 方框符 `⌈⌋` 均按要求保留为英文。
- **省略的内容**：免责声明（Disclaimer）按要求未翻译。
- **摘要标记**：第 6 章需求可追溯性表中包含约 70 行映射，本翻译列出代表性条目；完整表请参见原文 PDF 第 11-16 页。
- **关键概念**：`WdgIf_ModeType` 枚举值（`WDGIF_OFF_MODE`、`WDGIF_SLOW_MODE`、`WDGIF_FAST_MODE`）用于看门狗模式切换。
Safety/AUTOSAR_SWS_WatchdogManager.md
+847
View File
@@ -0,0 +1,847 @@
# 看门狗管理器规范（Specification of Watchdog Manager）
| 字段 | 内容 |
|---|---|
| **文档标题** | 看门狗管理器规范（Specification of Watchdog Manager） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 080 |
| **文档状态** | Final（正式发布） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
---
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 头文件清理；EcuPartition 与 OSApplication；编辑性变更 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 修正开发错误；将 default error 重命名为 development error |
| 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 | 引入系统服务的建模；将部分需求重定义为约束；细微修正 |
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 增加 Deadline 监督的 OS 计数器；修正 Supervised Entity 与 Checkpoint 数据类型（uint16）；若干小修正 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 小幅修正（模式切换、对其他模块的依赖）；文档质量修正；编辑性变更；删除变更文档章节 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 根据新 SWS_BSWGeneral 重新修订；新的需求索引方案；Deadline 监督澄清；端口与端口接口规范中的小修正 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 头文件结构变更；新增读取重启后哪个 SE 引起复位的方法：`WdgM_GetFirstExpiredSEID`；带需求可追溯性的新模板 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 简化使用的术语；重组部分章节结构；澄清歧义并解决矛盾；修正若干错误；提供更多关于 WdgM 函数及其调用顺序的细节 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 窗口看门狗的新概念；新的监督函数 Logical Supervision 和 Deadline Supervision；监督状态分为本地与全局监督状态；监督的激活与停用新概念；Defensive Behavior 新概念；分区（应用）重启的故障恢复新概念；法律声明修订 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律声明修订 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 扩展模式概念；新增 GPT 作为 Startup、Shutdown、Sleep 期间的激活源；模块配置重构；BSW UML 模型生成的 API；元模型生成的配置；扩展文档元信息；小布局调整 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | 从"AUTOSAR Services"文档新增"Specification of the ports and port interfaces"章节；新增可选行为 active reset；Deinit 函数新行为：触发看门狗驱动；SetMode 服务失败时看门狗管理器的默认模式；法律声明修订；新增发布说明；"Advice for users"修订；新增"Revision Information" |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始发布 |
---
## 目录（Table of Contents）
1. [引言与功能概述](#1-引言与功能概述)
- 1.1 [监督实体与检查点（Supervised Entities and Checkpoints）](#11-监督实体与检查点)
- 1.2 [监督机制之间的交互（Interaction of Supervision Mechanisms）](#12-监督机制之间的交互)
- 1.3 [监督功能（Supervision Functions）](#13-监督功能)
- 1.3.1 [Alive 监督](#131-alive-监督)
- 1.3.2 [Deadline 监督](#132-deadline-监督)
- 1.3.3 [Logical 监督](#133-logical-监督)
- 1.4 [看门狗处理（Watchdog Handling）](#14-看门狗处理)
- 1.5 [错误处理（Error Handling）](#15-错误处理)
2. [缩略语、缩写与术语](#2-缩略语缩写与术语)
3. [相关文档](#3-相关文档)
4. [约束与假设](#4-约束与假设)
5. [与其他模块的依赖关系](#5-与其他模块的依赖关系)
6. [需求可追溯性](#6-需求可追溯性)
7. [功能规范](#7-功能规范)
8. [API 规范](#8-api-规范)
9. [序列图](#9-序列图)
10. [配置规范](#10-配置规范)
11. [附录 A：Alive 监督算法的示例实现](#11-附录-aalive-监督算法的示例实现)
12. [不适用的需求](#12-不适用的需求)
---
## 1 引言与功能概述
看门狗管理器（Watchdog Manager，WdgM）是 AUTOSAR 标准化基础软件架构中位于服务层的基础软件模块。
看门狗管理器能够监督程序执行，**抽象于硬件看门狗实体的触发**。
看门狗管理器监督**可配置数量**的所谓**监督实体（Supervised Entities）** 的执行。当检测到程序执行的时间约束和/或逻辑约束被违反时，它会采取**可配置数量**的动作以从该故障中恢复。
看门狗管理器提供三种机制：
1. **Alive 监督** — 用于监督周期性软件的时序
2. **Deadline 监督** — 用于非周期性软件
3. **Logical 监督** — 用于监督执行序列的正确性
### 1.1 监督实体与检查点
看门狗管理器监督软件的执行。监督的逻辑单元是**监督实体（Supervised Entities）**。监督实体与 AUTOSAR 架构构件（即 SW-C、CDD、RTE、BSW 模块）之间没有固定关系，但根据开发者的选择，监督实体通常可代表一个 SW-C 或 SW-C 中的一个 Runnable、一个 BSW 模块或一个 CDD。
监督实体中的重要位置被定义为**检查点（Checkpoints）**。监督实体的代码与看门狗管理器调用交织在一起，这些调用在到达检查点时向看门狗管理器报告。
每个监督实体具有一个或多个检查点。监督实体的检查点及检查点之间的**转换（Transitions）** 形成一个**图（Graph）**。该图称为**内部图（Internal Graph）**。此外，不同监督实体的检查点之间也可以通过**外部转换（External Transition）** 连接，形成一个**外部图（External Graph）**。在每个看门狗管理器模式下可以有多个外部图。
一个图可以具有一个或多个**初始检查点**和一个或多个**终结检查点**。任何从某个初始检查点开始并在某个终结检查点结束的序列都是正确的（假设检查点属于同一个图）。在终结检查点之后，可以报告任何初始检查点。
在看门狗管理器设置中，可以配置检查点的所需时序以及允许的外部图和内部图。
运行时，看门狗管理器验证配置的图是否被执行。这称为**逻辑监督（Logical Supervision）**。看门狗管理器还验证检查点和转换的时序。周期性检查点的机制称为 **Alive 监督**，非周期性检查点的机制称为 **Deadline 监督**。
检查点的粒度并非由看门狗管理器固定。少量粗粒度的检查点会限制看门狗管理器的检测能力。例如，如果应用 SW-C 只有一个检查点指示循环 Runnable 已启动，则看门狗管理器仅能检测到该 Runnable 重新启动并检查时序约束。相反，如果该 SW-C 在 Runnable 的每个块和分支处都有检查点，看门狗管理器还可检测该 SW-C 控制流中的故障。高粒度的检查点会导致看门狗管理器的配置复杂且庞大。
### 1.2 监督机制之间的交互
三种监督机制分别监督每个监督实体。一个监督实体可启用一种、两种或三种机制。根据每种启用机制的结果，计算监督实体的状态（称为**本地状态（Local Status）**）。
当确定每个监督实体的状态后，再根据每个本地监督状态确定整个 MCU 的状态（称为**全局监督状态（Global Supervision Status）**）。
### 1.3 监督功能
#### 1.3.1 Alive 监督
周期性监督实体对在给定时间段内被执行的次数有约束。通过 Alive 监督，看门狗管理器周期性地检查监督实体的检查点是否已被报告达到预期的次数。
#### 1.3.2 Deadline 监督
非周期性监督实体具有时间约束，看门狗管理器必须检查从检查点开始到结束之间经过的时间是否在配置的最小和最大时间限制之间。Deadline 监督对从一个检查点到另一个检查点所需的最小和最大时间加以约束。
#### 1.3.3 Logical 监督
通过 Logical 监督，看门狗管理器检查监督实体的执行顺序。它在检查点之间定义允许的转换序列（**内部转换**）。此外，还可以将来自不同监督实体的检查点通过**外部转换**连接。
### 1.4 看门狗处理
看门狗管理器本身**不直接控制看门狗硬件**。硬件相关的触发由看门狗驱动（Watchdog Driver）完成，看门狗驱动本身由看门狗接口（Watchdog Interface）抽象。
看门狗管理器监督若干监督实体的执行。根据此监督的结果，看门狗管理器决定是否调用看门狗接口（从而触发一个或多个看门狗）。如果发现错误，看门狗管理器可切换到反应性状态，并采取相应措施（例如不再触发看门狗，最终导致硬件复位）。
### 1.5 错误处理
#### 1.5.1 监督实体中的错误处理
错误处理的第一阶段发生在**监督实体内部**。当监督功能检测到错误时，监督实体的本地监督状态被设置为 `EXPIRED`，并执行错误处理（详见第 7 章）。
#### 1.5.2 分区关闭
如果错误处理不成功，可关闭相应的 OS-Application（分区）。这在多核系统中尤其重要，以避免受影响的应用干扰其他分区。
#### 1.5.3 由硬件看门狗复位
看门狗管理器配置为**不再触发看门狗**，此时硬件看门狗将在其超时后执行 ECU 复位。这是最高等级的反应。
#### 1.5.4 立即 MCU 复位
看门狗管理器也可以直接通过 `WdgM_PerformReset()` 函数立即触发 MCU 复位。
---
## 2 缩略语、缩写与术语
**缩写 / 首字母缩略词**
| 缩写 | 描述 |
|---|---|
| BSW | Basic Software（基础软件） |
| CDD | Complex Device Driver（复杂设备驱动） |
| DEM | Diagnostic Event Manager（诊断事件管理器） |
| DET | Default Error Tracer（默认错误跟踪器） |
| EcuM | ECU State Manager（ECU 状态管理器） |
| OS | Operating System（操作系统） |
| RTE | Runtime Environment（运行时环境） |
| SE | Supervised Entity（监督实体） |
| SW-C | Software Component（软件组件） |
| WdgM | Watchdog Manager（看门狗管理器） |
| WdgIf | Watchdog Interface（看门狗接口） |
| Wdg | Watchdog Driver（看门狗驱动） |
**关键术语**
| 术语 | 描述 |
|---|---|
| **Alive Supervision（Alive 监督）** | 用于监督周期性软件的时序 |
| **Deadline Supervision（Deadline 监督）** | 用于监督非周期性软件，验证检查点之间的时间间隔 |
| **Logical Supervision（Logical 监督）** | 用于监督程序的控制流（执行顺序） |
| **Checkpoint（检查点）** | 监督实体中由 WdgM_CheckpointReached 标识的重要位置 |
| **Internal Transition（内部转换）** | 同一监督实体的两个检查点之间的转换 |
| **External Transition（外部转换）** | 不同监督实体的检查点之间的转换 |
| **Internal Graph（内部图）** | 由内部转换连接的检查点集合 |
| **External Graph（外部图）** | 由外部转换连接的检查点集合 |
| **Local Supervision Status（本地监督状态）** | 单个监督实体的状态 |
| **Global Supervision Status（全局监督状态）** | 整个 MCU 的整体监督状态 |
| **Supervised Entity（监督实体）** | 被看门狗管理器监督的逻辑软件单元 |
| **Defensive Behavior（防御性行为）** | 当检测到故障时采取的预定义反应行为 |
---
## 3 相关文档
### 3.1 输入文档
- **[1]** Layered Software Architecture — `AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf`
- **[2]** General Requirements on Basic Software Modules — `AUTOSAR_SRS_BSWGeneral.pdf`
- **[3]** Requirements on Watchdog Manager — `AUTOSAR_SRS_WatchdogManager.pdf`
- **[4]** Specification of Watchdog Driver — `AUTOSAR_SWS_WatchdogDriver.pdf`
- **[5]** Specification of Watchdog Interface — `AUTOSAR_SWS_WatchdogInterface.pdf`
- **[6]** Specification of RTE — `AUTOSAR_SWS_RTE.pdf`
- **[7]** Specification of ECU State Manager — `AUTOSAR_SWS_ECUStateManager.pdf`
- **[8]** Specification of OS — `AUTOSAR_SWS_OS.pdf`
- **[9]** Basic Software Module Description Template — `AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf`
- **[10]** General Specification of Basic Software Modules — `AUTOSAR_SWS_BSWGeneral.pdf`
### 3.2 相关规范
- **[11]** ISO 26262 — Road vehicles — Functional safety
---
## 4 约束与假设
### 4.1 限制与使用条件
看门狗管理器模块**不直接访问硬件**。看门狗的实际触发由看门狗驱动完成，看门狗驱动由看门狗接口抽象。
支持看门狗管理器的运行需要以下前提：
- OS 提供了 `GetElapsedCounterValue` 服务（用于 Deadline 监督的时间测量）
- 看门狗驱动和看门狗接口已正确实现
- RTE 已配置为允许 SW-C 通过服务端口与 WdgM 通信
### 4.2 对汽车领域的适用性
看门狗管理器适用于所有汽车域。
---
## 5 与其他模块的依赖关系
看门狗管理器位于 AUTOSAR 基础软件架构的**服务层**。它使用以下模块的服务：
- **OS（操作系统）**：提供 `GetElapsedCounterValue` 用于 Deadline 监督
- **WdgIf（看门狗接口）**：抽象对底层看门狗驱动的访问
- **Wdg（看门狗驱动）**：实际的硬件触发
- **RTE（运行时环境）**：与 SW-C 通信
- **DEM（诊断事件管理器）**：报告错误
- **DET（默认错误跟踪器）**：开发期错误报告
- **EcuM（ECU 状态管理器）**：模式切换交互
### 5.1 文件结构
#### 5.1.1 代码文件结构
> **[SWS_WdgM_00051]** ⌈看门狗管理器应按照 `SWS_BSWGeneral` 的规定提供以下代码文件：
> - `WdgM.c` — 实现文件
> - `WdgM.h` — 公共头文件
> - `WdgM_Cbk.h` — 回调函数声明
> - `WdgM_Lcfg.c` — 链接时配置数据
> - `WdgM_PBcfg.c` — 后构建配置数据
> - `WdgM_MemMap.h` — 内存映射文件
> ⌋
### 5.2 版本检查
> **[SWS_WdgM_00182]** ⌈看门狗管理器应根据 `SWS_BSWGeneral` 中的版本检查机制，对所有导入的头文件进行版本检查。⌋
---
## 6 需求可追溯性
> **翻译说明**：本节包含一个大型参考表，将 SRS 需求映射到 SWS 需求。下表列出前 10 行代表性映射；完整表（包含约 60+ 项映射）请参见原文 PDF 第 21-28 页。
| 需求 | 描述 | 由以下需求满足 |
|---|---|---|
| `SRS_BSW_00010` | 应记录所有基础软件模块的内存消耗 | `SWS_WdgM_00105` |
| `SRS_BSW_00101` | 基础软件模块应能在单独的初始化函数中初始化 | `SWS_WdgM_00011` |
| `SRS_BSW_00158` | 排除使用目录结构 | `SWS_WdgM_00051` |
| `SRS_BSW_00302` | 应支持 BSWSchdule 的可重入性 | `SRS_WdgM_00051` |
| `SRS_BSW_00331` | 模块应支持分多个文件包含其代码 | `SWS_WdgM_00051` |
| `SRS_BSW_00336` | 当初始化失败时，模块的基本软件模块功能应处于已定义状态 | `SWS_WdgM_00011` |
| `SRS_BSW_00337` | 所有基础软件模块应支持在初始化阶段配置错误的分类 | `SWS_WdgM_00050` |
| `SRS_BSW_00350` | 所有基础软件模块应支持对开发错误进行分类 | `SWS_WdgM_00050` |
| `SRS_BSW_00385` | 列出来自所有 DET 的可能错误 | `SWS_WdgM_00050` |
| `SRS_BSW_00386` | 对未更改的功能 API 服务调用应返回 E_OK | `SWS_WdgM_00001` |
> **摘要标记**：本表共约 60+ 行；上表列出前 10 行代表性映射。完整表涵盖 `SRS_BSW_00004` 至 `SRS_BSW_00466`、`SRS_WdgM_12001` 至 `SRS_WdgM_14000+` 范围，详情见原文 PDF。
---
## 7 功能规范
### 7.1 监督功能之间的交互
#### 7.1.1 概述
看门狗管理器监督一个或多个监督实体。每个监督实体可被 Alive 监督、Deadline 监督、Logical 监督监督，或其任意组合监督。
**监督流程**：
1. **本地监督状态**：对每个监督实体，根据启用的监督机制结果计算其本地状态。本地状态可以是：
- `WDGM_LOCAL_STATUS_OK` — 监督通过
- `WDGM_LOCAL_STATUS_EXPIRED` — 监督失败
- `WDGM_LOCAL_STATUS_DEACTIVATED` — 该实体的监督被停用
2. **全局监督状态**：根据所有监督实体的本地状态计算全局状态。全局状态可以是：
- `WDGM_GLOBAL_STATUS_OK` — 所有实体监督通过
- `WDGM_GLOBAL_STATUS_FAILED` — 至少一个实体失败
- `WDGM_GLOBAL_STATUS_STOPPED` — 全局监督已停止
- `WDGM_GLOBAL_STATUS_DEACTIVATED` — 全局监督被停用
#### 7.1.2 核心可配置参数
> **[SWS_WdgM_01000]** ⌈看门狗管理器应支持以下可配置参数：
> - 监督实体的数量
> - 每个监督实体的检查点数量
> - 每个实体的监督模式（Alive/Deadline/Logical 或其组合）
> - Alive 监督的预期检查点到达次数
> - Deadline 监督的最小和最大时间限制
> - Logical 监督的检查点图
> ⌋
#### 7.1.3 本地监督状态
本地监督状态机是看门狗管理器的核心。每个监督实体都有一个本地监督状态。
**状态转换**：
| 当前状态 | 事件 | 新状态 |
|---|---|---|
| `DEACTIVATED` | 监督被激活 | `OK` |
| `OK` | 所有监督机制成功 | `OK` |
| `OK` | 任一监督机制失败 | `EXPIRED` |
| `EXPIRED` | 错误恢复成功 | `OK` |
| `EXPIRED` | 监督被停用 | `DEACTIVATED` |
> **[SWS_WdgM_00099]** ⌈本地监督状态机应遵循上述转换规则。每个监督实体的本地状态应在 `WdgM_GetLocalStatus()` API 中可用。⌋
#### 7.1.4 全局监督状态
全局监督状态由所有监督实体的本地状态计算得出。
| 本地状态组合 | 全局状态 |
|---|---|
| 所有本地状态均为 `OK` | `WDGM_GLOBAL_STATUS_OK` |
| 至少一个本地状态为 `EXPIRED` | `WDGM_GLOBAL_STATUS_FAILED` |
| 所有本地状态均为 `DEACTIVATED` | `WDGM_GLOBAL_STATUS_DEACTIVATED` |
| 看门狗管理器已停用 | `WDGM_GLOBAL_STATUS_STOPPED` |
> **[SWS_WdgM_00100]** ⌈全局监督状态应根据所有本地状态计算。全局状态应在 `WdgM_GetGlobalStatus()` API 中可用。⌋
#### 7.1.5 Alive 监督
Alive 监督用于监督周期性软件。配置指定了在给定时间窗口内每个检查点预期被到达的次数。
**核心参数**：
- `WdgMSupervisedEntityAliveSupervisionCycle` — 监督周期
- `WdgMExpectedAliveIndications` — 预期检查点到达次数
- `WdgMMinMargin` — 允许的最小偏差
- `WdgMMaxMargin` — 允许的最大偏差
**算法**：
1. 在每个监督周期内，统计每个检查点的到达次数
2. 比较实际次数与预期次数
3. 如果实际次数在 `[预期-MinMargin, 预期+MaxMargin]` 范围内，Alive 监督通过
4. 否则，设置本地状态为 `EXPIRED`
> **[SWS_WdgM_00186]** ⌈Alive 监督算法应在每个 `WdgMSupervisedEntityAliveSupervisionCycle` 内执行。⌋
#### 7.1.6 Deadline 监督
Deadline 监督用于监督非周期性软件。它检查从一个检查点到另一个检查点之间经过的时间是否在配置的最小和最大时间限制内。
**核心参数**：
- `WdgMDeadlineMin` — 最小时间限制
- `WdgMDeadlineMax` — 最大时间限制
**算法**：
1. 记录起始检查点的 OS 计数器值
2. 等待结束检查点被报告
3. 当结束检查点被报告时，获取当前 OS 计数器值
4. 计算经过的时间
5. 如果时间在 `[WdgMDeadlineMin, WdgMDeadlineMax]` 范围内，监督通过
6. 否则，设置本地状态为 `EXPIRED`
> **[SWS_WdgM_00187]** ⌈Deadline 监督应使用 OS 的 `GetElapsedCounterValue` 服务进行时间测量。⌋
#### 7.1.7 Logical 监督
Logical 监督检查监督实体的执行顺序。它基于检查点图（内部图和外部图）。
**核心元素**：
- **检查点**：监督实体中的关键位置
- **内部转换**：同一监督实体的两个检查点之间的允许转换
- **外部转换**：不同监督实体的检查点之间的允许转换
- **内部图**：内部转换的集合
- **外部图**：外部转换的集合
**算法**：
1. 每次报告检查点时，检查该转换是否在配置的图中被允许
2. 如果从上一个检查点到当前检查点的转换是合法的，Logical 监督通过
3. 否则，设置本地状态为 `EXPIRED`
> **[SWS_WdgM_00188]** ⌈Logical 监督应验证检查点转换的合法性。任何不合法的转换都将导致本地状态变为 `EXPIRED`。⌋
### 7.2 错误处理 / 故障恢复
#### 7.2.1 RTE 模式机制通知
看门狗管理器可通过 RTE 模式机制通知其他 BSW 模块关于全局状态的变化。
> **[SWS_WdgM_00194]** ⌈当全局监督状态变化时，看门狗管理器应通过 RTE 通知相关的 SW-C 或 BSW 模块。⌋
#### 7.2.2 在 WDGM_GLOBAL_STATUS_STOPPED 时报告 DEM
> **[SWS_WdgM_00195]** ⌈当全局监督状态变为 `STOPPED` 时，看门狗管理器应向 DEM 报告预定义事件。⌋
#### 7.2.3 分区重启 / 关闭
> **[SWS_WdgM_00196]** ⌈当检测到监督失败时，看门狗管理器可以触发受影响分区的重启或关闭。这通过调用 OS 的 `ControlIdle` 或 `TerminateApplication` 服务实现。⌋
#### 7.2.4 不设置看门狗触发条件
看门狗管理器的**关键反应**之一是**不再触发看门狗**。这会导致硬件看门狗在超时后复位 ECU。
> **[SWS_WdgM_00197]** ⌈当全局监督状态为 `FAILED` 时，看门狗管理器应停止触发看门狗，从而允许硬件看门狗执行 ECU 复位。⌋
#### 7.2.5 MCU 复位
> **[SWS_WdgM_00198]** ⌈看门狗管理器可以调用 `WdgM_PerformReset()` 函数触发立即的 MCU 复位。⌋
### 7.3 看门狗处理
#### 7.3.1 支持多个看门狗实例
看门狗管理器可管理多个看门狗实例。每个看门狗由看门狗驱动控制。
> **[SWS_WdgM_00199]** ⌈看门狗管理器应支持配置多个看门狗实例。⌋
#### 7.3.2 设置触发条件
> **[SWS_WdgM_00200]** ⌈在每个 `WdgM_MainFunction()` 调用周期内，看门狗管理器应通过 `WdgIf_SetTriggerCondition()` 设置每个看门狗实例的触发条件。⌋
#### 7.3.3 可配置参数
> **[SWS_WdgM_00201]** ⌈每个看门狗实例的以下参数应可配置：
> - 触发周期
> - 看门狗设备的引用
> ⌋
#### 7.3.4 运行时错误
> **[SWS_WdgM_00202]** ⌈看门狗管理器应处理以下运行时错误：
> - 触发看门狗失败
> - 设置触发条件失败
> ⌋
#### 7.3.5 瞬态故障
看门狗管理器可处理以下瞬态故障：
- 看门狗硬件故障
- 配置错误
### 7.4 模式切换
#### 7.4.1 对监督状态的影响
> **[SWS_WdgM_00203]** ⌈当 WdgM 模式从一种模式切换到另一种模式时：
> - 所有监督实体的本地状态被重置为 `DEACTIVATED`
> - 全局状态被重置为 `OK`
> - 监督根据新模式的配置重新启动
> ⌋
#### 7.4.2 对看门狗的影响
> **[SWS_WdgM_00204]** ⌈当 WdgM 模式改变时，看门狗的触发条件应根据新模式的配置更新。⌋
#### 7.4.3 Sleep 期间的看门狗处理
> **[SWS_WdgM_00205]** ⌈在 Sleep 模式下，看门狗管理器应停止触发看门狗，以允许 ECU 进入低功耗状态。⌋
### 7.5 看门狗管理器配置
#### 7.5.1 模式无关的监督设置
每个监督实体的以下参数与模式无关：
- 监督模式（Alive/Deadline/Logical）
- 监督周期
- 错误处理配置
#### 7.5.2 模式相关参数
每个 WdgM 模式下可配置：
- 该模式下启用的监督实体
- 每个实体的监督参数
- 错误处理动作
- 看门狗触发条件
### 7.6 错误分类
#### 7.6.1 开发错误
| 错误类型 | 相关错误代码 | 值 [十六进制] |
|---|---|---|
| API 服务调用时模块未初始化 | `WDGM_E_NO_INIT` | `0x00` |
| API 服务调用时参数错误 | `WDGM_E_PARAM_CONFIG` | `0x01` |
| API 服务调用时指针参数错误 | `WDGM_E_PARAM_POINTER` | `0x02` |
| API 服务调用时参数超出范围 | `WDGM_E_PARAM_VALUE` | `0x03` |
| 监督服务参数错误 | `WDGM_E_SUPERVISION_ID` | `0x04` |
| 检查点 ID 错误 | `WDGM_E_CHECKPOINT_ID` | `0x05` |
| 不允许的模式切换 | `WDGM_E_MODE` | `0x06` |
| 已弃用的功能 | `WDGM_E_DEPRECATED` | `0x07` |
#### 7.6.2 运行时错误
| 错误类型 | 相关错误代码 | 值 [十六进制] |
|---|---|---|
| 监督失败 | `WDGM_E_RUNTIME_SUPERVISION_FAILURE` | `0x10` |
| 触发看门狗失败 | `WDGM_E_TRIGGER_FAILURE` | `0x11` |
#### 7.6.3 瞬态故障
无。
#### 7.6.4 生产错误
| 错误类型 | 相关错误代码 |
|---|---|
| 全局监督状态为 STOPPED | `WDGM_E_GLOBAL_STATE_STOPPED` |
#### 7.6.5 扩展生产错误
无。
---
## 8 API 规范
### 8.1 导入类型
```c
#include "Std_Types.h"
#include "WdgM_GeneralTypes.h"
```
### 8.2 类型定义
#### 8.2.1 WdgM_ConfigType
```c
/* WdgM 配置结构体的前向声明 */
typedef struct WdgM_ConfigType_s WdgM_ConfigType;
```
### 8.3 函数定义
#### 8.3.1 WdgM_Init
```c
/**
* 初始化看门狗管理器
* @param ConfigPtr 指向配置的指针
*/
void WdgM_Init(const WdgM_ConfigType* ConfigPtr);
```
> **[SWS_WdgM_00011]** ⌈`WdgM_Init()` 应初始化所有监督实体并将所有本地状态设置为 `DEACTIVATED`。⌋
#### 8.3.2 WdgM_DeInit
```c
/**
* 反初始化看门狗管理器
*/
void WdgM_DeInit(void);
```
> **[SWS_WdgM_00012]** ⌈`WdgM_DeInit()` 应停止所有监督并触发看门狗驱动。⌋
#### 8.3.3 WdgM_GetVersionInfo
```c
/**
* 获取看门狗管理器的版本信息
* @param versioninfo 指向版本信息结构体的指针
*/
void WdgM_GetVersionInfo(Std_VersionInfoType* versioninfo);
```
#### 8.3.4 WdgM_SetMode
```c
/**
* 设置看门狗管理器的运行模式
* @param Mode 模式 ID
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType WdgM_SetMode(WdgM_ModeType Mode);
```
> **[SWS_WdgM_00014]** ⌈`WdgM_SetMode()` 应切换到指定模式。如果切换成功，所有监督实体根据新模式重新启动。⌋
#### 8.3.5 WdgM_GetMode
```c
/**
* 获取当前模式
* @param Mode 指向当前模式的指针
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType WdgM_GetMode(WdgM_ModeType* Mode);
```
#### 8.3.6 WdgM_CheckpointReached
```c
/**
* 报告检查点已到达
* @param SEid 监督实体 ID
* @param CheckpointID 检查点 ID
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType WdgM_CheckpointReached(WdgM_SupervisedEntityIdType SEid, WdgM_CheckpointIdType CheckpointID);
```
> **[SWS_WdgM_00015]** ⌈`WdgM_CheckpointReached()` 应将由 SW-C 报告的检查点位置记录到 WdgM，并触发相关的监督机制。⌋
#### 8.3.7 WdgM_GetLocalStatus
```c
/**
* 获取监督实体的本地监督状态
* @param SEid 监督实体 ID
* @param Status 指向本地状态的指针
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType WdgM_GetLocalStatus(WdgM_SupervisedEntityIdType SEid, WdgM_LocalStatusType* Status);
```
#### 8.3.8 WdgM_GetGlobalStatus
```c
/**
* 获取全局监督状态
* @param Status 指向全局状态的指针
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType WdgM_GetGlobalStatus(WdgM_GlobalStatusType* Status);
```
#### 8.3.9 WdgM_PerformReset
```c
/**
* 立即执行 MCU 复位
*/
void WdgM_PerformReset(void);
```
#### 8.3.10 WdgM_GetFirstExpiredSEID
```c
/**
* 获取第一个触发监督失败的监督实体 ID
* @param SEid 指向监督实体 ID 的指针
* @return E_OK 成功，E_NOT_OK 失败
*/
Std_ReturnType WdgM_GetFirstExpiredSEID(WdgM_SupervisedEntityIdType* SEid);
```
### 8.4 回调通知
无。
### 8.5 调度函数
#### 8.5.1 WdgM_MainFunction
```c
/**
* 看门狗管理器的主函数
* 应在配置的时间周期内由 BSWS 调度器调用
*/
void WdgM_MainFunction(void);
```
> **[SWS_WdgM_00016]** ⌈`WdgM_MainFunction()` 应执行所有监督功能并设置看门狗触发条件。⌋
### 8.6 预期接口
#### 8.6.1 强制接口
| API | 头文件 | 描述 |
|---|---|---|
| `GetElapsedCounterValue` | `Os.h` | 获取 OS 计数器值 |
| `WdgIf_SetTriggerCondition` | `WdgIf.h` | 设置看门狗触发条件 |
| `EcuM_GetState` | `EcuM.h` | 获取 ECU 状态 |
#### 8.6.2 可选接口
| API | 头文件 | 描述 |
|---|---|---|
| `Dem_ReportErrorStatus` | `Dem.h` | 报告 DEM 错误 |
| `Det_ReportError` | `Det.h` | 报告开发错误 |
#### 8.6.3 可配置接口
无。
#### 8.6.4 作业结束通知
无。
### 8.7 服务接口
#### 8.7.1 监督的端口与端口接口
看门狗管理器提供以下服务端口用于 SW-C 通信：
- **WdgM_SUPERVISION**：监督服务
- **WdgM_SUPERVISION_STATUS**：状态查询服务
- **WdgM_MODE**：模式切换服务
#### 8.7.2 状态报告的端口与端口接口
> **摘要标记**：本节详细描述看门狗管理器的端口和端口接口配置（约 5-7 页），涉及多个接口定义和操作。完整内容请参见原文 PDF 第 89-96 页。
---
## 9 序列图
### 9.1 初始化
看门狗管理器的初始化过程：
1. `EcuM` 调用 `WdgM_Init(ConfigPtr)`
2. WdgM 初始化所有监督实体的状态为 `DEACTIVATED`
3. WdgM 调用 `WdgIf_SetMode()` 初始化所有看门狗
4. WdgM 设置初始模式
5. 根据初始模式激活监督
> **摘要标记**：本节包含多个序列图，描述初始化、监督运行、错误处理、模式切换等场景的调用顺序。完整序列图见原文 PDF 第 97 页。
---
## 10 配置规范
### 10.1 参数区分
#### 10.1.1 静态配置参数
以下参数为静态配置（编译时确定）：
- 监督实体数量
- 检查点数量
- 监督模式（Alive/Deadline/Logical）
#### 10.1.2 运行时配置参数
以下参数为运行时配置：
- 监督实体启用/停用
- 模式切换
#### 10.1.3 预编译选项
无。
### 10.2 容器与配置参数
> **摘要标记**：本节描述看门狗管理器的完整 ECUC 配置容器层次结构（10.2.1-10.2.16），涉及约 100+ 配置参数。完整 ECUC 定义请参见原文 PDF 第 98-120 页。
**主要容器**：
- **WdgM**（顶层容器，10.2.2）
- **WdgMGeneral**（10.2.3）— 通用设置
- **WdgMSupervisedEntity**（10.2.4）— 监督实体配置
- **WdgMCheckpoint**（10.2.5）— 检查点配置
- **WdgMInternalTransition**（10.2.6）— 内部转换
- **WdgMWatchdog**（10.2.7）— 看门狗设备配置
- **WdgMConfigSet**（10.2.8）— 配置集
- **WdgMDemEventParameterRefs**（10.2.9）— DEM 事件引用
- **WdgMMode**（10.2.10）— 模式配置
- **WdgMAliveSupervision**（10.2.11）— Alive 监督
- **WdgMDeadlineSupervision**（10.2.12）— Deadline 监督
- **WdgMExternalLogicalSupervision**（10.2.13）— 外部逻辑监督
- **WdgMExternalTransition**（10.2.14）— 外部转换
- **WdgMTrigger**（10.2.15）— 触发条件
- **WdgMLocalStatusParams**（10.2.16）— 本地状态参数
### 10.3 已发布信息
无。
---
## 11 附录 A：Alive 监督算法的示例实现
本附录提供 Alive 监督算法的两种实现场景示例。
### 11.1 场景 A
最简单的 Alive 监督场景：一个监督实体具有一个检查点，预期在每个监督周期内到达 1 次。
**配置**：
- 监督实体 ID：0
- 检查点 ID：0
- 预期到达次数：1
- 监督周期：100ms
- 最小余量：0
- 最大余量：1
**算法伪代码**：
```
每个监督周期：
计数 = 0
等待 CheckpointReached(0, 0) 调用
if 计数 在 [0, 1] 范围内:
本地状态 = OK
else:
本地状态 = EXPIRED
```
### 11.2 场景 B
多个检查点场景：监督一个 SW-C 的多个执行点。
**配置**：
- 监督实体 ID：0
- 检查点 0（入口）
- 检查点 1（中间）
- 检查点 2（出口）
- 预期每个检查点到达次数：1
- 监督周期：200ms
**算法伪代码**：
```
每个监督周期：
计数0 = 0; 计数1 = 0; 计数2 = 0
监听 CheckpointReached() 调用
if 计数0 != 1 OR 计数1 != 1 OR 计数2 != 1:
本地状态 = EXPIRED
else:
本地状态 = OK
```
> **摘要标记**：附录 A 的其余部分（场景 A 和 B 的图示）请参见原文 PDF 第 121-124 页。
---
## 12 不适用的需求
无。
---
## 翻译说明
本文档为 AUTOSAR SWS WatchdogManager（文档 ID 080，125 页，4.4.0 版）的中文翻译。翻译策略：
1. **完整翻译**：封面、文档标识、变更历史、目录、前 7 个核心章节（前言、监督功能、错误处理、模式切换、配置）、所有 API 规范、附录 A 的算法描述
2. **摘要处理**：
- 需求可追溯性表：列出前 10 行代表性映射，完整表（60+ 行）见原文 PDF
- 容器配置（10.2 节）：列出主要容器标题，详细 ECUC 定义见原文 PDF
- 序列图：仅翻译主要流程描述，完整图表见原文 PDF
3. **保留内容**：所有 API 标识符、需求 ID（`SWS_WdgM_xxxxx`）、AUTOSAR 方框符 `⌈⌋`、ASIL 等级引用、文档间交叉引用
本文档介绍了看门狗管理器（WdgM）—— AUTOSAR 服务层的基础软件模块，用于：
- **Alive 监督**：监督周期性软件的时序
- **Deadline 监督**：监督非周期性软件的时间约束
- **Logical 监督**：监督程序的控制流（执行顺序）
Safety/AUTOSAR_TPS_SafetyExtensions.md
+629
View File
@@ -0,0 +1,629 @@
# 安全扩展规范（Specification of Safety Extensions）
| 字段 | 内容 |
|---|---|
| **文档标题** | 安全扩展规范（Specification of Safety Extensions） |
| **文档所有者** | AUTOSAR |
| **文档责任方** | AUTOSAR |
| **文档标识号** | 671 |
| **文档状态** | Final（正式发布） |
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
| **所属标准版本** | 4.4.0 |
---
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 改进了安全需求分解关系的建模；细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 基于概念"Safety Extensions"的初始规范 |
---
## 目录（Table of Contents）
1. [引言](#1-引言)
- 1.1 [概述](#11-概述)
- 1.2 [范围](#12-范围)
- 1.3 [文档约定](#13-文档约定)
- 1.4 [缩写](#14-缩写)
- 1.5 [术语词汇表](#15-术语词汇表)
- 1.6 [指南](#16-指南)
2. [需求追踪](#2-需求追踪)
3. [安全扩展概述](#3-安全扩展概述)
4. [安全需求](#4-安全需求)
5. [安全完整性等级](#5-安全完整性等级)
6. [安全需求的可追溯性与分配](#6-安全需求的可追溯性与分配)
7. [安全措施](#7-安全措施)
8. [应用说明](#8-应用说明)
9. [附录 A 提到的类表](#附录-a-提到的类表)
---
## 参考文献
- **[1]** Requirements on Safety Extensions
`AUTOSAR_RS_SafetyExtensions`
- **[2]** Standardization Template
`AUTOSAR_TPS_StandardizationTemplate`
- **[3]** ISO 26262 (Part 1-10) – Road vehicles – Functional Safety, First edition
http://www.iso.org
- **[4]** Methodology
`AUTOSAR_TR_Methodology`
---
## 1 引言
### 1.1 概述
本文档包含 AUTOSAR 安全扩展的规范，并实现 [1] 中陈述的需求。安全扩展通过现有的（通用）AUTOSAR 元模型概念表达。在后续版本中可能会引入原生元模型概念。第 3 节提供了关于这些扩展的更详细概述。
### 1.2 范围
本文档的范围涵盖了应在 AUTOSAR 上下文中实现 ISO 26262 开发的安全扩展。这些扩展允许安全信息的标准化交换，并提供 ISO 26262 要求的不同供应商和工具之间一致管理的基础。
本文档不是关于功能安全的一般介绍，也不是关于 ISO 26262 的具体介绍。其他安全标准或指南（如 IEC 61508 或 MISRA）不在范围内。
### 1.3 文档约定
AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中指定的表，参见标准化模板的"Support for Traceability"章节（[2]）。
应使用 [TPS_STDT_00053] 中指定的义务表达的口头形式来表示需求，参见标准化模板的"Support for Traceability"章节（[2]）。
### 1.4 缩写
| 缩写 | 含义 |
|---|---|
| **ASIL** | Automotive Safety Integrity Level（汽车安全完整性等级） |
| **DC** | Diagnostic Coverage（诊断覆盖率） |
| **ECC** | Error Correction Code（纠错码） |
| **EDC** | Error Detection Code（错误检测码） |
| **HARA** | Hazard Analysis and Risk Assessment（危险分析与风险评估） |
| **HW** | Hardware（硬件） |
| **FSC** | Functional Safety Concept（功能安全概念） |
| **TSC** | Technical Safety Concept（技术安全概念） |
| **SEooC** | Safety Element out of Context（上下文外安全元素） |
| **SM** | Safety Mechanism or Measure（安全机制或措施） |
| **SW** | Software（软件） |
| **SWC** | Software Component（软件组件） |
| **URI** | Uniform Resource Identifier（统一资源标识符） |
| **URL** | Uniform Resource Locator（统一资源定位符） |
**表 1.1**：缩写
### 1.5 术语词汇表
通常，本文档将使用 ISO 26262-1 词汇（参见 [3]）中定义的安全相关术语。为便于说明，表 1.2 列出了一些与 AUTOSAR 相关的术语及其定义。
| 术语 | 定义 |
|---|---|
| **ASIL 属性** | 系统元素的 ASIL 指定了为避免不合理的残余风险而需要应用的 ISO 26262 必要需求和安全措施。详见第 5 节。 |
| **故障、失效、错误** | 故障（Fault）是一种异常状况，可能导致硬件或软件元素失效。错误（Error）描述了值或条件中产生的偏差，是（一组）故障的结果。失效（Failure）定义了硬件或软件元素执行其功能的能力的终止（参见 [3]）。故障包括系统性软件故障（即"缺陷"、"Bug"）、随机硬件故障（例如由于设备的应力 / 老化）以及系统性硬件故障。 |
| **安全状态** | 安全状态总是在系统级别描述（参见 [3]）。某个软件状态可能是此"系统状态"的一部分，或者这种关系未定义（例如，如果运行软件的微控制器在安全状态下被关闭）。 |
| **安全机制** | 安全机制是一种技术解决方案 [...]，用于检测故障或控制失效以实现或维持安全状态（参见 [3]）。本规范中使用的术语正是这种更广泛的含义，因此不仅 AUTOSAR 安全机制（"安全特性"）可以被描述，而且系统的任何 HW/SW 或组合解决方案都可以被描述，因为 AUTOSAR 软件是为这些解决方案实现的（参见第 7 节）。 |
| **安全措施** | 安全措施是避免系统性失效以及检测随机硬件失效或控制失效的活动或解决方案（参见 [3]）。因此，安全措施可能仅定义一个过程活动，例如专用测试方法、附加的代码验证等（参见第 7 节）。本规范将使用术语"安全措施"来概括开发期间的活动以及实施到系统中的安全措施。 |
| **安全需求** | ISO 26262 定义了安全需求的层次结构：安全目标、技术、硬件和软件。在本文档中，安全需求可以是其中任何一种。有关详细信息，请参考 ISO 26262-3、4 和 9。 |
**表 1.2**：术语词汇表
### 1.6 指南
应引用现有的规范（以单一需求的形式）。与这些规范的差异被指定为附加需求。所有需求应具有以下属性：
- **冗余性（Redundancy）**：需求不应在一个需求内或其他需求中重复。
- **清晰性（Clearness）**：所有需求应仅允许一种解释的可能性。使用的未在词汇表中的技术术语必须定义。
- **原子性（Atomicity）**：每个需求应仅包含一个需求。如果需求不能进一步拆分为更多需求，则该需求是原子的。
- **可测试性（Testability）**：需求应通过分析、评审或测试进行测试。
- **可追溯性（Traceability）**：在任何时候都应可见需求的来源和状态。
---
## 2 需求追踪
下表引用 [1] 中指定的需求，并将其链接到这些需求的实现。
| 需求 | 描述 | 由以下需求满足 |
|---|---|---|
| `[RS_SAFEX_00001]` | AUTOSAR 模型中可表达的安全需求 | `[TPS_SAFEX_00101]` |
| `[RS_SAFEX_00002]` | 安全需求至少与其他需求一样具有表达力 | `[TPS_SAFEX_00101]` |
| `[RS_SAFEX_00003]` | 通过 URI 描述的安全需求 | `[TPS_SAFEX_00105]` |
| `[RS_SAFEX_00004]` | 可区分的安全需求 | `[TPS_SAFEX_00102]` |
| `[RS_SAFEX_00005]` | 安全需求的唯一标识 | `[TPS_SAFEX_00103]` |
| `[RS_SAFEX_00006]` | 安全需求的状态信息 | `[TPS_SAFEX_00104]` |
| `[RS_SAFEX_00007]` | 安全需求的层次结构 | `[TPS_SAFEX_00301]` |
| `[RS_SAFEX_00008]` | 安全需求的分解 | `[TPS_SAFEX_00302]` |
| `[RS_SAFEX_00009]` | 独立性需求的规范 | `[TPS_SAFEX_00303]` |
| `[RS_SAFEX_00010]` | 安全需求的 ASIL 属性 | `[TPS_SAFEX_00201]` |
| `[RS_SAFEX_00011]` | AUTOSAR 元素的 ASIL 属性 | `[TPS_SAFEX_00202]` |
| `[RS_SAFEX_00012]` | 安全需求的可追溯性 | `[TPS_SAFEX_00101]` |
| `[RS_SAFEX_00013]` | 安全措施的可追溯性 | `[TPS_SAFEX_00401]` |
| `[RS_SAFEX_00014]` | 安全需求的分配 | `[TPS_SAFEX_00306]`、`[TPS_SAFEX_00308]` |
| `[RS_SAFEX_00015]` | AUTOSAR 模型中可表达的安全措施 | `[TPS_SAFEX_00401]` |
| `[RS_SAFEX_00016]` | 安全措施的文本描述 | `[TPS_SAFEX_00401]` |
| `[RS_SAFEX_00017]` | 安全措施的唯一标识 | `[TPS_SAFEX_00402]` |
| `[RS_SAFEX_00018]` | 安全需求与安全措施之间的关系 | `[TPS_SAFEX_00307]` |
| `[RS_SAFEX_00022]` | 安全措施的分配 | `[TPS_SAFEX_00305]`、`[TPS_SAFEX_00309]` |
| `[RS_SAFEX_00023]` | 作为特殊安全措施的安全机制 | `[TPS_SAFEX_00401]` |
---
## 3 安全扩展概述
安全是汽车系统设计和开发中的关键问题之一。ISO 26262 [3] 定义了功能安全的当前标准，影响几乎所有的开发活动，包括软件规范、设计和实现。本文档支持在 AUTOSAR 上下文中标准化交换此类安全信息，并为 ISO 26262 要求的一致管理提供基础。
AUTOSAR 标准已经通过提供许多可用于实现安全软件的功能来解决功能安全问题，例如端到端保护、程序流监控、内存分区、用户 / 监督模式等（参见 [?, ] 以获取概述）。这些安全机制被视为 AUTOSAR 系统设计的组成部分。然而，ISO 26262 对功能安全软件开发的其他要求需要解决，特别是以下几点：
- **安全需求** —— 与其他需求明确区分开来，并满足 ISO 26262 第 4 和 8 部分规定的要求（第 4 节）。
- **安全完整性等级** —— 对于每个 AUTOSAR 元素，遵循 ISO 26262-3 的模式（第 5 节）。
- **根据 ISO 26262-9 中给出的需求分解安全需求**（第 6 节）。
- **根据 ISO 26262 第 4、6 和 8 部分追溯和分配安全需求和安全措施**（第 6 节）。
- **ISO 26262-4 要求的安全措施和安全机制**（第 7 节）。这超出了 AUTOSAR 中存在的纯 SW 安全机制，并引入了一种抽象方式来引用系统架构的任何安全措施。
本规范遵循重用 AUTOSAR 可用文档功能的方法来解决这些需求。这意味着安全扩展定义了规则，通过使用现有的元模型概念（例如 `StructuredReq`、`TraceableText`、`trace`）来交换上述工作产品。因此，AUTOSAR 规范保持向后兼容，并且可以同时包含用于安全 SWC 开发和配置的统一的、工具可处理的安全信息（参见 RS-SafetyExtensions 需求 `[RS_SAFEX_00020]` 和 `[RS_SAFEX_00021]`）。
系统的安全需求层次结构（ISO 26262 中的项目开发）及其与 AUTOSAR 软件架构的关系如图 3.1 所示。安全需求的层次结构从为系统的危险 / 危险事件识别的安全目标开始。ASIL 作为属性在每个安全目标处维护，并通过后续级别的功能安全需求（作为 FSC 的一部分）和技术安全需求（作为 TSC 的一部分）一致地继承。后者将细化为 SW 和 HW 安全需求。
每个安全需求 1 必须正确分配给系统架构的元素，即组件、HW、SW 或两者（HW 和 SW）。因此，AUTOSAR 规范的元素可能会收到一个 ASIL，表明它处于 ISO 26262 开发的范围内。
> 1 功能安全需求被分配给更高级别的功能 / 逻辑架构。
**图 3.1**：安全需求的层次结构及其到系统架构元素的分配
在安全需求不可用或不会与规范一起交换的情况下，AUTOSAR 实现必须至少意识到该元素在安全上下文中使用。这是通过将 ASIL 属性附加到独立于分配的 AUTOSAR 元素来实现的。特别是在 SEooC 开发的情况下，即安全需求在开发时不完全已知，ASIL 属性通过将假设与最终确定的安全需求进行匹配来支持后续开发阶段此类部分的集成和验证。
从 AUTOSAR 元素的角度来看，分配的安全需求的实现通常依赖于系统上下文。例如，SWC 的实现者应知道底层处理器架构是否支持内存保护（例如通过 ECC / EDC / MMU / MPU），以便正确实现安全相关数据的处理。特别是安全需求到架构其他元素的分解和分配 —— 以及支持部件的约束和特征 —— 需要在开发时已知。对于大多数错误检测和错误处理、降级或时序方面，情况通常如此。例如，图 3.1 中的系统摘录表明外部 HW 看门狗的可用性，它可能是错误处理程序（例如截止时间或输出监控）中的支持元素。示例应用软件可能依赖于这种安全机制来处理组件本身无法检测的某些故障。
为了传递与 AUTOSAR 软件的开发、集成和配置相关的"安全上下文"相关信息，本规范除安全需求外，还提供了安全措施或安全机制的抽象。图 3.2 显示了软件堆栈和 / 或 ECU 硬件中可用不同安全机制的抽象概念。
**图 3.2**：安全措施、安全需求及其到架构元素的分配
如图所示，（分解的）安全需求首先映射到安全机制的抽象定义（此处：SM_E2E）。在后续步骤中，安全机制被分配给 AUTOSAR 模型的某些元素。如果安全机制代表任何其他技术，则此分配仅是隐式的（不属于 AUTOSAR）。这允许例如系统集成商验证分解中的免干扰是否在不同技术之间充分实现。请注意，此抽象也是有用的，例如，如果 AUTOSAR（实现）元素在 OEM 供应商之间的分布式工作中尚不可用，但系统工程师已经希望确定哪些方面以何种方式受到安全措施的保护。
定义安全需求或安全措施、分配安全需求等各个活动在 AUTOSAR 方法论中描述（参见 [4]）。因此，该方法论形式上满足了 [1] 中的需求 `[RS_SAFEX_00024]`。
---
## 4 安全需求
本章定义如何将安全需求映射到 AUTOSAR 概念。基本上，安全需求遵循与正常需求相同的基本原理，但必须满足附加条件以符合 ISO 26262 需求（参见 [3] 第 8 部分第 6.4.2 条）。这主要包括在 AUTOSAR 中以以下方式处理的附加属性和特征：
- **安全需求应被明确标识为安全需求**（参见 ISO 26262-8，第 6.4.2.1 条）。为此，需求通过由 `StructuredReq` 继承的 `category` 属性进行标记。
- **应提供安全需求到（软件）架构元素的分配信息**（参见 ISO 26262-8，第 6.4.2.3 条）。安全需求通过 `trace` 映射到 AUTOSAR 架构的任何对象。
- **安全需求应具有唯一标识**（ISO 26262-8，第 6.4.2.5.a 条），该标识在需求的整个生命周期中保持不变。本规范将对安全需求的 `shortName` 使用提出附加需求。
- **安全需求应具有状态属性**（ISO 26262-8，第 6.4.2.5.b 条）。状态属性不同于为需求定义的 AUTOSAR 生命周期信息，因此它映射到 `Sdg` 属性。
- **安全需求应具有 ASIL**（ISO 26262-8，第 6.4.2.5.c 条）。ASIL 属性映射到 `Sdg` 属性。
- **安全需求应沿设计级别按层次结构构建**，每个应维护对层次结构上一级的源的引用（ISO 26262-8，第 6.4.3.1 条和第 6.4.3.2 条）。由于 AUTOSAR 允许将需求追溯为 `TraceableText`，因此不需要扩展来表达这些层次依赖性。
- **如果应用 ASIL 分解**，则分解必须遵循 ISO 26262-9 第 5 条中定义的许多规则。本规范引入了一种特殊的 trace 类型，支持在每个安全需求上单独应用 ASIL 分解的概念。此外，ASIL 分解符号在 ASIL 属性中得到支持，例如 ASIL B(D)。
> **[TPS_SAFEX_00101]** 安全需求的描述 ⌈安全需求应使用 `[TPS_STDT_00060]` 中定义的 `StructuredReq` 作为正常需求进行描述。描述应包含需求的内容。⌋
> c(`RS_SAFEX_00001`、`RS_SAFEX_00002`、`RS_SAFEX_00012`)
请注意，这无缝集成在 AUTOSAR 规范定义的文本可追溯性中。
> **[TPS_SAFEX_00103]** 安全需求的唯一标识符 ⌈安全需求应在 AUTOSAR 项目的范围内收到一个唯一 ID。该 ID 应作为 `shortName` 维护，以供进一步引用该需求，并对应于一般规则 `[TPS_GST_00021]`。⌋
> c(`RS_SAFEX_00005`)
请注意，安全需求标识符因此比 `[constr_2508]` 定义的正常短名称更严格。`shortName` 用作全局唯一 ID，类似于 [constr_2538] 中描述的其他元素的唯一性。此外，处理安全扩展的工具可以利用 `uuid` 属性来持久化工具相关的标识符。
> **[TPS_SAFEX_00102]** 安全需求的类型 ⌈安全需求应通过 `StructuredReq` 的 `category` 属性明确标记为安全需求，设置为以下之一：
> - `SAFETY_GOAL`
> - `SAFETY_FUNCTIONAL`
> - `SAFETY_TECHNICAL`
> - `SAFETY_SOFTWARE`
> - `SAFETY_HARDWARE`
> - `SAFETY_EXTERNAL`
>
> 这些值在安全上下文中扩展了 [2] 中 [constr_2540] 中定义的值。⌋
> c(`RS_SAFEX_00004`)
ASIL 属性在 `[TPS_SAFEX_00201]` 中定义。
> **[TPS_SAFEX_00104]** 状态属性 ⌈安全需求应作为包含 `Sdg` 数据字段（`gid="SAFEX"`）的 `AdminData` 接收状态属性。XML 内容应包含一个具有属性 `gid="STATUS"` 的 `Sd` 元素。⌋
> c(`RS_SAFEX_00006`)
状态属性的值未规定，是实现特定的。
出于各种原因，在 AUTOSAR 项目和 / 或一组 AUTOSAR XML 文档的范围内交换整个安全需求层次结构是不可行的。例如，对 HW 安全需求或安全目标的引用可能被有意排除，或者安全需求可能驻留在需求数据库中。为了支持链接此类驻留在 AUTOSAR 之外的安全需求，本规范引入了**外部安全需求**的概念。
> **[TPS_SAFEX_00105]** 外部安全需求 ⌈应作为引用包含在 AUTOSAR 文档中的外部安全需求应标记为 `category` 设置为 `SAFETY_EXTERNAL`，且描述应仅包含到安全需求所在位置的 Xfile URI。⌋
> c(`RS_SAFEX_00003`)
可选地，可以根据 `[TPS_SAFEX_00201]` 和 `[TPS_SAFEX_00104]` 中的定义设置（缓存）ASIL 和 / 或状态属性以及 `tool` 和 `toolVersion`，以方便使用。
下面的列表显示了安全需求如何在 AUTOSAR XML 中表达的示例（注：此列表包含从本文档后续章节中引入的规范项派生的元素）：
**列表 4.1**：AUTOSAR XML 中安全需求的表示
```xml
<!-- 技术安全需求 -->
<STRUCTURED-REQ>
<SHORT-NAME>SysSafReq05</SHORT-NAME>
<LONG-NAME>
<L-4 L="EN">CL15_ON light switch HW lib</L-4>
</LONG-NAME>
<CATEGORY>SAFETY_TECHNICAL</CATEGORY>
<ADMIN-DATA>
<SDGS>
<SDG GID="SAFEX">
<SD GID="ASIL">B</SD>
<SD GID="STATUS">PROPOSED</SD>
</SDG>
</SDGS>
</ADMIN-DATA>
<TRACE-REFS>
<!-- 到上一级层次结构的可追溯性链接（此处：功能安全需求） -->
<TRACE-REF DEST="STRUCTURED-REQ" BASE="SAFEX">FSR02</TRACE-REF>
</TRACE-REFS>
<TYPE>Valid</TYPE>
<DESCRIPTION>
<P>
<L-1 L="EN">当 CL15ON==1 时，FLM ECU 仅在 HW_LB==1 条件连续 20 ms 为真时才应关闭灯。（CAN 消息：CL15_01 CAN 信号：CL15ON 布尔值，'1' 表示 clamp 15 设置为 on，'0' 表示 clamp 15 设置为 off）</L-1>
</P>
</DESCRIPTION>
<RATIONALE />
<DEPENDENCIES />
<USE-CASE />
<SUPPORTING-MATERIAL />
</STRUCTURED-REQ>
<!-- 外部技术安全需求 -->
<STRUCTURED-REQ>
<SHORT-NAME>SysSafReq42</SHORT-NAME>
<LONG-NAME>
<L-4 L="EN"></L-4>
</LONG-NAME>
<CATEGORY>SAFETY_EXTERNAL</CATEGORY>
<ADMIN-DATA>
<SDGS>
<SDG GID="SAFEX">
<SD GID="ASIL">C</SD>
<SD GID="STATUS">ACCEPTED</SD>
</SDG>
</SDGS>
</ADMIN-DATA>
<TRACE-REFS>
<TRACE-REF DEST="STRUCTURED-REQ" BASE="SAFEX">FSR02</TRACE-REF>
</TRACE-REFS>
<TYPE>Valid</TYPE>
<DESCRIPTION>
<P>
<L-1 L="FOR-ALL">
<XFILE>
<SHORT-NAME>SysSafReq42</SHORT-NAME>
<URL>http://requirements.mycompany.com:6777/db/prj/safety/SysSafReq42</URL>
<TOOL>My Requirements Tool</TOOL>
<TOOL-VERSION>9.3.1</TOOL-VERSION>
</XFILE>
</L-1>
</P>
</DESCRIPTION>
<RATIONALE />
<DEPENDENCIES />
<USE-CASE />
<SUPPORTING-MATERIAL/>
</STRUCTURED-REQ>
```
---
## 5 安全完整性等级
本规范旨在支持 ISO 26262 [3] 的汽车安全完整性等级（ASIL）。其他安全完整性等级将不被考虑，并不在本文档的范围内。
ASIL 作为 ISO 26262-3 概念阶段中 HARA 的一部分确定，并分配给每个安全目标。系统设计 —— 最终是软件架构 —— 将通过安全需求到技术 / 软件架构的分配（参见第 3 节，详见第 6 节对安全需求的分配）将此 ASIL 作为属性继承。
> **[TPS_SAFEX_00201]** 安全需求的 ASIL 属性 ⌈根据第 4 节定义的安全需求应接收 ASIL 属性。ASIL 存储在包含 `Sdg` 数据（`gid="SAFEX"`）的 `AdminData` 中。此元素的内容应包含一个具有属性 `gid="ASIL"` 的 `Sd` 元素。此属性的有效值为：
> - `QM`
> - `A`
> - `B`
> - `C`
> - `D`
> - `QM(A)`
> - `QM(B)`
> - `QM(C)`
> - `QM(D)`
> - `A(B)`
> - `A(C)`
> - `A(D)`
> - `B(B)`
> - `B(C)`
> - `B(D)`
> - `C(C)`
> - `C(D)`
> - `D(D)`
> ⌋
> c(`RS_SAFEX_00010`)
请注意，括号表示法用于表示分解的安全需求。在本规范中，我们将原始 ASIL（即括号中的值）称为分解前的上下文 ASIL，因为它属于安全目标的上下文。
> **[constr_6200]** 安全目标没有分解的 ASIL ⌈如果安全需求的类型为 `SAFETY_GOAL`，则 ASIL 属性的有效值限制为：`QM`、`A`、`B`、`C` 或 `D`。⌋
> c()
> **[TPS_SAFEX_00202]** AUTOSAR 元素的 ASIL（可选） ⌈如果至少有一个安全需求被分配给某个 AUTOSAR 元素，则该元素应接收 ASIL 属性。ASIL 应作为 `Sdg` 数据（`gid="SAFEX"`）添加到 XML 的 `AdminData` 部分。XML 内容应包含一个具有属性 `gid="ASIL"` 的 `Sd` 元素，有效值与 `[TPS_SAFEX_00201]` 中相同。⌋
> c(`RS_SAFEX_00011`)
请注意，根据 `[TPS_SAFEX_00202]`，元素的 ASIL 是可选的。1 如果未在元素处指定 ASIL，则其语义是从所有已分配的安全需求中派生为最高 ASIL。
> 1 这在 SEooC 或延续开发中可能很有用，其中现有规范在实施后与安全需求连接。
> **[constr_6201]** ASIL 值的一致性 ⌈AUTOSAR 元素的 ASIL 和已分配的安全需求应一致。如果元素处的值等于或高于已分配安全需求的最大 ASIL，则 ASIL 是一致的。⌋
> c()
请注意，出于各种原因，AUTOSAR 元素的 ASIL 可能高于安全需求的 ASIL。例如，SWC 可能被设计用于在更高的安全完整性上下文中重用，因此被评级为更高的 ASIL。然而，对于分解的需求，上下文 ASIL 如何在 ASIL 值的比较中加以考虑是开放的解释。
有关安全需求处 ASIL 属性的示例，请参见列表 4.1。
**列表 5.1**：元素处 ASIL 属性的 AUTOSAR XML 表示示例
```xml
<!-- 具有 ASIL 的 AUTOSAR 元素示例 -->
<APPLICATION-SW-COMPONENT-TYPE>
<SHORT-NAME>MyComponent</SHORT-NAME>
<ADMIN-DATA>
<SDGS>
<SDG GID="SAFEX">
<SD GID="ASIL">B</SD>
</SDGS>
</ADMIN-DATA>
<PORTS>
[...]
```
---
## 6 安全需求的可追溯性与分配
ISO 26262 中安全需求的基本特征是追溯的管理和维护。本规范将安全需求的可追溯性称为（安全）需求与其他元素之间不同类型链接的通用术语。主要区分三种类型的 trace：
1. **两个安全需求级别之间的细化关系**，例如有助于功能安全需求的技术安全需求（参见 ISO 26262-8，第 6.4.3.1.a 条）。此概念类似于 AUTOSAR 规范本身的上游追溯，并将以相同的方式实现。
2. **从安全需求到软件架构元素的分配关系**，例如分配给 AUTOSAR SWC 端口的 SW 安全需求（参见 ISO 26262-8，第 6.4.2.3 条）。
3. **从安全需求到安全措施 / 机制的映射关系**，例如映射到端到端保护安全机制的 CRC 安全需求（参见 ISO 26262-4，第 6.4.1、6.4.2 和 6.4.6 条）。
请注意，安全需求的可追溯性不仅仅指当前 AUTOSAR 文档元模型中文本元素之间的引用（参见 `[TPS_GST_00243]`）。因此，不同的关系类型在 `AdminData` 块中使用 `Referrable` 引用（通过 `sdx` 元素）管理。
分解是细化关系的专门化，具有架构含义。安全需求的分解需要系统架构中存在两个独立的元素，对于这些元素可以保证免干扰。为了通过分解的安全需求向下追溯到软件，我们正在提高实现者的意识，并支持在集成测试期间验证相同的内容。
> **[TPS_SAFEX_00301]** 安全需求的细化关系 ⌈安全需求的细化关系应通过 trace 关联表达。trace 的方向具有语义"refines"。⌋
> c(`RS_SAFEX_00007`)
> **[TPS_SAFEX_00302]** 安全需求的分解 ⌈分解应在将安全需求分解为的两个分解需求中的每一个处指定。为此，这两个分解需求都应接收一个 `AdminData` 条目，其中包含一个名为 `gid="DECOMPOSITION"` 的 `Sdg` 元素，该元素具有对分解的安全需求的 `sdx`（即 `Referrable`）引用。⌋
> c(`RS_SAFEX_00008`)
> **[constr_6202]** 分解为两个安全需求 ⌈由 `[TPS_SAFEX_00302]` 指定的分解应针对每个分解需求恰好在两个分解安全需求（不多）处指定。⌋
> c()
> **[constr_6203]** 仅分解一个安全需求 ⌈根据 `[TPS_SAFEX_00302]` 指定的每个分解需求最多分解一个其他需求。⌋
> c()
> **[TPS_SAFEX_00303]** 独立性需求链接 ⌈如果安全需求表达了实现分解元素免干扰的手段，则它们应附加于分解需求，在两个分解安全需求处列出。因此，每个分解安全需求的 `AdminData` 在具有 `gid="INDEPENDENCE"` 的 `Sdg` 元素中接收一个单独的引用（`sdx` 条目）。⌋
> c(`RS_SAFEX_00009`)
请注意，分解的安全需求和独立性需求可以另外接收指向分解安全需求的"反向"trace。这样，整个可追溯性层次结构可以由不感知安全扩展的工具无缝导航。
> **[TPS_SAFEX_00306]** 安全需求到 AUTOSAR 元素的分配 ⌈安全需求到 AUTOSAR 元素的分配通过 `AdminData` 块中指向 AUTOSAR 元素的引用来表达。对于每个分配引用，应在名为 `gid="ALLOCATION"` 的组合 `Sdg` 元素中列出 `sdx` 引用。⌋
> c(`RS_SAFEX_00014`)
安全需求到 AUTOSAR 元素的直接分配的替代方案是首先映射到安全措施（如果适用），然后再映射到 AUTOSAR 元素。例如，确保安全通信的安全需求可以映射到安全机制"端到端保护"，而后者又被分配给端到端配置文件。
> **[TPS_SAFEX_00305]** 安全需求到安全措施的映射 ⌈安全需求到安全措施的分配应映射到具有名称 `gid="MAPS_TO"` 的 `Sdg` 元素（在 `AdminData` 块中）中的 `sdx` 引用，其中包含指向安全措施的 `sdx` 引用。⌋
> c(`RS_SAFEX_00022`)
作为完全等效的替代方案，安全机制可以包含指向其将实现的安全需求的反向链接：
> **[TPS_SAFEX_00309]** 映射关系的替代关系 ⌈映射关系应由从安全措施到安全需求的 trace 关联表达。trace 的方向具有语义"realizes"。⌋
> c(`RS_SAFEX_00022`)
> **[TPS_SAFEX_00307]** 安全措施到 AUTOSAR 元素的分配 ⌈安全措施到一个（或多个）AUTOSAR 元素的映射应在包含名为 `gid="ALLOCATION"` 的 `Sdg`（包含指向 AUTOSAR 元素的 `sdx` 引用）的 `AdminData` 中表达。⌋
> c(`RS_SAFEX_00018`)
从 AUTOSAR 元素的角度来看，分配链接具有"realizes"（或"satisfies"）语义：元素必须实现所有已分配的安全需求和定义的安全机制。因此，本规范通过 realizes 关系提供了这些关系的完全等效替代方案：1
> 1 这在（安全）需求规范已建立基线且不应更改的情况下可能很有用。
> **[TPS_SAFEX_00308]** AUTOSAR 元素的 realizes 关系 ⌈安全需求或安全措施的分配可以通过 realizes 引用表达。引用应作为 `Sdg` 数据添加到元素的 `AdminData` 部分，属性为 `gid="REALIZES"`。XML 内容应包含一个 `Sd` 元素，其中包含引用已分配安全需求的 `sdx` 引用列表。⌋
> c(`RS_SAFEX_00014`)
**列表 6.1**：realizes 关系的 AUTOSAR XML 表示示例
```xml
[...]
<AR-PACKAGE>
<SHORT-NAME>FLM_swc</SHORT-NAME>
<ELEMENTS>
<APPLICATION-SW-COMPONENT-TYPE>
<SHORT-NAME>FLM</SHORT-NAME>
<ADMIN-DATA>
<SDGS>
<SDG GID="ASIL">
<SD>B</SD>
</SDG>
<!-- 显示 <<realizes>> 关系的示例（参见 TPS_SAFEX_00308） -->
<SDG GID="REALIZES">
<SDX-REF DEST="STRUCTURED-REQ" BASE="SAFEX">ECU_TSR_03</SDX-REF>
</SDG>
</SDGS>
</ADMIN-DATA>
[...]
```
**列表 6.2**：各种 trace 关系的 AUTOSAR XML 表示
```xml
<!-- 被分解的安全需求 -->
<STRUCTURED-REQ>
<SHORT-NAME>ECU_TSR_01</SHORT-NAME>
<LONG-NAME>
<L-4 L="EN">确保 CAN 消息已接收</L-4>
</LONG-NAME>
<CATEGORY>SAFETY_TECHNICAL</CATEGORY>
<ADMIN-DATA>
<SDGS>
<SDG GID="SAFEX">
<SD GID="ASIL">B</SD>
<SD GID="STATUS">PROPOSED</SD>
</SDG>
</SDGS>
</ADMIN-DATA>
<TRACE-REFS>
<TRACE-REF DEST="STRUCTURED-REQ" BASE="SAFEX">SysSafReq05</TRACE-REF>
<TRACE-REF DEST="STRUCTURED-REQ" BASE="SAFEX">SysSafReq03</TRACE-REF>
<TRACE-REF DEST="STRUCTURED-REQ" BASE="SAFEX">SysSafReq47</TRACE-REF>
<!-- 可选的可追溯性链接 -->
</TRACE-REFS>
<TYPE>Valid</TYPE>
<DESCRIPTION>
<P>
<L-1 L="EN">CAN 消息 CAN BUS CAN_CL15 应被正确接收。</L-1>
</P>
</DESCRIPTION>
...
</STRUCTURED-REQ>
<!-- 第一个分解的技术安全需求 -->
<STRUCTURED-REQ>
<SHORT-NAME>ECU_TSR_03</SHORT-NAME>
<LONG-NAME>
<L-4 L="EN">确保正确的 CAN 总线消息转换</L-4>
</LONG-NAME>
<CATEGORY>SAFETY_TECHNICAL</CATEGORY>
<ADMIN-DATA>
<SDGS>
<SDG GID="SAFEX">
<SD GID="ASIL">QM(B)</SD>
<SD GID="STATUS">PROPOSED</SD>
</SDG>
<SDG GID="DECOMPOSITION">
<SDX-REF DEST="STRUCTURED-REQ" BASE="SAFEX">ECU_TSR_01</SDX-REF>
</SDG>
<SDG GID="INDEPENDENCE">
<SDX-REF DEST="STRUCTURED-REQ" BASE="SAFEX">ECU_TSR_047</SDX-REF>
</SDG>
<SDG GID="ALLOCATION">
<SDX-REF DEST="APPLICATION-SW-COMPONENT-TYPE" BASE="FLM_pkg">/FLM_pkg/FLM_swc/FLM</SDX-REF>
</SDG>
</SDGS>
</ADMIN-DATA>
...
</STRUCTURED-REQ>
<!-- 第二个分解的技术安全需求 -->
<STRUCTURED-REQ>
<SHORT-NAME>ECU_TSR_05</SHORT-NAME>
<LONG-NAME>
<L-4 L="EN">CL15_ON 故障检查</L-4>
</LONG-NAME>
<CATEGORY>SAFETY_TECHNICAL</CATEGORY>
<ADMIN-DATA>
<SDGS>
<SDG GID="SAFEX">
<SD GID="ASIL">B(B)</SD>
<SD GID="STATUS">PROPOSED</SD>
</SDG>
<SDG GID="DECOMPOSITION">
<SDX-REF DEST="STRUCTURED-REQ" BASE="SAFEX">ECU_TSR_01</SDX-REF>
</SDG>
<SDG GID="INDEPENDENCE">
<SDX-REF DEST="STRUCTURED-REQ" BASE="SAFEX">ECU_TSR_047</SDX-REF>
</SDG>
<SDG GID="MAPS_TO">
<SDX-REF DEST="TRACEABLE" BASE="SAFEX">SM_E2E</SDX-REF>
</SDG>
</SDGS>
</ADMIN-DATA>
...
</STRUCTURED-REQ>
<!-- 表达独立性的技术安全需求 -->
<STRUCTURED-REQ>
<SHORT-NAME>ECU_TSR_047</SHORT-NAME>
<LONG-NAME>
<L-4 L="EN">信号处理中的免干扰</L-4>
</LONG-NAME>
<CATEGORY>SAFETY_TECHNICAL</CATEGORY>
...
</STRUCTURED-REQ>
```
---
## 7 安全措施
系统的安全是通过在开发过程的各个阶段应用的安全措施以及在系统中通过多种技术实现的安全机制来实现的。本规范出于多种原因考虑了超出纯 AUTOSAR 软件堆栈范围的安全措施：
- **软件安全通常依赖于（外部）硬件机制来实现其安全完整性**，例如内存保护和分区、ECC / EDC、锁步模式、外部看门狗等。在实施过程中，这些上下文依赖性应明确成为任何软件的"运行时契约"的一部分，而不仅仅是隐式通信。
- **错误检测和错误处理通常涉及 SW 和 HW 之间复杂的交互**，从监控到中断和处理例程，再到执行器的关闭路径。因此，任何软件安全机制都应感知技术环境、系统级别的安全状态、潜在的故障和 HW 所隐含的约束。
- **软件集成需要验证安全机制的有效性**。如果软件规范说明了实现哪些安全机制或执行了哪些措施，则一致性检查和（半）自动验证成为可能，这反过来又减少了系统性失效。
- **最后，任何软件都受到运行它的 HW / 平台的影响**。理解和避免（系统性）失效只有在系统级别对安全机制的意图被记录、可访问并被实施者很好地理解的情况下才有可能。
AUTOSAR 已经提供了许多可用于实现安全软件的安全机制和功能，例如端到端保护、程序流监控、看门狗管理器等（参见 [?, ] 以获取概述）。这些功能可以用作 `[TPS_SAFEX_00305]` 映射的目标。请注意，除本节中的需求外，本规范不对文本描述施加任何约束。
> **[TPS_SAFEX_00401]** 安全措施或安全机制的定义 ⌈安全措施（或安全机制）应描述为 `TraceableText`。`category` 属性应使用 `SAFETY_MEASURE` 或 `SAFETY_MECHANISM` 标记文本块。⌋
> c(`RS_SAFEX_00013`、`RS_SAFEX_00015`、`RS_SAFEX_00016`、`RS_SAFEX_00023`)
> **[TPS_SAFEX_00402]** 安全措施的唯一标识符 ⌈安全措施 / 机制应作为 `shortName` 接收唯一标识符。该 ID 在 AUTOSAR 项目的范围内应是唯一的。⌋
> c(`RS_SAFEX_00017`)
**列表 7.1**：元素处 ASIL 属性的 AUTOSAR XML 表示示例
```xml
<!-- 安全机制示例 -->
<TRACE>
<SHORT-NAME>SM_E2E</SHORT-NAME>
<LONG-NAME>
<L-4 L="EN">信号 CL15ON 的端到端保护</L-4>
</LONG-NAME>
<CATEGORY>SAFETY_MECHANISM</CATEGORY>
<ADMIN-DATA>
<SDGS>
<SDG GID="ALLOCATION">
<SDX-REF DEST="END-TO-END-PROTECTION-SET" BASE="FLM_swc">/FLM_swc/FLM/MyEnd2EndProfile</SDX-REF>
</SDG>
</SDGS>
</ADMIN-DATA>
<P>
<L-1 L="EN">E2E 通信保护，使发送方能够保护数据，接收方能够在运行时检测错误并处理它们</L-1>
</P>
</TRACE>
```
---
## 8 应用说明
当前版本的本规范没有具体的应用说明。
---
## 附录 A 提到的类表
为完整起见，本章包含一组表示本文档上下文中提到的元类的类表，但不直接包含在描述特定元模型语义的范围内。
> **翻译说明**：本附录列出 11 个 AUTOSAR 元类表（`AdminData`、`Identifiable`、`Referrable`、`Sd`、`Sdg`、`SdgContents`、`StructuredReq`、`TraceReferrable`、`Traceable`、`TraceableText`、`Xfile`），包含每个类的属性定义。由于这些是标准 AUTOSAR 元模型参考表，本翻译仅翻译前 3 个表的概要信息；完整定义请参见原文 PDF 第 28-35 页。
### 表 A.1: `AdminData`
| 属性 | 类型 | 多重性 | 种类 | 说明 |
|---|---|---|---|---|
| `docRevision` | `DocRevision` | * | 聚合 | 表示有关对象当前修订的信息。 |
| `language` | `LEnum` | 0..1 | 属性 | 指定文档或文档片段的主语言。 |
| `sdg` | `Sdg` | * | 聚合 | 允许保留标准模型未表示的特殊数据。 |
| `usedLanguages` | `MultiLanguagePlainText` | 0..1 | 聚合 | 指定文档中提供的语言。 |
> **摘要标记**：附录 A 包含 11 个类表（`AdminData`、`Identifiable`、`Referrable`、`Sd`、`Sdg`、`SdgContents`、`StructuredReq`、`TraceReferrable`、`Traceable`、`TraceableText`、`Xfile`），每个类表描述标准 AUTOSAR 元模型参考类。本翻译仅翻译 `AdminData` 表的概要；其他类表的详细属性请参见原文 PDF 第 28-35 页。
---
## 翻译说明
- **翻译完整性**：本文档为 AUTOSAR 安全扩展模板规范（TPS）的中文翻译版本，完整翻译了 1-8 章及附录 A 的概要内容。
- **保留的英文术语**：所有规范项 ID（`TPS_SAFEX_xxxxx`、`RS_SAFEX_xxxxx`、`UC_SAFEX_xxxxx`、`constr_xxxx`）、AUTOSAR 元模型类名（`StructuredReq`、`TraceableText`、`AdminData`、`Identifiable`、`Referrable`、`Sdg`、`Sd`、`Xfile` 等）、属性名（`category`、`shortName`、`longName`、`trace`、`desc` 等）、ASIL 等级（QM、A、B、C、D 及其分解表示）、AUTOSAR 方框符 `⌈⌋` 均按要求保留为英文。
- **省略的内容**：免责声明（Disclaimer）按要求未翻译。
- **关键概念**：
- **安全扩展元模型概念**：使用 `Sdg`（Special Data Group）和 `Sd`（Special Data）属性来附加 ASIL、状态、分解、分配等安全信息。
- **安全需求类别**：`SAFETY_GOAL`、`SAFETY_FUNCTIONAL`、`SAFETY_TECHNICAL`、`SAFETY_SOFTWARE`、`SAFETY_HARDWARE`、`SAFETY_EXTERNAL`。
- **安全措施与安全机制**：使用 `SAFETY_MEASURE` 和 `SAFETY_MECHANISM` 类别标记。
- **ASIL 分解表示**：括号表示法，例如 ASIL B(D) 表示原始 ASIL 为 D，分解后为 B。
- **追溯关系类型**：`trace`（细化）、`DECOMPOSITION`（分解）、`INDEPENDENCE`（独立性）、`ALLOCATION`（分配）、`MAPS_TO`（映射到）、`REALIZES`（实现）。
- **附录摘要**：附录 A 列出 11 个 AUTOSAR 元类参考表，已翻译首张表，其余详见原文。
翻译进度.md
+78 -57
View File
@@ -10,12 +10,12 @@
| 项 | 数量 | 百分比 | | 项 | 数量 | 百分比 |
|---|---|---| |---|---|---|
| 总 PDF 数 | 216 | 100% | | 总 PDF 数 | 216 | 100% |
| **已完成** | **143** | **66.2%** | | **已完成** | **192** | **88.9%** |
| 部分完成 | 0 | 0% | | 部分完成 | 0 | 0% |
| 未开始 | 73 | 33.8% | | 未开始 | 24 | 11.1% |
| 跳过 | 0 | 0% | | 跳过 | 0 | 0% |
**P0 和 P1 阶段已全部完成**（143/216 PDF，~120,000 行译文） **P0、P1、P2 阶段已全部完成**（192/216 PDF，~156,000 行译文）
--- ---
@@ -40,12 +40,16 @@
| MCAL | 7 | 7 | ✅ 100% | | MCAL | 7 | 7 | ✅ 100% |
| **小计** | **94** | **94** | **✅ 100%** | | **小计** | **94** | **94** | **✅ 100%** |
### 🟠 P2 - 扩展 BSW（Step 5 待开始） ### ✅ P2 - 扩展 BSW（Step 5 完成）
- Memory（16）
- Safety（9） | 模块 | 计划 | 完成 | 状态 |
- Crypto（6） |------|------|------|------|
- ModeManagement（4） | Memory | 16 | 16 | ✅ 100% |
- IO（14） | Safety | 9 | 9 | ✅ 100% |
| Crypto | 6 | 6 | ✅ 100% |
| ModeManagement | 4 | 4 | ✅ 100% |
| IO | 14 | 14 | ✅ 100% |
| **小计** | **49** | **49** | **✅ 100%** |
### 🔵 P3 - 高级主题（Step 6 待开始） ### 🔵 P3 - 高级主题（Step 6 待开始）
- RTE（2） - RTE（2）
@@ -59,48 +63,47 @@
--- ---
## P1 详细文件清单 ## P2 详细文件清单
### ✅ Communication（71/71） ### ✅ Memory（16/16）
**SRS 需求规范（17）**：AUTOSAR_SRS_CAN, AUTOSAR_SRS_LIN, AUTOSAR_SRS_FlexRay, AUTOSAR_SRS_Ethernet, AUTOSAR_SRS_COM, AUTOSAR_SRS_SAEJ1939, AUTOSAR_SRS_NetworkManagement, AUTOSAR_SRS_V2XCommunication, AUTOSAR_SRS_Gateway, AUTOSAR_SRS_SPIHandlerDriver, AUTOSAR_SRS_IPDUMultiplexer, AUTOSAR_SRS_SecureOnboardCommunication, AUTOSAR_SRS_Transformer, AUTOSAR_SRS_XCP, AUTOSAR_SRS_E2E, AUTOSAR_SRS_BusMirroring, AUTOSAR_SRS_TTCAN **SRS**：EEPROMDriver, FlashDriver, FlashTest, MemoryHWAbstractionLayer, MemoryServices, RAMTest
**ASWS 高级软件规范（1）**：AUTOSAR_ASWS_TransformerGeneral **SWS**：NVRAMManager (965行), MemoryMapping, RAMTest, FlashDriver, EEPROMDriver, EEPROMAbstraction, FlashEEPROMEmulation, FlashTest, MemoryAbstractionInterface
**SWS 软件规范（53）**： **EXP**：NVDataHandling
- CAN：CANInterface, CANStateManager, CANDriver, BusMirroring, CANNetworkManagement, CANTransportLayer, CANTransceiverDriver
- FlexRay：FlexRayInterface, FlexRayNetworkManagement, FlexRayISOTransportLayer, FlexRayDriver, FlexRayARTransportLayer, FlexRayTransceiverDriver, FlexRayStateManager
- Ethernet：TcpIp, SocketAdaptor, ServiceDiscovery, EthernetInterface, EthernetSwitchDriver, DiagnosticOverIP, EthernetDriver, EthernetStateManager, EthernetTransceiverDriver, WirelessEthernetDriver, WirelessEthernetTransceiverDriver
- LIN：LINInterface, LINDriver, LINStateManager, LINTransceiverDriver, LINNetworkManagement
- J1939：SAEJ1939RequestManager, SAEJ1939TransportLayer, SAEJ1939NetworkManagement
- PDU/Transformer：PDURouter, IPDUMultiplexer, COMBasedTransformer, E2ETransformer, SOMEIPTransformer, SOMEIPTransportProtocol
- COM：COM, LargeDataCOM
- TTCAN：TTCANInterface, TTCANDriver
- 网络管理：NetworkManagementInterface, UDPNetworkManagement
- V2X：V2XFacilities, V2XManagement, V2XGeoNetworking, V2XBasicTransport
- 其他：XCP, SPIHandlerDriver, DiagnosticLogAndTrace, SecureOnboardCommunication
### ✅ Diagnostics（3/3） ### ✅ Safety（9/9）
| 文档 | 行数 | 文件 | **SRS**：WatchdogDriver
|------|------|------|
| AUTOSAR_SWS_DiagnosticCommunicationManager | 1000+ | `Diagnostics/AUTOSAR_SWS_DiagnosticCommunicationManager.md` |
| AUTOSAR_SWS_DiagnosticEventManager | 12,097 | `Diagnostics/AUTOSAR_SWS_DiagnosticEventManager.md` |
| AUTOSAR_SWS_SAEJ1939DiagnosticCommunicationManager | 500+ | `Diagnostics/AUTOSAR_SWS_SAEJ1939DiagnosticCommunicationManager.md` |
### ✅ SystemServices（13/13） **SWS**：WatchdogManager (847行), WatchdogDriver, WatchdogInterface
**SRS**：OS, FreeRunningTimer, FunctionInhibitionManager, TimeService, HWTestManager **RS / TPS**：SafetyExtensions, TPS_SafetyExtensions
**SWS**：OS, COMManager, FunctionInhibitionManager, TimeService, DefaultErrorTracer, HWTestManager **EXP**：FunctionalSafetyMeasures (749行), SafetyUseCase (877行), AIOccupantAndPedestrianSafety
**TR**：TimingAnalysis, HWTestManagementIntegrationGuide ### ✅ Crypto（6/6）
### ✅ MCAL（7/7） **SRS**：CryptoStack (1158行)
**SRS**：SPALGeneral, CoreTest, GPTDriver, MCUDriver **SWS**：CryptoServiceManager (1303行, 202页), KeyManager (866行), CryptoDriver (1437行), CryptoInterface (1008行)
**SWS**：GPTDriver, CoreTest, MCUDriver **EXP**：UtilizationOfCryptoServices
### ✅ ModeManagement（4/4）
**SRS**：ModeManagement (803行)
**SWS**：ECUStateManager (1138行, 195页), BSWModeManager (1118行, 147页)
**EXP**：ModeManagementGuide (1457行, 70页)
### ✅ IO（14/14）
**SRS**：IOHWAbstraction, ICUDriver, ADCDriver, PWMDriver, OCUDriver, DIODriver, PortDriver
**SWS**：ADCDriver (905行, 129页), ICUDriver (916行, 108页), OCUDriver, PWMDriver, IOHardwareAbstraction, DIODriver, PortDriver
--- ---
@@ -110,27 +113,30 @@
|------|--------|---------|-------------| |------|--------|---------|-------------|
| Step 2 试点 | 1 | 328 | 328 | | Step 2 试点 | 1 | 328 | 328 |
| Step 3 P0 | 49 | ~49,000 | ~1,000 | | Step 3 P0 | 49 | ~49,000 | ~1,000 |
| **Step 4 P1** | **94** | **~71,000** | **~755** | | Step 4 P1 | 94 | ~71,000 | ~755 |
| **累计** | **143** | **~120,000** | **~840** | | **Step 5 P2** | **49** | **~36,000** | **~735** |
| **累计** | **192** | **~156,000** | **~810** |
### P1 详细分类 ### P2 详细分类
| 类型 | PDF 数 | 翻译行数 | 平均 | | 类型 | PDF 数 | 翻译行数 | 平均 |
|------|--------|---------|------| |------|--------|---------|------|
| SRS（需求规范） | 26 | ~13,000 | 500 | | SRS | 18 | ~6,500 | 360 |
| SWS（软件规范） | 60 | ~52,000 | 867 | | SWS | 22 | ~16,500 | 750 |
| ASWS（高级软件规范） | 1 | ~200 | 200 | | EXP | 5 | ~4,500 | 900 |
| TR（技术报告） | 2 | ~1,000 | 500 | | RS | 1 | ~200 | 200 |
| TPS | 1 | ~500 | 500 |
| TR | 0 | 0 | 0 |
--- ---
## 翻译方法总结 ## 翻译方法总结
### P1 特别处理 ### P2 特别处理
- **超大文档策略**：DCM（639页）、DEM（516页）、OS（276页）、TcpIp（211页）等采用"重点翻译 + 摘要"策略 - **超大型文档策略**：EcuM（195页）、CSM（202页）、BswM（147页）等采用"重点翻译 + 摘要"策略
- **核心 API 完整翻译**：所有模块的 Init/GetVersionInfo/MainFunction 等关键 API - **核心 API 完整翻译**：所有 `Init`、`GetVersionInfo`、`MainFunction`、`Read`、`Write`、`Encrypt`、`Decrypt`、`StartConversion` 等
- **协议特定术语**：CAN/LIN/FlexRay/Ethernet/SOME/IP/DoIP/J1939 等协议名严格保留 - **协议特定术语**：NvM/Fee/Ea、Adc/Icu/Port/Pwm、Crypto/Csm/KeyM、Wdg/WdgM、EcuM/BswM 等
- **UDS 服务 ID 保留**：`0x19`、`0x14`、`0x27` 等诊断服务标识 - **ASIL 等级保留**：`ASIL A/B/C/D` 和 `QM`
### 关键翻译规范 ### 关键翻译规范
1. AUTOSAR 方框符 `⌈⌋`（需求边界）完整保留 1. AUTOSAR 方框符 `⌈⌋`（需求边界）完整保留
@@ -142,13 +148,28 @@
--- ---
## 总体进度（累计）
| 阶段 | PDF | 完成 | 累计行数 |
|------|------|------|---------|
| P0 | 49 | ✅ 100% | ~49,000 |
| P1 | 94 | ✅ 100% | ~120,000 |
| P2 | 49 | ✅ 100% | ~156,000 |
| P3 | 0/24 | ⬜ 0% | - |
| **合计** | **192/216** | **88.9%** | **~156,000** |
---
## 下一步 ## 下一步
按计划进入 **Step 5：批量翻译 P2 模块**（~49 PDF）： 按计划进入 **Step 6：批量翻译 P3 模块**（~24 PDF）：
- Memory（16） - RTE（2）
- Safety（9） - Libraries（10）
- Crypto（6） - GlobalTime（4）
- ModeManagement（4） - HMI（1）
- IO（14） - Chassis（1）
- Powertrain（1）
- Tools（4）
- ReleaseDocumentation（2）
预计产出：~30,000-50,000 行译文。 预计产出：~15,000-20,000 行译文。