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

P1 batch translation: 94 PDFs (Communication + Diagnostics + SystemServices + MCAL)

Browse Source
This commit is contained in:
opencode-translator
2026-06-13 00:29:54 +08:00
parent 0d470d1f17
commit 6f293acbf7
95 changed files with 70811 additions and 83 deletions
Download Patch File Download Diff File Expand all files Collapse all files
MCAL/AUTOSAR_SRS_CoreTest.md
+758
View File
@@ -0,0 +1,758 @@
# AUTOSAR Core Test 需求规范
> **Requirements on Core Test**
> AUTOSAR CP Release 4.4.0
## 元信息
- **文档类别**：SRS（Software Requirements Specification，软件需求规范）
- **模块名称**：Core Test（内核测试)
- **关联层级**：MCAL（Microcontroller Abstraction Layer，微控制器抽象层)
- **AUTOSAR 版本**：Classic Platform 4.4.0
- **文档标识号**：258
## 文档标识
| 项 | 值 |
| --- | --- |
| Document Title | Requirements on Core Test |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 258 |
| Document Status | Final |
| Part of AUTOSAR Standard | Classic Platform |
| Part of Standard Release | 4.4.0 |
## 文档变更历史
| 日期 | 版本 | 变更方 | 变更说明 |
| --- | --- | --- | --- |
| 2017-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 | 编辑性修订;将 "RS_BSWAndRTEFeatures" 重命名为 "RS_Features" |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 正式更新文档模板;添加至特性的追溯性 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 澄清一个需求 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 新增前台测试的需求;澄清部分需求 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 首次发布 |
## 免责声明
> 本节为版权与法律声明,以英文形式发布,翻译时予以保留原文。详情请参考英文原版。
---
## 目录
1. [文档范围](#1-文档范围)
2. [使用的约定](#2-使用的约定)
3. [缩略语与缩写](#3-缩略语与缩写)
4. [功能概述](#4-功能概述)
- 4.1.1 [内核 Core 的定义](#411-内核-core-的定义)
- 4.1.2 [多核支持](#412-多核支持)
- 4.1.3 [架构先决条件](#413-架构先决条件)
5. [需求追溯](#5-需求追溯)
6. [需求规范](#6-需求规范)
- 6.1 [功能性需求](#61-功能性需求)
- 6.1.1 [配置](#611-配置)
- 6.1.2 [正常操作](#612-正常操作)
- 6.1.3 [初始化](#613-初始化)
- 6.1.4 [关机操作](#614-关机操作)
- 6.2 [非功能性需求](#62-非功能性需求)
7. [参考文献](#7-参考文献)
---
## 1 文档范围
本文档定义了 AUTOSAR 中 Core Test 规范的通用规则和需求。它应作为每个需求文档的基础。
已注意确保 Core test、RAM test 和 Flash test SRS 文档之间的一致性。
---
## 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"表示某项确实是可选的。一个供应商可以选择包含该项,因为特定市场需求或供应商认为它能够提升产品,而另一供应商可以省略相同的项。不包含特定可选项的实现 MUST 准备好与包含该选项的实现互操作(可能功能有所缩减)。同理,包含特定选项的实现 MUST 准备好与不包含该选项的实现互操作(当然,除了该选项所提供的特性之外)。
---
## 3 缩略语与缩写
| 缩写 | 描述 |
| --- | --- |
| CPU | Central Processing Unit(中央处理单元) |
| MPU | Memory Protection Unit(内存保护单元) |
| L1 | 1st level memory(一级内存) |
| L2 | 2nd level memory(二级内存) |
| MCU | Microcontroller Unit(微控制器单元) |
| BIST | Built in Self Test(内建自测试) |
| IRQ | Interrupt Request(中断请求) |
| Core | CPU 加上紧密相关的功能资源 |
| Atomic sequence / atomic part | 不可在任何时间中断的软件代码执行序列 |
| Partial test | 部分测试,定义为对一个或多个"硬件资源"的测试。(部分测试可被中断,因为它在后台模式中执行) |
| PCB | Printed Circuit Board(印刷电路板) |
| External device | 物理上的外部实体;例如第二个微控制器 |
| Resource | 执行唯一功能的内核内部单元(例如 IRQ 控制器) |
| Checksum / signature | 测试执行结果或测试执行的原子序列的数字表示 |
| Caller / calling entity | 调用者/调用实体位于较高的 AUTOSAR 或 ISO 层。它是 API 调用的用户。 |
| 术语 | 描述 |
| --- | --- |
| Background test | 后台测试由 SW-scheduler 周期性调用 |
| Foreground test | 前台测试由用户调用触发 |
| Golden (Ref.) Value | 用于比较的参考值(例如 Checksum/Signature) |
| Good Case | 执行完成且未报告错误 |
由于本文档是面向专业人员的专业文档,其余术语默认读者已知。
---
## 4 功能概述
本模块根据汽车规范描述了一个用于指定测试用例的 API 需求。它涵盖周期性测试以及启动测试。这旨在集成到整个安全概念中,并不能单独提供所需的诊断覆盖率。
测试可在后台或前台模式下运行:
- 在后台模式下,测试由调度器周期性调用,在当前作为内核测试一部分的原子序列完成时可被中断。一个完整测试可由多个测试内核实体功能的原子序列组成。该完整测试被拆分到许多原子测试部分中,以满足任务调度的实时操作系统需求。
- 在前台模式下,测试可用于测试整个内核功能或选定的块,例如在运行关键任务之前。
应允许取消后台模式并启动前台模式。不应可能同时执行两种模式。如果后台任务正在运行而请求前台任务,后台任务应在调用前台任务之前被取消(例如在原子序列结束时)。
完整测试由 2 个步骤组成:
1. 运行专用指令序列以激发门电路与触发器,并计算 checksum/signature 作为结果表示。
2. 提供已比较的 checksum/signature -或- 将计算的 checksum 与参考值("Golden reference value")比较并决定测试是否通过 -或- 存储计算的 checksum 并按需提供给外部调用者。
测试既可计算两个步骤并返回 pass/fail 状态,也可以仅计算 checksum 并向调用实体提供完成通知。这是为了在测试和监督概念的实现中允许更高的灵活性。
调用者也可以是运行在不同 CPU 上的软件组件,或外部设备。
本模块涵盖来自 WP Architecture "Functional Safety" 开发的 AUTOSAR 特性 [RS_Features] 的需求。"References" 章节给出了由 "MCAL" 标识的特性列表。
### 4.1.1 内核 Core 的定义
Core 被定义为中央处理单元 (CPU)、所有专用内存和总线接口 (TCM、L1、L2 cache、系统总线等) 以及所有专用支持功能 (例如中断控制器、调试等)。本文档中,"Core" 一词用于引用此定义。下面显示了一个非常通用的方框图。实现了多个通用 CPU 的内核应有多个内核测试实体。
```
Interrupt
Debug interface
controller
CPU
Tighty Coupled
Memory
Interface(s)
Instruction Data
Cache MPU Cache
System
Bus
Interface(s)
CORE
```
需求源自汽车标准。必须测试总线(包括仲裁、MMU/MPU、cache、紧密耦合内存、通用和专用寄存器、数字执行单元,包括地址生成和中断加异常处理)。
相应的测试已在汽车标准中列出。为汽车标准定义的测试技术提供 API,但边界扫描测试 boundary scan test 不在本文档范围内。
不涵盖永久监控技术或冗余硬件技术(例如 lock-step CPU)。如果存在且需要软件支持,它们可能必须由 MCAL 复杂驱动 complex drivers 处理。
注:Core test 仅启动诊断事件。它应用于在运行时检测静态硬件错误。瞬态故障和间歇性故障不包括在内,无法通过专用测试软件支持来检测。
注:Core test 将所有专用内存和总线接口 (TCM、L1、L2 cache、系统总线等) 以及所有专用支持功能 (例如中断控制器、调试等) 的错误报告给诊断事件管理器 (DEM)。对于内核内的 CPU (例如 ALU、Prefetch queue) - 仅可报告测试或测试原子部分的成功执行 ("Good case")。内核内 CPU 的错误情况不能可靠地报告给 DEM。DEM 的事件必须相应定义。结果/错误通过 DEM API (BSW, `Dem_SetEventStatus()`) 报告。
注:Core test 实现应专注于测试内核本身,不干扰应用程序本身的实现。但由于内核测试计算需求,应考虑一定的性能和时序开销。但是,这需要由相对于在较低层执行的 Core test 驱动的较高实体/层或 MCAL 内核测试驱动的任何调用者处理,因此超出驱动实现的范围。
### 4.1.2 多核支持
应可在硅片设备内核的每个相同实例上执行 Core test。Core test 本身和 API 由于位于较低 AUTOSAR 层的驱动事实,无需感知系统架构本身。
此外,Core test 无需感知整个系统架构中共存的内核数量,只专注于单个内核实体(即,如果有多内核,则用户应用必须为每个内核调度同一测试的多个实体)。
因此,'Multi-microcontroller' 和 'multi-core' 之间必须有明确的区别。由于驱动和驱动 API 的性质,Multi-Microcontroller 系统设计超出 Core test 及其驱动 API 的范围。
```
Interrupt Interrupt
Debug interface Debug interface
controller controller
Tighty Coupled Tighty Coupled
CPU Memory CPU Memory
Interface(s) Interface(s)
Instruction Data Instruction Data
Cache MPU Cache Cache MPU Cache
System System
Bus Bus
Interface(s) Interface(s)
CORE CORE
Peripheral & I/O Interfaces etc.
Microcontroller/ECU
```
总结来说,内核测试是一个本地 MCAL 驱动,因此它没有对系统架构设计、其他微控制器或上层服务的水平视图。
### 4.1.3 架构先决条件
#### 4.1.3.1 资源分配
AUTOSAR 上层中没有可用的资源管理实体(例如 ISO 7-layer model - 会话管理)。有必要临时从应用使用中释放本地内核资源(例如 IRQ controller),以避免运行时测试和应用之间的非预期行为和干扰。在执行内核测试之前,AUTOSAR 架构中没有可用的管理实体来主动处理此需求(Feb/2008,R3.0)。由于其位于较低 AUTOSAR 层的驱动状态,MCAL 驱动无法处理资源管理。ECU 状态管理器可能会被扩展以处理此问题,作为额外状态或模式。
#### 4.1.3.2 测试概念
如今 AUTOSAR 不支持运行时测试;因此在 AUTOSAR 上层没有可用的测试管理实体。由于 MCAL 驱动有意缺少直接访问在其他内核上执行的测试结果的能力(例如 Multi-microcontroller 系统),需要 AUTOSAR 上层架构中存在测试管理实体,以处理测试结果(本地、外部)及整体系统架构相关反应的处理。
#### 4.1.3.3 限制
由于 4.1.3.1 和 4.1.3.2,Core test 实现可能受限于在上电/启动期间执行,此时内核资源未在不同活动应用任务或实体之间共享(例如 IRQ-controller、DMA) -或者- 可能受限于测试运行时未共享的资源(例如 CPU 本身)。
---
## 5 需求追溯
| 上层需求 | 描述 | 由以下需求满足 |
| --- | --- | --- |
| RS_BRF_00129 | AUTOSAR 应支持数据损坏检测与保护 | SRS_CoreTst_14115, SRS_CoreTst_14116 |
| RS_BRF_01048 | AUTOSAR 模块设计应支持模块在多任务环境中协作 | SRS_CoreTst_14111, SRS_CoreTst_14130 |
| RS_BRF_01056 | AUTOSAR BSW 模块应提供标准化接口 | SRS_CoreTst_14112, SRS_CoreTst_14113, SRS_CoreTst_14131 |
| RS_BRF_01064 | AUTOSAR BSW 应提供回调函数以访问上层模块 | SRS_CoreTst_14119 |
| RS_BRF_01096 | AUTOSAR 应支持 ECU 启动与关机 | SRS_CoreTst_14134 |
| RS_BRF_01136 | AUTOSAR 应支持系统启动后解析的已配置 BSW 数据变体 | SRS_CoreTst_14101, SRS_CoreTst_14102 |
| RS_BRF_01232 | AUTOSAR OS 应支持应用软件的隔离和保护 | SRS_CoreTst_14123 |
| RS_BRF_01296 | AUTOSAR RTE 应支持并处理软件组件的单实例化和多实例化 | SRS_CoreTst_14133 |
| RS_BRF_01320 | AUTOSAR RTE 应调度 SWC 和 BSW 模块 | SRS_CoreTst_14114 |
| RS_BRF_01400 | AUTOSAR RTE 应提供可配置的测试钩子 | SRS_CoreTst_14114 |
| RS_BRF_01472 | AUTOSAR 应支持模式 | SRS_CoreTst_14123, SRS_CoreTst_14126, SRS_CoreTst_14133, SRS_CoreTst_14134 |
| RS_BRF_02024 | AUTOSAR 应提供机制以保护系统免受未授权使用 | SRS_CoreTst_14117 |
| RS_BRF_02160 | AUTOSAR 诊断应允许外部测试器控制 ECU 的活动功能 | SRS_CoreTst_14130 |
| RS_BRF_02168 | AUTOSAR 诊断应提供异常运行状况的集中分类与处理 | SRS_CoreTst_14117 |
| RS_BRF_02224 | AUTOSAR 应支持运行时硬件测试 | SRS_CoreTst_14104, SRS_CoreTst_14105, SRS_CoreTst_14106, SRS_CoreTst_14107, SRS_CoreTst_14108, SRS_CoreTst_14109, SRS_CoreTst_14110, SRS_CoreTst_14131, SRS_CoreTst_14134 |
---
## 6 需求规范
### 6.1 功能性需求
#### 6.1.1 配置
##### 6.1.1.1 [SRS_CoreTst_14101] Core Test 应可配置
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 需要测试的内核功能和要运行的原子测试应可配置。 |
| Rationale | 新内核在综合时高度可配置。Cache、MPU、Tightly Coupled Memories/Internal Memories 和其他功能是实现特定的且可选/可配置。测试需要反映最终执行测试的内核配置。 |
| Use Case | 复用同一测试软件以适应不同版本的内核并选择配置。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01136)
##### 6.1.1.2 [SRS_CoreTst_14102] 应支持链接时配置
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 要测试的内核功能和要运行的原子测试应在链接时通过目标库进行配置。 |
| Rationale | Core test 应作为目标库提供。无需运行时(post build)配置,因为内核功能是固定的且不依赖于软件变体和用例。 |
| Use Case | 复用同一测试软件以适应不同版本的内核并选择配置。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01136)
#### 6.1.2 正常操作
##### 6.1.2.1 [SRS_CoreTst_14104] 应可用 Core Register Test
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 应根据汽车标准支持测试。 |
| Rationale | 汽车标准要求测试所有关键 Core 组件。 |
| Use Case | 内核测试策略的一部分,用于检测内核故障。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02224)
##### 6.1.2.2 [SRS_CoreTst_14105] 应可用 Core Interrupt and Exception Detection Tests
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 应根据汽车标准支持测试。 |
| Rationale | 汽车标准要求测试所有关键 Core 组件。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02224)
##### 6.1.2.3 [SRS_CoreTst_14106] 应可用 Core ALU Test
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 应支持汽车标准建议的"包括标志寄存器的编码和执行"测试。 |
| Rationale | 汽车标准要求测试所有关键 Core 组件。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02224)
##### 6.1.2.4 [SRS_CoreTst_14107] 应可用 Core Address Generator Test
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 应支持汽车标准建议的"地址生成"测试。 |
| Rationale | 汽车标准要求测试所有关键 Core 组件。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02224)
##### 6.1.2.5 [SRS_CoreTst_14108] 应可用 Core Memory Interfaces Test
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 应支持汽车标准建议的总线测试。 |
| Rationale | 汽车标准要求测试所有关键 Core 组件。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02224)
##### 6.1.2.6 [SRS_CoreTst_14109] 应可用 Memory Management/Protection Unit (MMU/MPU) Test
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 应支持汽车标准建议的 MMU/MPU 测试。 |
| Rationale | 汽车标准要求测试所有关键 Core 组件。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02224)
##### 6.1.2.7 [SRS_CoreTst_14110] 应可用 Cache Controller Test
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 应支持汽车标准建议的总线测试。 |
| Rationale | 汽车标准要求测试所有关键 Core 组件。Cache 控制器虽然未被汽车标准明确涵盖,但是 Core 的标准组件。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02224)
##### 6.1.2.8 [SRS_CoreTst_14111] Core Test 应划分为原子序列
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | Core test 模块应划分为原子测试的序列。原子测试的执行时间和代码长度应尽可能短(实际可行范围内)。实现者应提供以周期数表示的运行时。 |
| Rationale | 为了不破坏内核测试的状态,它不能被中断和恢复,必须运行至至少一个单一原子序列的完成。为避免中断延迟超出可接受水平,内核的不同构建块应在单独的原子测试中分别测试。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01048)
##### 6.1.2.9 [SRS_CoreTst_14112] Core Test 服务应有单一 API
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 应有单一 API 按序调用原子 Core test。如有要求,实现者应说明序列和依赖关系。 |
| Rationale | 实施便利:多个测试的单一入口点(预期是最常见用法)。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01056)
##### 6.1.2.10 [SRS_CoreTst_14113] API 应有一个选择测试组件的参数
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 应有一个参数选择测试 core 的哪个组件。下列组件应可分别测试,例如:<br>- CPU 作为整体<br>- CPU 的外部和附属模块,例如 cache、MPU、interrupt controller 分别测试<br>可选择任何组合的测试,但至少应选择一个测试作为最低要求。 |
| Rationale | -- |
| Use Case | OS 可在重新初始化或模式变更前单独测试组件,或在启动阶段一次性运行所有可用的 Core 组件测试。 |
| Dependencies | SRS_CoreTst_14112 |
| Supporting Material | -- |
⌋(RS_BRF_01056)
##### 6.1.2.11 [SRS_CoreTst_14114] 应可用 Core Test 的主函数
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 应有 Core Test 的主处理函数(它与 C 语言表示中的 main() 函数调用含义不同)。通过主函数,可在不让应用处理 Core test 执行内部细节的情况下执行测试序列。 |
| Rationale | Core test 可被 BSW 调度器在后台模式中调用。 |
| Use Case | 周期性后台内核测试。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01400, RS_BRF_01320)
##### 6.1.2.12 [SRS_CoreTst_14115] 调用者应可获得测试指标
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 每个部分测试的 checksum 结果应存储在内部变量中。该变量保存最近一次结果供调用读取,未提供历史缓冲区。 |
| Rationale | 调用者将与 'golden value' 比较并决定测试是否通过。调用者可以是运行在被测试目标上的软件组件、独立的片上 CPU 或外部设备。 |
| Use Case | 拥有内核每部分的详细结果将允许在恢复机制实现中具有更高灵活性。例如,如果 MPU 被检测到故障,OS 可以运行在非保护模式;如果 cache 故障,系统可以以降低的性能和功能运行,等等。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_00129)
##### 6.1.2.13 [SRS_CoreTst_14116] 应提供返回 checksum/signature 作为测试结果的服务
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 测试首先计算 checksum/signature 作为测试结果表示。与 golden reference value 的比较以决定通过或失败,留给外部/较高实体。 |
| Rationale | 需要此服务,因为通过/失败标准的检查应由不同实体完成。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_00129)
##### 6.1.2.14 [SRS_CoreTst_14131] 应提供返回 Pass/Fail 状态表示作为测试结果的服务
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 测试首先计算一个算法以测试内核模块,然后将测试结果与 golden reference value 比较,以决定通过或失败。'pass' 或 'fail' 的表示值返回给调用实体。 |
| Rationale | 为较小的 ECU 系统提供不同的报告方法。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02224, RS_BRF_01056)
##### 6.1.2.15 [SRS_CoreTst_14117] 故障应作为生产错误处理
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | Core test 模块应向 DEM 报告内核内部检测到的故障,但 CPU 本身(例如 ALU、MAC、Registers 等)内部检测到的故障除外,这些故障不能可靠地报告。 |
| Rationale | 根据资源可用性对系统作出反应并重新配置。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02024, RS_BRF_02168)
##### 6.1.2.16 [SRS_CoreTst_14118] Core test 模块的结果应提供给用户
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | Core test 模块的结果应提供给用户。用户应有机会随时获得 Core test 的状态。这应实现为 get-status-interface,并应在编译时可配置。此函数应为可选。 |
| Rationale | 与 RAM test 的一致性。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
##### 6.1.2.17 [SRS_CoreTst_14119] 应提供完成通知
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 系统或调用者应被通知测试已运行至完成。 |
| Rationale | 参见第 5.1 节内核测试用法描述。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01064)
##### 6.1.2.18 [SRS_CoreTst_14126] 应可取消正在运行的测试
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 应可在当前原子序列完成后停止测试。 |
| Rationale | 由于运行模式变更而停止服务运行的需求。如果改变 ECU 模式,应可通过软件停止正在运行的 coretest。 |
| Use Case | 应允许取消后台模式并启动前台模式。不应可能同时执行两种模式。如果后台任务正在运行而请求前台任务,后台任务应在调用前台任务之前被取消(例如在原子序列结束时)。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01472)
##### 6.1.2.19 [SRS_CoreTst_14130] 破坏性测试应恢复被测实体的原始状态
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 内核测试应将被测实体的状态恢复到测试执行开始前的状态。 |
| Rationale | 在破坏性测试的情况下,内核测试期间值将被修改,这将与应用程序产生干扰。 |
| Use Case | 例如测试内核寄存器集或中断控制器配置。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01048, RS_BRF_02160)
##### 6.1.2.20 [SRS_CoreTst_14133] 每个 Core Test 时间间隔应有标识符
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 每个 Core Test 时间间隔应有一个标识符,该标识符应在后台模式下每次开始新测试间隔时递增。Core Test 间隔的此值应提供给上层。标识符的结束值应可配置。 |
| Rationale | 将测试结果或测试签名分配给测试间隔,以从较高软件层监视测试流。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01472, RS_BRF_01296)
##### 6.1.2.21 [SRS_CoreTst_14134] 应可用前台内核测试 (open)
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 应可用一个服务以在前台模式下测试内核实体。 |
| Rationale | 在启动阶段测试内核实体。在关键操作或内核模式变更之前测试内核实体。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_02224, RS_BRF_01472, RS_BRF_01096)
##### 6.1.2.22 [SRS_CoreTst_14128] Core Test 不应干扰应用程序 (rejected)
⌈
| 项 | 值 |
| --- | --- |
| Type | new |
| Description | 内核测试应独立于运行在内核上的应用程序实现。Core test 实现应专注于测试 Core 本身,不修改应用任务。由于内核测试计算工作和调度,应考虑对应用程序的时序影响。 |
| Rationale | 内核测试应对应用程序透明。由于非常特定的测试算法和复杂的内核结构,核心测试必须由内核设计者提供。 |
| Use Case | 在前台或后台模式下,运行时操作期间测试内核功能。 |
| Dependencies | SRS_CoreTst_14121, SRS_CoreTst_14123 |
| Supporting Material | -- |
⌋()
##### 6.1.2.23 [SRS_CoreTst_14129] 多微控制器支持 (rejected)
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 两个 ECU 互相监督,或由第三方外部决策单元监督。<br>如果在 ECU 上实现了多个内核,调用应用程序或调用 OS 应能够将内核测试分配给 ECU 内的某个内核。Core test 明确不进行内核分配。 |
| Rationale | 需要增强安全性和/或高数据吞吐量的应用。 |
| Use Case | 在运行时操作期间测试 ECU。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
##### 6.1.2.24 [SRS_CoreTst_14127] 测试应能从外部实体请求 checksum (rejected)
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 应请求在外部实体上执行的原子测试的 checksum 结果。该接收到的 checksum 应与内部处理的 checksum 比较。未为接收的 checksum 提供历史缓冲区。 |
| Rationale | 内核将比较接收到的 checksum 与自己最终的内核测试结果,因此可以决定自己的测试是否通过。外部 checksum 提供实体可以是运行在单独 CPU 上的软件组件、监视 MCU 或仅是外部存储设备。 |
| Use Case | WPII-1.3 "Multi-Microcontroller Support" 文档提出了一种灵活的架构方法,覆盖从简单看门狗到双核 MCU 架构的所有外部监视规模。 |
| Dependencies | -- |
| Supporting Material | WPII-1.3, "Multi-Microcontroller Support" 文档, V1.0, sept/26/2007 |
⌋()
#### 6.1.3 初始化
##### 6.1.3.1 [SRS_CoreTst_14103] 应可用 Core Test 的初始化函数 (rejected)
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 应根据汽车标准支持测试。<br>- 选择专用测试覆盖率级别<br>- 激活专用诊断硬件(如可用)<br>- 激活 Core 内部测试和诊断模式(如可用) |
| Rationale | 对于高覆盖率级别,可能需要硬件支持以达到相关测试覆盖率需求。需要 API 来初始化专用诊断硬件(如可用)。 |
| Use Case | |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
#### 6.1.4 关机操作
##### 6.1.4.1 [SRS_CoreTst_14120] 应可用 Core Test 的去初始化函数 (rejected)
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | - 停止专用诊断硬件(如可用)<br>- 禁用 Core 内部测试和诊断模式(如可用) |
| Rationale | 对于汽车标准,可能需要额外的硬件支持。需要 API 来复位专用诊断硬件。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
### 6.2 非功能性需求
#### 6.2.1 [SRS_CoreTst_14123] 要测试的共享资源应专门提供给测试
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 应有一种机制在多主系统中请求和释放共享资源。调用者必须处理共享资源的状态。在调用 API 之前保存/恢复状态不由测试本身处理,而是调用者的任务。 |
| Rationale | 在 Core 中,某些资源(例如紧密耦合的内存接口)与外部主控(例如 DMA)共享。这些共享资源需要为测试目的专门提供。然后,测试可以自由地操作它们,例如如果支持则更改为测试模式,等等,而不与应用程序的其余部分冲突。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01472, RS_BRF_01232)
#### 其他被拒绝的需求
##### [SRS_CoreTst_14121] 时序需求 (rejected)
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 内核测试软件的测试持续时间。 |
| Rationale | Core test 的运行时执行被识别为重要需求,因此将在开发阶段成为调试事件。最大执行时间不应超过,以避免与 OS 和/或应用软件冲突,以及 Core 性能需求。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
##### [SRS_CoreTst_14122] 应可用 DET 接口 (rejected)
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | Core test 应向 DET 提供接口,以在开发期间监视关键参数。 |
| Rationale | 关键参数(例如时序预算超出或测试进行中)应在开发期间监视。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
##### [SRS_CoreTst_14125] 诊断覆盖率 (rejected)
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 应证明 60%、90% 和 99% 的诊断覆盖率;诊断覆盖率指 Core。此外,还必须检测瞬态和间歇性错误。<br>在不支持专用附加 Core test 硬件的情况下,仅靠软件是否能实现 60% 以上的覆盖率级别值得怀疑;软件测试无法捕获 90% 和 99% 故障模型所要求的故障。 |
| Rationale | 汽车标准强制要求。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
##### [SRS_CoreTst_14124] Core test 的实现必须符合 IEC61508 (rejected)
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | Core test 的实现必须符合 IEC61508 软件需求以达到认证。这影响开发过程和编程技术。 |
| Rationale | IEC61508 强制要求。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | BRF 00001 - 00100 (ID) |
⌋()
注:在不支持专用附加 Core test 硬件的情况下,仅靠软件是否能达到足够的测试覆盖率级别值得怀疑;软件测试无法捕获通用故障模型(例如瞬态故障)所要求的所有故障。
---
## 7 参考文献
### 7.1 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_DEM] Specification of Diagnostic Event Manager, AUTOSAR_SWS_DiagnosticEventManager.pdf
- [SWS_BSW_ECU] Specification of ECU state manager, AUTOSAR_SWS_ECUStateManager.pdf
- [RS_Features] Requirements on AUTOSAR Features, AUTOSAR_RS_Features.pdf
- [TPS_STDT_0078] Standardization Template, AUTOSAR_TPS_StandardizationTemplate.pdf
### 7.2 相关标准与规范
ISO DIS 26262
---
## 翻译说明
- 本文档由 AUTOSAR CP 4.4.0 英文原文翻译。
- 模块缩写(CPU、MPU、MCU、MCAL、Core、DEM、DET、OS、BSW、RTE、SWC、ECU 等)保留原文。
- API 标识符、需求 ID(SRS_CoreTst_xxxxx、RS_BRF_xxxxx)保留原文。
- AUTOSAR 方括号符 `⌈ ⌋` 保留原貌,以保持需求结构的可追溯性。
- 版权声明保持英文原文。
- 跨文档引用以英文文件名形式保留。
- Core test 特定术语(原子序列、checksum、golden reference value 等)以双语形式呈现,保持英文以保留与代码 API 一致。
MCAL/AUTOSAR_SRS_GPTDriver.md
+476
View File
@@ -0,0 +1,476 @@
# AUTOSAR GPT 驱动需求规范
> **Requirements on GPT Driver**
> AUTOSAR CP Release 4.4.0
## 元信息
- **文档类别**：SRS（Software Requirements Specification，软件需求规范）
- **模块名称**：GPT Driver（General Purpose Timer Driver，通用定时器驱动)
- **关联层级**：MCAL（Microcontroller Abstraction Layer，微控制器抽象层）
- **AUTOSAR 版本**：Classic Platform 4.4.0
- **文档标识号**：187
## 文档标识
| 项 | 值 |
| --- | --- |
| Document Title | Requirements on GPT Driver |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 187 |
| 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 | 新的 RS feature 关联至 GPT Predef Timer 需求 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 编辑性修订 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 新增 GPT Predef Timer 功能需求 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 重做需求追溯 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 删除 BSW12460;修订法律免责声明 |
| 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-05-16 | 2.0 | AUTOSAR Administration | 作为独立文档发布。SRS SPAL V1.0.0 在 Release 2.0 时被拆分为 12 份独立文档。新增需求:[SRS_Gpt_13601] 唤醒功能;[SRS_Gpt_13602] 使能/禁用唤醒;[SRS_Gpt_13603] 唤醒模式选择服务 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 作为 SRS SPAL V1.0.0 的一部分首次发布 |
## 免责声明
> 本节为版权与法律声明,以英文形式发布,翻译时予以保留原文。详情请参考英文原版。
---
## 目录
1. [文档范围](#1-文档范围)
2. [如何阅读本文档](#2-如何阅读本文档)
- 2.1 [使用的约定](#21-使用的约定)
- 2.2 [需求结构](#22-需求结构)
3. [功能概述](#3-功能概述)
4. [缩略语与缩写](#4-缩略语与缩写)
5. [需求规范](#5-需求规范)
- 5.1 [功能性需求](#51-功能性需求)
- 5.1.1 [通用](#511-通用)
- 5.1.2 [配置](#512-配置)
- 5.1.3 [初始化](#513-初始化)
- 5.1.4 [正常操作](#514-正常操作)
- 5.1.5 [故障操作](#515-故障操作)
6. [需求追溯](#6-需求追溯)
7. [参考文献](#7-参考文献)
---
## 1 文档范围
本文档规定了 GPT Driver 模块的需求。
### 约束
基础软件模块需求规范的首要范围是不涉及安全相关的系统。因此,安全需求被赋予中等优先级。
---
## 2 如何阅读本文档
每个需求都有以前缀 "BSW"(代表"Basic Software")开头的唯一标识符。任何评审注释、备注或问题请引用此唯一 ID,而非章节或页码!
### 2.1 使用的约定
- AUTOSAR 文档中需求的表示形式遵循 [TPS_STDT_00078] 中规定的表格。
- 在需求中,以下特定语义被使用(摘自 IETF 的 Request for Comment 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"表示某项确实是可选的。一个供应商可以选择包含该项(因为特定市场需求或供应商认为它能提升产品),而另一供应商可以省略相同的项。不包含特定可选项的实现 MUST 准备好与包含该选项的实现互操作(可能功能有所缩减)。同理,包含特定选项的实现 MUST 准备好与不包含该选项的实现互操作(当然,除了该选项所提供的特性之外)。
### 2.2 需求结构
每个模块特定章节包含基础软件模块的简短功能描述。每章中同类型需求按以下标题分组(如适用):
**功能性需求**:
- 配置(模块中哪些元素需要可配置)
- 初始化
- 正常操作
- 关机操作
- 故障操作
- ...
**非功能性需求**:
- 时序需求
- 资源使用
- 易用性
- 给其他工作包的输出(例如 Description Templates、Tooling 等)
- ...
---
## 3 功能概述
GPT 驱动是 microcontroller abstraction layer (MCAL) 的一部分。它初始化并控制微控制器内部的 General Purpose Timer (GPT)。
GPT 驱动提供以下服务和配置参数:
- 启动与停止硬件定时器
- 获取定时器值
- 控制时间触发的中断通知
- 控制时间触发的唤醒中断
GPT 驱动能够提供精确而短期的时序。当 OS Alarm 服务的开销过大时,可以使用 GPT 驱动的单次/连续中断通知。
典型周期时间范围的示例为 50µs ... 5 ms。
定义了一些自由运行的递增计数器——即所谓的 GPT Predef Timers。这些定时器具有预定义的 tick 持续时间和预定义的位数(物理时间单位与范围)。GPT Predef Timers 被 Time Service 模块使用。
---
## 4 缩略语与缩写
具有局部范围的缩略语和缩写不包含在 AUTOSAR 术语表中。它们必须出现在本地术语表中。
| 缩写 | 描述 |
| --- | --- |
| CS | Chip select(片选) |
| DIO | Digital Input Output(数字输入输出) |
| ECU | Electric Control Unit(电子控制单元) |
| EOL | End Of Line(产线终点),常用于"EOL Programming"或"EOL Configuration" |
| ICU | Input Capture Unit(输入捕获单元) |
| MAL | 微控制器抽象层的旧称(已被 MCAL 取代,因为'MAL'在法语中意为'坏的') |
| 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 | Standard Peripheral Abstraction Layer(本工作组名称) |
| SFR | Special Function Register(专用功能寄存器) |
| RTE | Runtime environment(运行时环境) |
| WP | Work Package(工作包) |
| STD | Standard(标准) |
| REQ | Requirement(需求) |
| UNINIT | Uninitialized(未初始化) |
由于本文档是面向专业人员的专业文档,其余术语默认读者已知。
---
## 5 需求规范
### 5.1 功能性需求
#### 5.1.1 通用
##### 5.1.1.1 [SRS_Gpt_12328] GPT 驱动应对所有与 GPT 定时器通道相关的 API 服务使用时间单位 ticks
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应对所有与 GPT 定时器通道相关的 API 服务使用时间单位 ticks。 |
| Rationale | 物理时间单位与 ticks 之间的转换应是用户软件的一部分。 |
| Use Case | -- |
| Dependencies | [SRS_BSW_00343] 时间的规范与配置 |
| Supporting Material | -- |
⌋(RS_BRF_01904)
##### 5.1.1.2 [SRS_Gpt_13604] GPT 驱动应支持特殊的自由运行递增计数器(GPT Predef Timers)
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应支持具有预定义 tick 持续时间和预定义位数(物理时间单位与范围)的自由运行递增计数器(GPT Predef Timers)。GPT Predef Timers 的功能应与 GPT 定时器通道相关功能相分离。 |
| Rationale | GPT 驱动应为 Time Service 模块提供硬件时间基准。 |
| Use Case | 时间测量、基于时间的状态机、超时监督、忙等待。 |
| Dependencies | [SRS_BSW_00343] 时间的规范与配置 |
| Supporting Material | -- |
⌋(RS_BRF_01904, RS_BRF_01468)
##### 5.1.1.3 [SRS_Gpt_13605] GPT 驱动应支持不同类型的 GPT Predef Timers
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应支持下列类型的 GPT Predef Timers:<br>- Timer 1µs 16bit<br>- Timer 1µs 24bit<br>- Timer 1µs 32bit<br>- Timer 100µs 32bit |
| Rationale | 1µs:高分辨率定时器。<br>16bit timer:支持 16bit 硬件定时器。<br>24bit timer:支持 24bit 硬件定时器。<br>32bit timer:支持 32bit 硬件定时器。<br>100µs 32bit timer:覆盖汽车应用用例(时间跨度 4.9 天)。 |
| Use Case | 时间测量、基于时间的状态机、超时监督、忙等待。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01904, RS_BRF_01468)
#### 5.1.2 配置
##### 5.1.2.1 [SRS_Gpt_12404] 应可对每个定时器通道配置单次/连续模式
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应允许对每个定时器通道进行如下静态配置:<br>- One-Shot mode:定时器达到结束值后停止<br>- Continuous mode:定时器达到结束值后自动重启 |
| Rationale | 提供保证的最小延迟时间或保证的频率。 |
| Use Case | One-shot 模式:<br>步进电机控制,其中线圈驱动脉冲必须具有定义的最小持续时间。在输出信号设置后定时器重启。即使一个输出脉冲被延迟(例如由于中断禁用),下一个脉冲也不会过早出现。<br><br>Continuous 模式:<br>ADC 转换触发。ADC 以固定速率连续触发,无需重启定时器。<br>输入信号采样。输入信号以固定速率采样。 |
| Dependencies | -- |
| Supporting Material | BMW Specification MCAL V1.0a, REQ MAL30.1.5 |
⌋(RS_BRF_01904)
##### 5.1.2.2 [SRS_Gpt_12114] 每个定时器通道应可配置为使用不同的时钟源
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应使得每个定时器通道可在静态配置上使用不同的时钟源(如果硬件支持)。 |
| Rationale | 提供通用功能。 |
| Use Case | 时钟源在正常模式和省电模式下不同。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01904)
##### 5.1.2.3 [SRS_Gpt_13606] GPT 驱动应可对 GPT Predef Timers 的使能进行静态配置
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应使得能够静态配置哪些 GPT Predef Timers 已使能。 |
| Rationale | 当硬件原因无法支持时,可禁用 GPT Predef Timers。 |
| Use Case | 硬件不支持某一 GPT Predef Timer |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01904, RS_BRF_01468)
#### 5.1.3 初始化
##### 5.1.3.1 [SRS_Gpt_12116] GPT 驱动应提供将定时器通道去初始化为上电复位状态的功能
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应提供将定时器通道去初始化为上电复位状态的功能。 |
| Rationale | 在进行有效初始化之前,需将所有硬件寄存器重置为相同状态。否则,上电复位后的初始化与模式变更后的初始化代码会不同。 |
| Use Case | 在变更省电模式的内部时钟频率后,可能需要以有效的预分频值重新初始化定时器模块。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01904, RS_BRF_01056)
#### 5.1.4 正常操作
##### 5.1.4.1 [SRS_Gpt_12117] GPT 驱动应提供同步服务以读取每个定时器通道的当前定时器值
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应提供同步服务以读取每个定时器通道的当前定时器值。 |
| Rationale | -- |
| Use Case | 某些信号需要时间戳。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01904, RS_BRF_01056)
##### 5.1.4.2 [SRS_Gpt_12128] GPT 驱动应提供以特定参数启动定时器的服务
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应提供以以下参数启动定时器的服务:<br>- timer channel<br>- time period(通知发生前的 tick 数) |
| Rationale | 基本功能。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01904, RS_BRF_01056)
##### 5.1.4.3 [SRS_Gpt_12119] GPT 驱动应提供停止每个定时器通道的服务
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应提供停止每个定时器通道的服务。 |
| Rationale | 在没有控制的情况下,只要供电,定时器就会运行。 |
| Use Case | 必须在有效初始化或改变其值之前停止定时器,以避免与定时器值绑定的不期望活动。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01904, RS_BRF_01056)
##### 5.1.4.4 [SRS_Gpt_12120] GPT 驱动应为每个通道提供时间周期到期时调用的通知
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应为每个通道提供时间周期到期时调用的通知。此回调应可按通道静态配置。 |
| Rationale | 定时器通常会被关联连接。 |
| Use Case | 1. 某项功能需要时间已过的信息。<br>2. 同步用户函数的另一动作。 |
| Dependencies | [SRS_Gpt_12128] 启动定时器 |
| Supporting Material | -- |
⌋(RS_BRF_01904, RS_BRF_01064)
##### 5.1.4.5 [SRS_Gpt_12121] GPT 驱动应在运行时提供使能每通道通知函数调用的功能
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应提供在运行时使能每通道通知函数调用的功能。 |
| Rationale | 通知函数必须被显式声明。 |
| Use Case | 当定时器翻转时。翻转表示定时器达到最大值后从零重新开始,或达到预定义值后从零重新开始。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01904, RS_BRF_01056, RS_BRF_01064)
##### 5.1.4.6 [SRS_Gpt_12122] GPT 驱动应在运行时提供禁用每通道通知函数调用的功能
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应提供在运行时禁用每通道通知函数调用的功能。 |
| Rationale | 如果不禁用,只要定时器活动,通知就会保持活动。 |
| Use Case | 当定时器翻转时(参见使能通知)。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01904, RS_BRF_01056, RS_BRF_01064)
##### 5.1.4.7 [SRS_Gpt_13601] 当预定义的唤醒周期到期时,GPT 驱动应能够执行唤醒事件
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 当预定义的唤醒周期到期时,GPT 驱动应能够执行唤醒事件。此特性仅在硬件支持时可用。 |
| Rationale | 降低功耗 |
| Use Case | 闪烁的 LED。ECU 在闪烁间隙被置入睡眠模式,当 LED 应再次点亮时被唤醒。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01904, RS_BRF_01104)
##### 5.1.4.8 [SRS_Gpt_13602] GPT 驱动应提供使能/禁用单个定时器通道唤醒能力的服务
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应提供使能/禁用单个定时器通道唤醒能力的服务。该通道相关的通知应被使能/禁用。 |
| Rationale | 控制 MCU 的唤醒条件需要使能或禁用通知。 |
| Use Case | -- |
| Dependencies | [SRS_Gpt_13601] 唤醒功能 |
| Supporting Material | -- |
⌋(RS_BRF_01904, RS_BRF_01056, RS_BRF_01104)
##### 5.1.4.9 [SRS_Gpt_13603] GPT 驱动应提供选择唤醒模式的服务
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应提供选择唤醒模式的服务:<br>- Normal mode(必须支持)<br>- Wake-up mode<br><br>在 normal mode 下,所有按配置可用的通知均可用。<br>在 Wake-up mode 下,仅那些会引起具备唤醒能力通知的通知可用。<br>所有其他通知被禁用,且当事件发生时不得使 MCU 退出 reduced power mode 状态(例如 idle、halt)。 |
| Rationale | 允许使能/禁用所有 ECU 唤醒不必需的通知。 |
| Use Case | 在 ECU 进入降功耗模式期间,MCU 的所有通知应被禁用,而不必在此期间禁用唤醒源。否则唤醒事件可能丢失。 |
| Dependencies | [SRS_Gpt_13601] 唤醒功能 |
| Supporting Material | -- |
⌋(RS_BRF_01904, RS_BRF_01056, RS_BRF_01104, RS_BRF_01448, RS_BRF_01472)
##### 5.1.4.10 [SRS_Gpt_13607] GPT Predef Timers 应由 GPT 驱动自动启动/停止
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT Predef Timers 应由 GPT 驱动自动启动/停止。 |
| Rationale | 确保所有已使能的 GPT Predef Timers 尽可能持续运行(初始化/去初始化后、进入正常/睡眠模式后)。 |
| Use Case | 避免上层模块启动 GPT Predef Timers。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01904, RS_BRF_01468)
##### 5.1.4.11 [SRS_Gpt_13608] GPT 驱动应提供同步服务以读取每个 GPT Predef Timer 的当前定时器值
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | GPT 驱动应提供同步服务以读取每个 GPT Predef Timer 的当前定时器值。 |
| Rationale | 获取定时器值。 |
| Use Case | 时间测量、基于时间的状态机、超时监督、忙等待。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01904, RS_BRF_01056, RS_BRF_01468)
#### 5.1.5 故障操作
无。
---
## 6 需求追溯
| 上层需求 | 描述 | 由以下需求满足 |
| --- | --- | --- |
| RS_BRF_01056 | AUTOSAR BSW 模块应提供标准化接口 | SRS_Gpt_12116, SRS_Gpt_12117, SRS_Gpt_12119, SRS_Gpt_12121, SRS_Gpt_12122, SRS_Gpt_12128, SRS_Gpt_13602, SRS_Gpt_13603, SRS_Gpt_13608 |
| RS_BRF_01064 | AUTOSAR BSW 应提供回调函数以访问上层模块 | SRS_Gpt_12120, SRS_Gpt_12121, SRS_Gpt_12122 |
| RS_BRF_01104 | AUTOSAR 应支持 ECU 与总线的睡眠与唤醒 | SRS_Gpt_13601, SRS_Gpt_13602, SRS_Gpt_13603 |
| RS_BRF_01448 | AUTOSAR 服务应支持模式与状态管理 | SRS_Gpt_13603 |
| RS_BRF_01468 | AUTOSAR 服务应支持相对时间测量的时间服务 | SRS_Gpt_13604, SRS_Gpt_13605, SRS_Gpt_13606, SRS_Gpt_13607, SRS_Gpt_13608 |
| RS_BRF_01472 | AUTOSAR 应支持模式 | SRS_Gpt_13603 |
| RS_BRF_01904 | AUTOSAR 微控制器抽象应提供对硬件定时器的访问 | SRS_Gpt_12114, SRS_Gpt_12116, SRS_Gpt_12117, SRS_Gpt_12119, SRS_Gpt_12120, SRS_Gpt_12121, SRS_Gpt_12122, SRS_Gpt_12128, SRS_Gpt_12328, SRS_Gpt_12404, SRS_Gpt_13601, SRS_Gpt_13602, SRS_Gpt_13603, SRS_Gpt_13604, SRS_Gpt_13605, SRS_Gpt_13606, SRS_Gpt_13607, SRS_Gpt_13608 |
---
## 7 参考文献
### 7.1 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
- [TPS_STDT_0078] Software Standardization Template, AUTOSAR_TPS_StandardizationTemplate.pdf
---
## 翻译说明
- 本文档由 AUTOSAR CP 4.4.0 英文原文翻译。
- 模块缩写(GPT、MCAL、MCU、ECU、DIO、PORT、ADC、PWM、ICU、SPI、SPAL 等)保留原文。
- API 标识符、需求 ID(SRS_Gpt_xxxxx、RS_BRF_xxxxx、SRS_BSW_xxxxx)保留原文。
- AUTOSAR 方括号符 `⌈ ⌋` 保留原貌,以保持需求结构的可追溯性。
- 版权声明保持英文原文。
- 跨文档引用以英文文件名形式保留。
- GPT Predef Timer 在 AUTOSAR 中是特定的术语(预定义定时器),翻译时保留英文以便与规范保持一致。
MCAL/AUTOSAR_SRS_MCUDriver.md
+426
View File
@@ -0,0 +1,426 @@
# AUTOSAR MCU 驱动需求规范
> **Requirements on MCU Driver**
> AUTOSAR CP Release 4.4.0
## 元信息
- **文档类别**：SRS（Software Requirements Specification，软件需求规范）
- **模块名称**：MCU Driver（Microcontroller Unit Driver，微控制器单元驱动)
- **关联层级**：MCAL（Microcontroller Abstraction Layer，微控制器抽象层）
- **AUTOSAR 版本**：Classic Platform 4.4.0
- **文档标识号**：195
## 文档标识
| 项 | 值 |
| --- | --- |
| Document Title | Requirements on MCU Driver |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 195 |
| 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 | 新增"第 5 章 - 需求追溯",追溯至 AUTOSAR 特性;编辑性修订 |
| 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-09-30 | 3.1.5 | AUTOSAR Administration | 重新表述大量需求以使其原子化;插入 Debugging Concept;插入新的服务(API)以在复位后读取状态(同样影响 SRS R4.0);插入新的配置参数以使能/禁用 PLL API;引入新容器以发布 MCU 支持的所有不同 reset;修订法律免责声明 |
| 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 | 1.0.0 首次发布 |
## 免责声明
> 本节为版权与法律声明,以英文形式发布,翻译时予以保留原文。详情请参考英文原版。
---
## 目录
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.1.3 [故障操作](#613-故障操作)
- 6.1.4 [关机操作](#614-关机操作)
- 6.2 [备注](#62-备注)
7. [参考文献](#7-参考文献)
---
## 1 文档范围
本文档规定了 MCU Driver 模块的需求。
### 约束
基础软件模块需求规范的首要范围是不涉及安全相关的系统。因此,安全需求被赋予中等优先级。
---
## 2 如何阅读本文档
每个需求都有以前缀 "BSW"(代表"Basic Software")开头的唯一标识符。任何评审注释、备注或问题请引用此唯一 ID,而非章节或页码!
### 2.1 使用的约定
- AUTOSAR 文档中需求的表示形式遵循 [TPS_STDT_00078] 中规定的表格。
- 在需求中,使用以下特定语义。
本文档中的关键词 "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"表示某项确实是可选的。一个供应商可以选择包含该项,因为特定市场需求或供应商认为它能够提升产品,而另一供应商可以省略相同的项。不包含特定可选项的实现 MUST 准备好与包含该选项的实现互操作(可能功能有所缩减)。同理,包含特定选项的实现 MUST 准备好与不包含该选项的实现互操作(当然,除了该选项所提供的特性之外)。
### 2.2 需求结构
每个模块特定章节包含基础软件模块的简短功能描述。每章中同类型需求按以下标题分组(如适用):
**功能性需求**:
- 配置(模块中哪些元素需要可配置)
- 初始化
- 正常操作
- 关机操作
- 故障操作
- ...
**非功能性需求**:
- 时序需求
- 资源使用
- 易用性
- 给其他工作包的输出(例如 Description Templates、Tooling 等)
- ...
---
## 3 缩略语与缩写
具有局部范围的缩略语和缩写不包含在 AUTOSAR 术语表中。它们必须出现在本地术语表中。
| 缩写 | 描述 |
| --- | --- |
| CS | Chip select(片选) |
| DIO | Digital Input Output(数字输入输出) |
| ECU | Electric Control Unit(电子控制单元) |
| EOL | End Of Line(产线终点),常用于"EOL Programming"或"EOL Configuration" |
| ICU | Interrupt Capture Unit(中断捕获单元) |
| MAL | 微控制器抽象层的旧称(已被 MCAL 取代,因为'MAL'在法语中意为'坏的') |
| 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 | Standard Peripheral Abstraction Layer(本工作组名称) |
| SFR | Special Function Register(专用功能寄存器) |
| RTE | Runtime environment(运行时环境) |
| WP | Work Package(工作包) |
| STD | Standard(标准) |
| REQ | Requirement(需求) |
| UNINIT | Uninitialized(未初始化) |
由于本文档是面向专业人员的专业文档,其余术语默认读者已知。
---
## 4 功能概述
MCU 驱动 [Microcontroller Unit] 提供基本微控制器初始化、断电功能、复位以及其他 MCAL 软件模块所需的微控制器特定功能服务。除了启动代码之外,初始化服务允许灵活、面向应用的 MCU 初始化(见下图)。启动代码非常 MCU 特定。本文档中提供的启动代码描述仅供参考,意味着在标准化 MCU 初始化能够启动之前必须考虑的功能。
```
Reset
Not in scope of
AUTOSAR
STARTUP Code
Bootloader Not
Bootloader Needed
Needed
BOOTLOADER
Standardized in
MCU driver
AUTOSAR
additional initialization services
power down service
reset service
```
MCU 驱动直接访问微控制器硬件,位于 Microcontroller Abstraction Layer (MCAL) 中。
**MCU 驱动特性**:
- 描述当前未被其他 MCAL 模块涵盖的功能配置所需的设置,例如全局时钟设置
- 设置 PLL 和 MCU 时钟分配
- RAM 区段初始化服务
- 设置通用 SPAL 需求未涵盖的 MCU 相关配置控制位
- 激活 µC 降功耗模式
- 执行 µC 复位
- 从硬件获取复位原因
---
## 5 需求追溯
| 上层需求 | 描述 | 由以下需求满足 |
| --- | --- | --- |
| RS_BRF_00129 | AUTOSAR 应支持数据损坏检测与保护 | SRS_Mcu_13701 |
| RS_BRF_01064 | AUTOSAR BSW 应提供回调函数以访问上层模块 | SRS_Mcu_12394 |
| RS_BRF_01096 | AUTOSAR 应支持 ECU 启动与关机 | SRS_Mcu_12331, SRS_Mcu_12350 |
| RS_BRF_01184 | AUTOSAR 应支持不同的降级方法 | SRS_Mcu_12268, SRS_Mcu_12421 |
| RS_BRF_01856 | AUTOSAR 微控制器抽象应提供对内部 MCU 配置的访问 | SRS_Mcu_12000, SRS_Mcu_12207, SRS_Mcu_12208, SRS_Mcu_12215, SRS_Mcu_12277, SRS_Mcu_12336, SRS_Mcu_12392 |
| RS_BRF_02168 | AUTOSAR 诊断应提供异常运行状况的集中分类与处理 | SRS_Mcu_12394 |
---
## 6 需求规范
### 6.1 功能性需求
#### 6.1.1 配置与初始化
##### 6.1.1.1 [SRS_Mcu_12421] 低功耗模式配置
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 低功耗模式的配置设置完全是微控制器特定的。应可配置硬件支持且应用需要的不同模式。 |
| Rationale | 根据应用需求降低 MCU 功耗 |
| Use Case | -- |
| Dependencies | [SRS_Mcu_12268] MCU 电源管理控制 |
| Supporting Material | -- |
⌋(RS_BRF_01184)
##### 6.1.1.2 [SRS_Mcu_12350] MCU 驱动应允许对启动期间需要初始化的 RAM 段进行静态配置
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | MCU 驱动应允许对启动期间需要初始化的 RAM 段进行静态配置。 |
| Rationale | 允许定义哪些 RAM 段被初始化(清零),哪些不初始化。 |
| Use Case | 允许在复位后保留特定 RAM 段中的数据。 |
| Dependencies | [SRS_Mcu_12331] RAM 初始化 |
| Supporting Material | -- |
⌋(RS_BRF_01096)
##### 6.1.1.3 [SRS_Mcu_12331] MCU 驱动应提供初始化已配置 RAM 段内容的服务
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | MCU 驱动应提供初始化已配置 RAM 段内容的服务。未配置为初始化的 RAM 段不应被触及。 |
| Rationale | 在 ECU 启动后获得已定义的 RAM 内容。 |
| Use Case | 用于以已定义内容灵活初始化 RAM 段。ECU 状态管理器可在 ECU 启动期间决定是否需要某些 RAM 段的初始化(例如取决于 Reset reason)。 |
| Dependencies | [SRS_Mcu_12350] RAM 段配置 |
| Supporting Material | -- |
⌋(RS_BRF_01096)
##### 6.1.1.4 [SRS_Mcu_12392] MCU 驱动应提供独立查询微控制器中所有 PLL 锁定状态的服务
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | MCU 驱动应提供独立查询微控制器中所有 PLL 锁定状态的服务。<br><br>该服务应返回:<br>- Locked(已锁定)<br>- Un-Locked(未锁定)<br>- Unsupported(不支持) |
| Rationale | -- |
| Use Case | 了解微控制器中任一 PLL 的状态。 |
| Dependencies | [SRS_Mcu_12208] MCU 时钟的初始化 |
| Supporting Material | -- |
⌋(RS_BRF_01856)
##### 6.1.1.5 [SRS_Mcu_12336] MCU 驱动应提供激活 PLL 时钟向整个 MCU 分配的服务
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | MCU 驱动应提供激活 PLL 时钟向整个 MCU 分配的服务。如果 MCU 中的 PLL 模块提供独立的使能位以释放 PLL 时钟,则需要该服务。该服务应仅在相应 PLL 已锁定后执行。在支持的情况下,该服务应针对微控制器中所有 PLL 独立提供。 |
| Rationale | 某些微控制器具有多个 PLL。 |
| Use Case | 在 MCU 中使已锁定的 PLL 时钟生效。 |
| Dependencies | [SRS_Mcu_12208], [SRS_Mcu_12392] |
| Supporting Material | -- |
⌋(RS_BRF_01856)
##### 6.1.1.6 [SRS_Mcu_12207] MCU 驱动应配置时钟安全特性
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 如果硬件支持,MCU 驱动应配置时钟安全特性,例如:<br>- 晶体丢失检测使能/禁用<br>- 晶体时钟源丢失(limp home 模式)使能/禁用<br>- 错误检测时的通知使能/禁用 |
| Rationale | 一个例子是 limp 模式,在该模式下,晶体丢失会启用备用时钟源,以提供一种安全系统关闭机制。 |
| Use Case | 晶体丢失恢复和有序关闭 |
| Dependencies | [SRS_Mcu_12208] |
| Supporting Material | -- |
⌋(RS_BRF_01856)
##### 6.1.1.7 [SRS_Mcu_12208] MCU 驱动应提供初始化 MCU 时钟系统的服务
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | MCU 驱动应提供初始化 MCU 时钟系统的服务。这包括 PLL 因子的初始化、启动 PLL 锁定过程(如果选定)以及影响多个驱动的其他 MCU 特定时钟选项,例如时钟预分频器。<br>等待 PLL 锁定不是强制性的。 |
| Rationale | -- |
| Use Case | 例如,从 MCU 降功耗模式唤醒后,为 MCU 子系统设置适当的时钟速度。 |
| Dependencies | [SRS_Mcu_12392] 提供 PLL 的锁定状态 |
| Supporting Material | -- |
⌋(RS_BRF_01856)
#### 6.1.2 正常操作
##### 6.1.2.1 [SRS_Mcu_12000] MCU 驱动应提供查询标准化复位原因的服务
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | MCU 驱动应提供查询复位原因的服务。应区分以下标准化的复位原因(如果硬件支持):<br>- Power On Reset(默认返回值)<br>- External Hard Reset<br>- Internal Watchdog Timer Reset<br>- Other reset reasons |
| Rationale | 不同的复位原因可能在初始化阶段需要不同的动作。 |
| Use Case | 为 ECU 状态管理器提供信息(例如决定选择哪种启动序列)。 |
| Dependencies | -- |
| Supporting Material | 注:上述复位原因不要求在每个微控制器设备中都实现。如果微控制器无法区分多种复位原因,默认值应为 "Power On Reset"。 |
⌋(RS_BRF_01856)
##### 6.1.2.2 [SRS_Mcu_12215] MCU 驱动应提供查询原始复位状态的服务
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | MCU 驱动应提供查询复位原因的服务。该服务应返回完整、原始的 µC 特定复位信息。 |
| Rationale | ECU 完全启动后,可查询原始复位状态并作为复位信息存储到诊断错误存储器中。 |
| Use Case | 该信息应仅用于将复位信息存储到诊断错误存储器中。<br><br>Reset Types 示例:<br>- Power On Reset<br>- External Hard Reset<br>- Soft Reset<br>- Internal Watchdog Timer Reset<br>- Debug System Reset<br>- Reset caused by exception<br>- ... |
| Dependencies | -- |
| Supporting Material | 如果微控制器不提供复位状态寄存器,该服务应返回 0(零)。 |
⌋(RS_BRF_01856)
##### 6.1.2.3 [SRS_Mcu_12277] MCU 驱动应提供复位触发函数
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | MCU 驱动应使用微控制器硬件的特性提供复位触发函数。由于 MCU 提供不同类型的复位变体,复位触发的配置应在 MCU 驱动的配置结构中定义。<br>如果微控制器不支持通过软件触发复位的方法,则不应使用该函数。在这种情况下,上层负责使用其他应用特定的方法,例如切换 I/O 引脚以触发外部复位电路。 |
| Rationale | 在软件检测到特定未知系统状态时,强制微控制器硬件进行受控初始化。 |
| Use Case | 可在出现致命错误时触发,例如:<br>- 出现不可恢复的 µC 陷阱(例如总线错误陷阱)<br>- 软件状态机突然遇到未定义状态(例如由于 RAM 中的位错误)且无其他可能反应 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01856)
##### 6.1.2.4 [SRS_Mcu_13701] MCU 驱动应提供查询 RAM 状态的服务
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | MCU 驱动应提供查询 RAM 状态的服务。<br>应区分以下标准化的 RAM 状态(如果硬件支持):<br>- RAM state invalid [default]<br>- RAM state valid<br>如果硬件不支持此特性,则该函数应被禁用。 |
| Rationale | 不同的 RAM 状态可能在初始化阶段需要不同的动作。 |
| Use Case | ECU 状态管理器可使用该信息在复位后重新加载 RAM 内容。 |
| Dependencies | -- |
| Supporting Material | 注:上述 RAM 状态不要求在每个微控制器设备中都实现。如果微控制器无法区分多种 RAM 状态,默认值应为 "RAM invalid"。 |
⌋(RS_BRF_00129)
#### 6.1.3 故障操作
##### 6.1.3.1 [SRS_Mcu_12394] MCU 驱动应提供时钟源故障的通知
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | MCU 驱动应提供通知,以便在 MCU 中时钟生成发生故障时报告时钟源的故障情况。如果 MCU 能够检测到此类故障,应提供该通知。由于 Diagnostic Event Manager 将对接该函数,因此该通知不应在启动阶段被调用。 |
| Rationale | 一旦检测到故障,可能希望选择恢复方式。 |
| Use Case | 晶体丢失恢复和有序关闭 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01064, RS_BRF_02168)
#### 6.1.4 关机操作
##### 6.1.4.1 [SRS_Mcu_12268] MCU 驱动应提供激活 µC MCU 节能模式的服务
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | MCU 驱动应提供激活 µC MCU 节能模式的服务。 |
| Rationale | -- |
| Use Case | 上层意图进入 ECU 降功耗模式。上层调用 MCU 驱动以激活适当的 MCU 设置。 |
| Dependencies | [SRS_Mcu_12421] 低功耗模式配置 |
| Supporting Material | 注:Low Power Modes 的 MCU 模式不要求在每个微控制器设备中都实现。 |
⌋(RS_BRF_01184)
### 6.2 备注
本章节[MCU 驱动]汇集了多种功能,以解决在从 MCU 节能模式或复位恢复后正确初始化的问题。
配置工具对于该功能的正确实现非常重要,并且可能需要成为最终解决方案的一部分。
---
## 7 参考文献
### 7.1 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
- [TPS_STDT_0078] Software Standardization Template, AUTOSAR_TPS_StandardizationTemplate.pdf
### 7.2 相关标准与规范
无。
---
## 翻译说明
- 本文档由 AUTOSAR CP 4.4.0 英文原文翻译。
- 模块缩写(MCU、MCAL、PLL、ECU、SPAL、DIO、PORT、ADC、PWM、ICU、SPI 等)保留原文。
- API 标识符、需求 ID(SRS_Mcu_xxxxx、RS_BRF_xxxxx)保留原文。
- AUTOSAR 方括号符 `⌈ ⌋` 保留原貌,以保持需求结构的可追溯性。
- 版权声明保持英文原文。
- 跨文档引用以英文文件名形式保留。
- Reset Types(如 Power On Reset、External Hard Reset 等)保留英文以保持与 API 定义的一致性。
MCAL/AUTOSAR_SRS_SPALGeneral.md
+646
View File
@@ -0,0 +1,646 @@
# AUTOSAR SPAL 通用需求规范
> **General Requirements on SPAL**
> AUTOSAR CP Release 4.4.0
## 元信息
- **文档类别**：SRS（Software Requirements Specification，软件需求规范）
- **模块名称**：SPAL（Standard Peripheral Abstraction Layer,标准外设抽象层)
- **关联层级**：MCAL / ECU Abstraction Layer
- **AUTOSAR 版本**：Classic Platform 4.4.0
- **文档标识号**：009
## 文档标识
| 项 | 值 |
| --- | --- |
| Document Title | General Requirements on SPAL |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 009 |
| 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 | SRS 需求引用 BMW 规范;删除对 HIS 的引用;轻微修订、澄清与编辑性变更，详情请参阅 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 | 将需求与 BSW Feature 文档相关联;按照 TPS_StandardizationTemplate 更新需求格式 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 在 SRS_SPAL_12461 中变更:从描述中删除"所有其他寄存器应由启动代码初始化" |
| 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 | 更新 SRS_SPAL_12092 中的用例;删除 SRS_SPAL_12077 中的支持材料,因其引用已被拒绝的需求 BSW12161;修订法律免责声明;修订"用户须知";新增"修订信息" |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 文档拆分,每个 SPAL 驱动现在拥有独立的需求文档;变更唤醒需求;新增 3 项需求;修改 9 项需求;拒绝 5 项需求 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 首次发布 |
## 免责声明
> 本节为版权与法律声明,以英文形式发布,翻译时予以保留原文。详情请参考英文原版。
---
## 目录
1. [文档范围](#1-文档范围)
2. [需求指南](#2-需求指南)
- 2.1 [使用的约定](#21-使用的约定)
- 2.2 [需求质量](#22-需求质量)
- 2.3 [需求标识](#23-需求标识)
- 2.4 [需求结构](#24-需求结构)
3. [缩略语与缩写](#3-缩略语与缩写)
4. [概念性问题](#4-概念性问题)
- 4.1 [通用规则](#41-通用规则)
- 4.2 [不受时钟频率影响的驱动列表](#42-不受时钟频率影响的驱动列表)
- 4.3 [MCAL 相关的 ECU 电源模式](#43-mcal-相关的-ecu-电源模式)
- 4.4 [唤醒场景](#44-唤醒场景)
- 4.5 [驱动的调度与集成](#45-驱动的调度与集成)
5. [需求追溯](#5-需求追溯)
6. [需求规范](#6-需求规范)
- 6.1 [功能性需求](#61-功能性需求)
- 6.1.1 [通用需求](#611-通用需求)
- 6.2 [非功能性需求](#62-非功能性需求)
- 6.2.1 [时序需求](#621-时序需求)
- 6.2.2 [软件设计需求](#622-软件设计需求)
- 6.2.3 [流程需求](#623-流程需求)
7. [参考文献](#7-参考文献)
---
## 1 文档范围
本文档规定了以下软件层中基础软件模块的通用需求:
- Microcontroller Abstraction Layer(微控制器抽象层)
- ECU Abstraction Layer(ECU 抽象层)
上述模块包括下列类型:
- µC 内部和外部外设的驱动 Drivers
- 处理程序 Handlers
- 接口 Interfaces
模块的选择源于 WP Architecture BSW Module List 和 Layered Architecture。涵盖的模块包括:
- 内存驱动与接口(内部/外部 EEPROM、Flash、Flash EEPROM Emulation)
- I/O 驱动(PORT、ADC、DIO、PWM、ICU、OCU)
- I/O 硬件抽象
- ECU 板载通信驱动与处理程序(SPI)
- 系统驱动(内部/外部 Watchdog、MCU、GPT、RAM test)
### 约束
基础软件模块需求规范的首要范围是不涉及安全相关的系统。因此,安全需求被赋予中等优先级。
---
## 2 需求指南
应引用现有规范(以单个需求的形式)。与这些规范的差异应作为附加需求另行规定。
### 2.1 使用的约定
- AUTOSAR 文档中需求的表示形式遵循文献[5]中规定的表格。
- 在需求中,以下特定语义被使用(摘自 IETF 的 Request for Comment 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"表示某项确实是可选的。一个供应商可以选择包含该项,因为特定市场需求或供应商认为它能够提升产品,而另一供应商可以省略相同的项。不包含特定可选项的实现 MUST 准备好与包含该选项的实现互操作(可能功能有所缩减)。同理,包含特定选项的实现 MUST 准备好与不包含该选项的实现互操作(当然,除了该选项所提供的特性之外)。
### 2.2 需求质量
所有需求应具备以下属性:
- **无冗余 Redundancy**:需求不应在同一需求中或在其他需求中重复。
- **清晰性 Clearness**:所有需求只允许一种解释方式。只能使用术语表中的技术术语。
- **原子性 Atomicity**:每个需求只应包含一项需求。如果需求不能被进一步拆分,则它是原子的。
- **可测试性 Testability**:需求应可通过分析、评审或测试进行验证。
- **可追溯性 Traceability**:需求的来源和状态应始终可见。
### 2.3 需求标识
每个需求都有以前缀 "BSW"(代表"Basic Software")开头的唯一标识符。任何评审注释、备注或问题请引用此唯一 ID,而非章节或页码!
### 2.4 需求结构
每章应按以下方式组织:
**功能性需求**:
- 配置(模块中哪些元素需要可配置)
- 初始化
- 正常操作
- 关机操作
- 故障操作
- ...
**非功能性需求**:
- 时序需求
- 资源使用
- 易用性
- 给其他工作包的输出(例如描述模板、工具链等)
- ...
---
## 3 缩略语与缩写
具有局部范围的缩略语和缩写不包含在 AUTOSAR 术语表中。它们必须出现在本地术语表中。
| 缩写 | 描述 |
| --- | --- |
| CS | Chip Select(片选) |
| DIO | Digital Input Output(数字输入输出) |
| ECU | Electric Control Unit(电子控制单元) |
| ICU | Interrupt Capture Unit(中断捕获单元) |
| MAL | 微控制器抽象层的旧称(已被 MCAL 取代,因为 'MAL' 在法语中意为'坏的') |
| MCAL | Microcontroller Abstraction Layer(微控制器抽象层) |
| MCU | Microcontroller Unit(微控制器单元) |
| MMU | Memory Management Unit(内存管理单元) |
| Master | 控制其他设备(从设备,见下文)的设备 |
| Slave | 完全由主设备控制的设备 |
| NMI | Non Maskable Interrupt(不可屏蔽中断) |
| OS | Operating System(操作系统) |
| OCU | Output Compare Unit(输出比较单元) |
| PLL | Phase Locked Loop(锁相环) |
| PWM | Pulse Width Modulation(脉冲宽度调制) |
| RX | Reception(总线通信场景下的接收) |
| SPAL | Standard Peripheral Abstraction Layer(本工作组名称) |
| SFR | Special Function Register(专用功能寄存器) |
| RTE | Runtime Environment(运行时环境) |
| WP | Work Package(工作包) |
| STD | Standard(标准) |
| REQ | Requirement(需求) |
| UNINIT | Uninitialized(未初始化) |
由于本文档是面向专业人员的专业文档,其余术语默认读者已知。
---
## 4 概念性问题
### 4.1 通用规则
1. 不要在我们的回调函数内做任何超出 50 µs 运行时间的事情,这将对系统性能产生过多影响。
2. 每个驱动规范的设计应使驱动本身负责维护其内部数据的原子性和数据完整性。
3. 应用层缓冲区应作为指针从用户传递给驱动。
### 4.2 不受时钟频率影响的驱动列表
时钟频率是对 WP "Specification / Standardization of BSW" 中大多数驱动有很大影响的参数。下面列出不直接依赖时钟频率的软件模块:
- PORT
- DIO
- RAM test
**结论**:大多数驱动对时钟频率有强依赖,因此在配置每个软件组件时仔细考虑其在整个系统中的影响非常重要。
### 4.3 MCAL 相关的 ECU 电源模式
WP "Specification / Standardization of BSW" 中所包含的驱动应支持 Specification of ECU State Manager 中定义的 ECU 电源模式。
必须支持不同的时钟模式。所有驱动应支持以不同配置参数重新初始化。详情请参阅"ECU State Manager"文档。
### 4.4 唤醒场景
由于不同的时序需求(例如某些 ECU 周期性唤醒,仅检查一些输入后尽快回到睡眠状态),需要采用不同的初始化流程。例如:
- 唤醒后初始化
- 上电复位 Power On Reset 后初始化
**结论**:不可能采用标准化的唤醒序列。该序列取决于微控制器硬件和系统需求。当前规定的概念允许以标准化的方式处理唤醒信号,同时提供自定义实际唤醒序列的可能。
### 4.5 驱动的调度与集成
目前,已知 ECU 的 90% 功能采用协作式调度。原因包括:
- 技术原因:相对抢占式系统,具有更低的开销(任务切换时间和任务栈消耗)
- 技术原因:更易于创建确定性行为
- 技术原因:相对全抢占式系统,采用协作式系统更易达到稳定的 95% 系统负载
- 历史原因:许多 ECU 在使用协作式调度概念
因此,所有驱动应允许被用于协作式调度的系统中。它们不应实现阻塞代码并期望被操作系统抢占。实现提示:使用状态机代替线性代码。
---
## 5 需求追溯
| 上层需求 | 描述 | 由以下需求满足 |
| --- | --- | --- |
| RS_BRF_01064 | AUTOSAR BSW 应提供回调函数以访问上层模块 | SRS_SPAL_00157, SRS_SPAL_12056 |
| RS_BRF_01096 | AUTOSAR 应支持 ECU 启动与关机 | SRS_SPAL_12057, SRS_SPAL_12068, SRS_SPAL_12125, SRS_SPAL_12163, SRS_SPAL_12461, SRS_SPAL_12463 |
| RS_BRF_01104 | AUTOSAR 应支持 ECU 与总线的睡眠与唤醒 | SRS_SPAL_12067, SRS_SPAL_12069, SRS_SPAL_12267 |
| RS_BRF_01152 | AUTOSAR 应支持有限的动态重配置 | SRS_SPAL_12265 |
| RS_BRF_01440 | AUTOSAR 服务应支持系统诊断功能 | SRS_SPAL_12064 |
| RS_BRF_01496 | AUTOSAR 应规范化处理使 ECU 离开 SLEEP 模式的事件 | SRS_SPAL_12267 |
| RS_BRF_02168 | AUTOSAR 诊断应提供异常运行状况的集中分类与处理 | SRS_SPAL_00157, SRS_SPAL_12064 |
| RS_BRF_02232 | AUTOSAR 应支持带运行时断言检查的开发 | SRS_SPAL_00157, SRS_SPAL_12448 |
---
## 6 需求规范
### 6.1 功能性需求
#### 6.1.1 通用需求
本章包含适用于 Microcontroller Abstraction Layer 与 ECU Abstraction Layer 所有模块,但不一定适用于其他层基础软件模块的通用需求。
##### 6.1.1.1 配置
###### 6.1.1.1.1 [SRS_SPAL_12263] 所有驱动模块的实现应允许在链接时配置特定模块参数类型
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 所有驱动模块的实现应允许在链接时配置下列模块参数类型:<br>- 写入硬件寄存器的值<br>- 在驱动模块中使用的值(例如时序)<br>- 回调函数<br><br>这些参数应置于一个模块外部的初始化数据结构中。 |
| Rationale | 以目标代码形式交付驱动模块 |
| Use Case | SVDO 与 Hella 内部开发模型 |
| Dependencies | [SRS_SPAL_12264] 配置项规范 |
| Supporting Material | 需要采用复杂的软件设计技术,以达到与源代码类似的可扩展性和资源效率。 |
⌋()
###### 6.1.1.1.2 [SRS_SPAL_12056] 所有驱动模块应允许通知机制的静态配置
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 所有驱动模块应允许通知机制的静态配置。回调函数的指针不得通过 API 传递。 |
| Rationale | 灵活性与可扩展性 |
| Use Case | 提供在受保护操作系统中运行驱动的可能性。通过 API 传递且"指向任意位置"的回调不可在受保护 OS 中使用。MISRA 建议避免使用指向函数的动态指针。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01064)
###### 6.1.1.1.3 [SRS_SPAL_12267] 唤醒源应由 MCAL 驱动和/或 MCU 驱动初始化
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 唤醒源应由 MCAL 驱动和/或 MCU 驱动初始化。可能的唤醒源包括 reset、watchdog、NMI、interrupt 等。 |
| Rationale | 允许配置 MCU 唤醒。 |
| Use Case | GPT 中断由 GPT 驱动使能,应能将 MCU 从 Idle/Sleep/Stop 模式中唤醒。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01104, RS_BRF_01496)
##### 6.1.1.2 初始化
###### 6.1.1.2.1 [SRS_SPAL_12057] 所有驱动模块应实现初始化接口
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 所有驱动模块应实现一个用于初始化的接口。该服务应初始化所有模块的全局变量以及由该模块使用的所有 SFR。 |
| Rationale | 基本功能。 |
| Use Case | -- |
| Dependencies | [SRS_SPAL_12125] 硬件资源的初始化 |
| Supporting Material | -- |
⌋(RS_BRF_01096)
###### 6.1.1.2.2 [SRS_SPAL_12125] 所有驱动模块应仅初始化已配置的资源
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 所有驱动模块应仅初始化已配置的资源。配置文件中未配置的资源不应被触及。 |
| Rationale | 允许与复杂驱动 Complex Drivers 集成且无资源冲突。 |
| Use Case | 通道 0..3 被 GPT 驱动使用,通道 4..6 被复杂驱动使用。 |
| Dependencies | [SRS_SPAL_12057] 驱动模块初始化 |
| Supporting Material | -- |
⌋(RS_BRF_01096)
###### 6.1.1.2.3 [SRS_SPAL_12163] 所有驱动模块应实现去初始化接口
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 所有驱动模块应实现一个用于去初始化的接口。该服务应将该模块使用的所有模块全局变量及所有 SFR 复位到其默认复位值。不可写寄存器的值除外。 |
| Rationale | 关闭模块。重新创建与初始化前相同的状态。清空队列。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01096)
###### 6.1.1.2.4 [SRS_SPAL_12461] 关于控制器寄存器初始化的特定规则应适用于所有驱动实现
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 关于控制器寄存器初始化的下列规则应适用于所有驱动实现:<br>1. 如果硬件只允许该寄存器的一次使用,实现该功能的驱动模块负责初始化该寄存器<br>2. 如果该寄存器可影响多个硬件模块且为 I/O 寄存器,应由 PORT 驱动初始化<br>3. 如果该寄存器可影响多个硬件模块且非 I/O 寄存器,应由 MCU 驱动初始化<br>4. 在复位后需要立即初始化的一次性可写寄存器,应由启动代码初始化 |
| Rationale | 控制器寄存器的明确初始化,无需为不同配置更改驱动实现。 |
| Use Case | 1) 所有与 flash 模块相关的寄存器应由 flash 驱动初始化<br>2) 可用于 CAN、ADC 或 DIO 的 I/O 寄存器应由 PORT 驱动初始化<br>3) 影响不同硬件模块时钟设置的寄存器应由 MCU 驱动初始化<br>4) 影响寄存器集、RAM 或 EEPROM 映射的寄存器应在启动代码中初始化 |
| Dependencies | -- |
| Supporting Material | I/O register:任何可影响端口引脚功能的内容。 |
⌋(RS_BRF_01096)
###### 6.1.1.2.5 [SRS_SPAL_12462] 寄存器初始化设置应当发布
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 各驱动模块的实现者必须在驱动模块文档中发布所有寄存器初始化设置。 |
| Rationale | 配置者(负责配置软件的人员或工具)需要获取那些不直接由驱动初始化的寄存器设置。 |
| Use Case | -- |
| Dependencies | SRS_SPAL_12461 |
| Supporting Material | -- |
⌋()
###### 6.1.1.2.6 [SRS_SPAL_12463] 寄存器初始化设置应合并并转发
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 配置者应合并所有来自不同驱动的初始化设置,并对其进行一致性检查(依赖性与冲突)。检查通过后应将合并的设置转发给负责初始化硬件的模块。如有不一致,配置者应抛出错误,系统构建过程必须重新启动。 |
| Rationale | 确保所有控制器寄存器以一致方式使用,且所有驱动对寄存器初始化设置的需求均得到满足。 |
| Use Case | -- |
| Dependencies | [SRS_SPAL_12461], [SRS_SPAL_12462] |
| Supporting Material | -- |
⌋(RS_BRF_01096)
###### 6.1.1.2.7 [SRS_SPAL_12068] MCAL 各模块应按定义顺序初始化
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | MCAL 各模块应按如下顺序初始化:<br>1. 禁用全局中断<br>2. 初始化全局寄存器(MCAL 系统模块)<br>3. 初始化所有驱动<br>4. 可使能全局中断 |
| Rationale | 无副作用的明确初始化序列。 |
| Use Case | Power On Reset |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01096)
###### 6.1.1.2.8 [SRS_SPAL_12069] SPAL 中从唤醒中断恢复的所有驱动应报告唤醒原因
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | SPAL 中从唤醒中断恢复的所有驱动应通过 IO 硬件抽象层向 ECU State Manager 报告唤醒原因。<br><br>来自 SPAL 驱动的通知应在 IO 硬件抽象模块中处理,然后再将唤醒原因发送至 ECU 状态管理器。<br><br>实现提示:通常,该通知由唤醒中断的 ISR 完成。 |
| Rationale | ECU State Manager 需要唤醒原因。它可以保证低功耗。例如,对于 ICU,可以避免报告无效的唤醒原因(尖峰)。 |
| Use Case | 相关唤醒中断的 ISR 在唤醒发生时调用 ECU State Manager 的唤醒报告函数。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01104)
##### 6.1.1.3 正常操作
###### 6.1.1.3.1 [SRS_SPAL_00157] AUTOSAR 基础软件的所有驱动与处理程序应实现驱动和处理程序的通知机制
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | AUTOSAR 基础软件的所有驱动与处理程序应实现下列通知机制(每个模块可配置)以供基础软件内使用:<br>- 轮询(通过读取状态信息)<br>- 回调函数<br>- 默认错误跟踪器 DET 的错误报告函数<br>- 诊断事件管理器 DEM 的事件报告函数 |
| Rationale | 灵活集成;避免强耦合与依赖。 |
| Use Case | EEPROM 写命令的完成可通过回调函数或设置状态信息(可通过模块接口访问)进行信号传递。<br><br>EEPROM 写入过程中发生故障(单元损坏)可上报至诊断事件管理器 DEM。 |
| Dependencies | Mr. Schumpelt/Bosch 的评审注释 #35 |
| Supporting Material | -- |
⌋(RS_BRF_01064, RS_BRF_02232, RS_BRF_02168)
###### 6.1.1.3.2 [SRS_SPAL_12169] 提供不同操作模式的所有驱动模块应提供模式选择服务
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 提供不同操作模式的所有驱动模块应提供模式选择服务。该服务允许在无需去初始化与重新初始化的情况下,从一种操作模式切换到另一种操作模式。 |
| Rationale | 允许在不希望出现的副作用情况下进行操作模式切换。 |
| Use Case | 将 EEPROM 驱动从普通模式切换到突发模式 |
| Dependencies | [SRS_SPAL_12064] 运行操作期间的操作模式变更 |
| Supporting Material | -- |
⌋()
###### 6.1.1.3.3 [SRS_SPAL_12063] 所有驱动模块应仅支持原始值模式
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 所有驱动模块应仅支持原始值模式。在该模式下,通过 API 服务传递的值将被直接使用,不进行进一步缩放。 |
| Rationale | 缩放和到物理值的转换是 ECU Abstraction Layer 的任务。原始值模式提供最高的性能。 |
| Use Case | I/O Hardware Abstraction 将原始 ADC 值转换为缩放后的值(例如电压),反之亦然。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
###### 6.1.1.3.4 [SRS_SPAL_12075] 具有随机流式能力的所有驱动应使用应用层缓冲区
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 具有随机流式能力的所有驱动(memory drivers)应使用应用层缓冲区。在驱动作业处理期间,调用者不得改变数据。 |
| Rationale | 最少的 RAM 消耗,运行时效率。 |
| Use Case | EEPROM 写服务获取一个指向源数据的指针。EEPROM 写操作期间,驱动从应用层缓冲区读取数据。EEPROM 驱动不提供自己的数据缓冲区。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
###### 6.1.1.3.5 [SRS_SPAL_12129] ISR 应负责复位中断标志并调用相应的通知函数
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | ISR 应负责复位中断标志并调用相应的通知函数。 |
| Rationale | 通知函数可以由用户定义,因此不允许直接访问硬件。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
##### 6.1.1.4 故障操作
###### 6.1.1.4.1 [SRS_SPAL_12064] 若操作模式变更导致正在运行的操作降级,所有驱动模块应报告错误
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 若操作模式的变更导致正在运行的操作降级,所有驱动模块应报告错误。正在运行的操作应被保留。<br><br>附加说明:此错误条件在正确的系统设计中不应发生。 |
| Rationale | -- |
| Use Case | SPI EEPROM 操作模式在正在运行的 SPI 通信序列中有效。 |
| Dependencies | [SRS_SPAL_12169] 操作模式控制 |
| Supporting Material | -- |
⌋(RS_BRF_02168, RS_BRF_01440)
###### 6.1.1.4.2 [SRS_SPAL_12448] 所有驱动模块在检测到开发错误后应具有特定行为
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 在检测到开发错误时,所有驱动模块应:<br>- 将错误报告至默认错误跟踪器 DET<br>- 跳过所要求的功能(在不执行任何动作的情况下离开服务)<br>- 标准返回值的情况下返回 E_NOT_OK<br>- 在返回任意值的情况下(例如 Dio_ReadPort)返回 0 |
| Rationale | 所有 SPAL 模块行为统一。避免处理错误的 API 参数,从而避免硬件损坏或危险的系统行为。 |
| Use Case | 已为驱动启用开发错误检测。驱动服务被调用且输入参数值有误。该服务不应处理该命令(否则可能导致严重故障)。 |
| Dependencies | [SRS_SPAL_00157] 驱动与处理程序的通知机制 |
| Supporting Material | -- |
⌋(RS_BRF_02232)
##### 6.1.1.5 关机操作
###### 6.1.1.5.1 [SRS_SPAL_12067] 所有驱动模块应根据所选操作模式设置其唤醒条件
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 所有驱动模块应根据所选操作模式设置其唤醒条件。 |
| Rationale | 允许使能模块特定的唤醒中断。 |
| Use Case | 例子:<br>ECU 状态管理器将 ECU 电源模式切换为 'ECU_POWERMODE_SLEEP'。<br>模块 'GPT' 和 'ICU' 根据其相对于 'ECU_POWERMODE_SLEEP' 的配置使能特定唤醒中断。 |
| Dependencies | [SRS_SPAL_12169] 操作模式控制 |
| Supporting Material | -- |
⌋(RS_BRF_01104)
### 6.2 非功能性需求
#### 6.2.1 时序需求
##### 6.2.1.1 [SRS_SPAL_12077] 所有驱动应提供非阻塞实现
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 所有驱动应提供非阻塞实现。<br><br>注:本需求中的"阻塞实现"是指"无感、不协作地占用处理器时间",例如长时间循环。 |
| Rationale | 避免未确定的等待时间。允许在协作式调度系统中使用所有驱动。 |
| Use Case | 用于"ADC 转换就绪标志"的等待循环应具有附加的超时条件。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
##### 6.2.1.2 [SRS_SPAL_12078] 驱动应以内存和运行时资源最有效的方式编码
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 驱动应以内存和运行时资源最有效的方式编码。 |
| Rationale | 避免资源浪费。 |
| Use Case | 在嵌入式汽车系统中使用驱动。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
#### 6.2.2 软件设计需求
##### 6.2.2.1 [SRS_SPAL_12092] 驱动的 API 应由其处理程序或管理器访问
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 如果一个驱动由处理程序或管理器控制,则不允许绕过该处理程序/管理器直接访问驱动的 API。如果驱动上方没有处理程序/管理器,则可直接访问。 |
| Rationale | 一致的访问。Handlers 和 Managers 不应被绕过。 |
| Use Case | EEPROM 驱动通过 EEPROM Abstraction 模块和 Memory Abstraction Interface 由 NVRAM Manager 独占控制。不允许其他形式访问 EEPROM 驱动的 API。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
##### 6.2.2.2 [SRS_SPAL_12265] 配置数据应保持常量
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 通过初始化函数传递给模块的初始化结构体的内容,应在运行时保持常量并可用。<br>说明:通常,这个初始化数据结构位于 ROM 中。 |
| Rationale | 模块可以随时访问该结构。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01152)
#### 6.2.3 流程需求
##### 6.2.3.1 [SRS_SPAL_12264] 应提供配置项规范
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | SWS(软件规范)应针对每个配置元素指定:<br>- 它是在编译前还是编译后可配置<br>- 该配置项位于何处(初始化数据结构,配置头文件 *_Cfg.h) |
| Rationale | 启用允许目标代码交付的配置参数的正确实现。 |
| Use Case | -- |
| Dependencies | [SRS_SPAL_12263] 编译后配置 |
| Supporting Material | -- |
⌋()
---
## 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] Specification of ECU State Manager
AUTOSAR_SWS_ECUStateManager.pdf
[5] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf
### 7.2 相关标准与规范
无。
---
## 翻译说明
- 本文档由 AUTOSAR CP 4.4.0 英文原文翻译。
- 模块缩写(MCAL、SPAL、ECU、DIO、PORT、ADC、PWM、ICU、OCU、SPI、MCU、GPT 等)保留原文。
- API 标识符、需求 ID(SRS_SPAL_xxxxx、RS_BRF_xxxxx)保留原文。
- AUTOSAR 方括号符 `⌈ ⌋` 保留原貌,以保持需求结构的可追溯性。
- 版权声明保持英文原文。
- 跨文档引用以英文文件名形式保留。
MCAL/AUTOSAR_SWS_CoreTest.md
+910
View File
@@ -0,0 +1,910 @@
# AUTOSAR Core Test 规范
> **Specification of Core Test**
> AUTOSAR CP Release 4.4.0
## 元信息
- **文档类别**：SWS（Software Specification,软件规范）
- **模块名称**：Core Test Driver(内核测试驱动)
- **关联层级**：MCAL(Microcontroller Abstraction Layer,微控制器抽象层)
- **AUTOSAR 版本**：Classic Platform 4.4.0
- **文档标识号**：259
## 文档标识
| 项 | 值 |
| --- | --- |
| Document Title | Specification of Core Test |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 259 |
| 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 的变更(Draft) |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 轻微修正 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 将 Development Error Tracer 替换为 Default Error Tracer;删除 Debugging Support 章节;删除 Variants 章节 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 修正 CorTst_Init 原型;添加 CorTst_ConfigType 和 CorTst_ResultType;调试支持标记为废弃;轻微修正 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | CORTST_E_CORE_FAILURE 扩展生产错误形式化,包括 healing;修正 CorTst_GetCurrentStatus 原型 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 删除需求 SWS_CorTst_00067 的时序属性;编辑性修订;删除变更文档章节 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 与新的 SWS_BSWGeneral 文档对齐;更新文档以适应扩展生产错误;与其他 AUTOSAR 文档的官方命名对齐 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 澄清部分需求;修正错别字;删除冗余和无用需求 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 添加新的配置和错误检测需求;澄清部分需求;添加新配置参数;删除过时需求;改进静态错误检测;删除未使用类型 |
| 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 基础软件模块 Core Test Driver 的功能、API 和配置。本规范适用于所有类型内核的驱动,无论驱动是在 ECU 上电情况下执行,还是在 ECU 应用运行时执行。
Core Test Driver 提供以下服务:
- 配置、启动、轮询、终止 Core Test
- 通知应用程序 Core Test 结果
- 以预定义方式返回测试结果
- 验证专用内核功能(例如通用寄存器或算术逻辑单元 ALU)的多种测试
假定每个被测内核硬件功能都可以专门访问以进行测试。Core Test Driver API 的用户应选择合适的测试组合和调度执行顺序,以满足系统的安全需求。这些服务的行为是异步或同步的。
Core Test 驱动直接访问微控制器内核,不经过任何中间软件层,并位于 Microcontroller Abstraction Layer (MCAL) 中。
---
## 2 缩略语与缩写
| 缩写 | 描述 |
| --- | --- |
| MCAL | Microcomputer Abstraction Layer(微计算机抽象层) |
| DEM | Diagnostic Event Manager(诊断事件管理器) |
| DET | Default Error Tracer(默认错误跟踪器) |
| CPU | Central Processing Unit(中央处理单元) |
| MPU | Memory Protection Unit(内存保护单元) |
| L1 | 1st level memory(一级内存) |
| L2 | 2nd level memory(二级内存) |
| MCU | Microcontroller Unit(微控制器单元) |
| BIST | Built in Self Test(内建自测试) |
| IRQ | Interrupt Request(中断请求) |
| Core | CPU 加上紧密相关的功能资源 |
| CSUM/Checksum/signature | 测试执行结果的数字表示 |
| 术语 | 描述 |
| --- | --- |
| Background test | 后台测试由 SW-scheduler/RTOS 周期性调用 |
| Foreground test | 前台测试是同步测试,不应被中断。它由用户应用调用触发 |
| Golden (Ref.) Value | 用于与之前计算的测试结果值比较的参考值(例如 Checksum/Signature) |
| Good Case | 执行完成且未报告错误 |
| Atomic sequence / atomic piece | 不能被中断的测试片段 |
| External device | 物理上的外部实体;例如第二个微控制器 |
| Resource | 'hardware resource' 是 CORETest 驱动用户可选择的最小单元(实例)。它可以在一个或多个原子序列中测试。它是执行唯一功能的内核内部单元(例如 IRQ-controller) |
| Partial test | 部分测试,定义为对一个或多个 'hardware resources' 的测试。(部分测试可被中断,因为它在后台模式中执行) |
| Entity/unit | 内核内部的硬件功能(例如 CPU、MMU 等) |
| Caller / calling entity | 调用者/调用实体位于较高的 AUTOSAR 或 ISO 层。它是 API 调用的用户。 |
| test interval | CoreTest 测试间隔:在硬件资源上执行的所有部分测试(在后台模式中执行)的总和,构成一个完整的 Core test |
| Test Interval Id | 测试间隔的标识符,每次开始新的测试间隔时递增 |
---
## 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] Specification of BSW Scheduler, AUTOSAR_SWS_BSW_Scheduler.pdf
- [5] ECU Configuration Specification, AUTOSAR_SWS_ECUStateManager.pdf
- [6] Specification of Memory Mapping, AUTOSAR_SWS_MemoryMapping.pdf
- [7] Requirement on Core Test, AUTOSAR_SRS_CoreTest.pdf
- [8] AUTOSAR Basic Software Module Description Template, AUTOSAR_RS_BSWModuleDescriptionTemplate.pdf
- [9] General Specification of Basic Software Modules, AUTOSAR_SWS_BSWGeneral.pdf
### 3.2 相关标准与规范
- [10] ISO DIS 26262, www.iso.org
### 3.3 相关规范
AUTOSAR 提供了基础软件模块的通用规范[9] (SWS BSW General),该规范也适用于 Core Test。
因此,SWS BSW General 规范应被视为 Core Test 的附加且必需的规范。
---
## 4 约束与假设
### 4.1 限制
Core test 模块实现可能受限于:
- 在上电/启动期间执行,此时内核资源未在不同活动的 AUTOSAR 相关软件任务或硬件实体之间共享(例如 IRQ-controller、DMA、Cache、MMU/MPU 和 MemoryIF)
- **或**
- 受限于测试运行时未共享的资源(例如 ALU 和 CPU 寄存器)
这取决于整体汽车系统架构,无法在 MCAL Core Test SWS 规范中覆盖。
必须存在一个管理实体或架构,管理诸如"硬件资源访问管理"等任务,因为 MCAL 驱动无法自行处理此类任务。
### 4.2 适用于汽车领域
无限制。
### 4.3 适用于安全相关环境
如果上层软件提供以下机制来处理 Core Test API 结果,且 Core Test 模块实现被嵌入到系统安全架构概念中,本模块可用于安全相关系统:
- Checksum/signature 保护
- 在使用 Core Test 代码前检查其完整性
- Checksum/signature 的冗余存储
- Core Test 结果的外部决策执行
---
## 5 对其他模块的依赖
CoreTest 模块依赖于以下模块:
- 需要 BSW scheduler 在后台模式下触发主函数
Core Test 库模块和/或源代码模块依赖于微控制器平台,因此依赖于硅片制造商的硬件实现,甚至依赖于硅片版本。
Core Test 库模块和/或源代码模块依赖于一个积极工作的内核时钟域。
### 5.1 文件结构
#### 5.1.1 代码文件结构
[SWS_CorTst_00002] ⌈Core Test 模块应仅为测试目的提供中断服务例程。⌋ (SRS_BSW_00164, SRS_CoreTst_14105)
---
## 6 需求可追溯性
| 上层需求 | 描述 | 由以下需求满足 |
| --- | --- | --- |
| SRS_BSW_00003 | 所有软件模块应提供版本和标识信息 | SWS_CorTst_00112 |
| SRS_BSW_00004 | 所有基础 SW 模块应对所有导入包含文件的版本进行预处理器检查 | SWS_CorTst_00112 |
| SRS_BSW_00101 | 基础软件模块应能够在单独的初始化函数中初始化变量和硬件 | SWS_CorTst_00040, SWS_CorTst_00041 |
| SRS_BSW_00164 | 中断服务例程的实现应由操作系统、complex drivers 或模块完成 | SWS_CorTst_00002 |
| SRS_BSW_00304 | 所有 AUTOSAR 基础软件模块应使用以下数据类型而非原生 C 数据类型 | SWS_CorTst_00027 |
| SRS_BSW_00323 | 所有 AUTOSAR 基础软件模块应检查传递的 API 参数的有效性 | SWS_CorTst_00161 |
| SRS_BSW_00327 | 错误值命名约定 | SWS_CorTst_00016 |
| SRS_BSW_00331 | 所有基础软件模块应严格区分错误和状态信息 | SWS_CorTst_00037, SWS_CorTst_00038, SWS_CorTst_00039 |
| SRS_BSW_00336 | 基础 SW 模块应能关机 | SWS_CorTst_00045, SWS_CorTst_00046 |
| SRS_BSW_00337 | 开发错误分类 | SWS_CorTst_00016 |
| SRS_BSW_00339 | 报告生产相关错误状态 | SWS_CorTst_00154, SWS_CorTst_00155, SWS_CorTst_00177, SWS_CorTst_01000, SWS_CorTst_01001, SWS_CorTst_01002 |
| SRS_BSW_00357 | 应为 API 调用的成功/失败定义标准返回类型 | SWS_CorTst_00064 |
| SRS_BSW_00385 | 列出可能的错误通知 | SWS_CorTst_00016, SWS_CorTst_01000 |
| SRS_BSW_00406 | 表明 BSW 模块是否已初始化的静态状态变量应在 BSW 模块的任何 API 被调用前以值 0 初始化 | SWS_CorTst_00040, SWS_CorTst_00044 |
| SRS_BSW_00407 | 每个 BSW 模块应提供函数以读取专用模块实现的版本信息 | SWS_CorTst_00112, SWS_CorTst_00118 |
| SRS_BSW_00414 | Init 函数应以指向配置结构的指针作为唯一参数 | SWS_CorTst_00040, SWS_CorTst_01003, SWS_CorTst_01004 |
| SRS_BSW_00466 | 扩展生产错误分类 | SWS_CorTst_00154, SWS_CorTst_00155, SWS_CorTst_01000, SWS_CorTst_01001, SWS_CorTst_01002 |
| SRS_BSW_00469 | 生产错误和扩展生产错误的故障检测与 healing | SWS_CorTst_00154, SWS_CorTst_00155, SWS_CorTst_01000, SWS_CorTst_01001, SWS_CorTst_01002 |
| SRS_CoreTst_14104 | 应可用 Core Register Test | SWS_CorTst_00008 |
| SRS_CoreTst_14105 | 应可用 Core Interrupt and Exception Detection Tests | SWS_CorTst_00002, SWS_CorTst_00009 |
| SRS_CoreTst_14106 | 应可用 Core ALU Test | SWS_CorTst_00010 |
| SRS_CoreTst_14107 | 应可用 Core Address Generator Test | SWS_CorTst_00011 |
| SRS_CoreTst_14108 | 应可用 Core Memory Interfaces Test | SWS_CorTst_00012 |
| SRS_CoreTst_14109 | 应可用 MMU/MPU Test | SWS_CorTst_00013 |
| SRS_CoreTst_14110 | 应可用 Cache Controller Test | SWS_CorTst_00014 |
| SRS_CoreTst_14112 | Core Test 服务应有单一 API | SWS_CorTst_00064, SWS_CorTst_00067, SWS_CorTst_00144 |
| SRS_CoreTst_14113 | API 应有一个选择测试组件的参数 | SWS_CorTst_00064, SWS_CorTst_00160 |
| SRS_CoreTst_14114 | 应可用 Core Test 的主函数 | SWS_CorTst_00067, SWS_CorTst_00144 |
| SRS_CoreTst_14115 | 调用者应可获得测试指标 | SWS_CorTst_00057, SWS_CorTst_00060 |
| SRS_CoreTst_14116 | 应提供返回 checksum/signature 作为测试结果的服务 | SWS_CorTst_00057, SWS_CorTst_00058, SWS_CorTst_00060, SWS_CorTst_00061, SWS_CorTst_00176 |
| SRS_CoreTst_14117 | 故障应作为生产错误处理 | SWS_CorTst_00016, SWS_CorTst_00021 |
| SRS_CoreTst_14118 | Core test 模块的结果应提供给用户 | SWS_CorTst_00053, SWS_CorTst_00054 |
| SRS_CoreTst_14119 | 应提供完成通知 | SWS_CorTst_00076, SWS_CorTst_00077 |
| SRS_CoreTst_14126 | 应可取消正在运行的测试 | SWS_CorTst_00048, SWS_CorTst_00050 |
| SRS_CoreTst_14130 | 破坏性测试应恢复被测实体的原始状态 | SWS_CorTst_00026 |
| SRS_CoreTst_14131 | 应提供返回 Pass/Fail 状态表示作为测试结果的服务 | SWS_CorTst_00055, SWS_CorTst_00056, SWS_CorTst_01005 |
| SRS_CoreTst_14133 | 每个 Core Test 时间间隔应有标识符 | SWS_CorTst_00137, SWS_CorTst_00139 |
| SRS_SPAL_00157 | 所有 AUTOSAR 基础软件的驱动与处理程序应实现通知机制 | SWS_CorTst_00077 |
| SRS_SPAL_12057 | 所有驱动模块应实现初始化接口 | SWS_CorTst_00041, SWS_CorTst_00179 |
| SRS_SPAL_12125 | 所有驱动模块应只初始化已配置的资源 | SWS_CorTst_00179 |
| SRS_SPAL_12163 | 所有驱动模块应实现去初始化接口 | SWS_CorTst_00045 |
---
## 7 功能规范
### 7.1 通用行为
[SWS_CorTst_00008] ⌈Core Test 应提供测试所有 CPU 寄存器的过程。⌋ (SRS_CoreTst_14104)
[SWS_CorTst_00009] ⌈Core Test 应提供 Interrupt Controller 和异常检测测试。特别地,中断本身的检测和到有效中断服务地址的分支应是测试的一部分。无论测试由软件异常触发还是由硅片中内置的专用硬件单元触发。⌋ (SRS_CoreTst_14105)
[SWS_CorTst_00010] ⌈Core Test 应提供算术和逻辑单元 (ALU) 测试。⌋ (SRS_CoreTst_14106)
[SWS_CorTst_00011] ⌈Core Test 应提供地址生成测试。⌋ (SRS_CoreTst_14107)
[SWS_CorTst_00012] ⌈Core Test 应提供内核内存接口测试。这明确排除对外部连接到内核或位于内核内部的内存位置本身的测试。⌋ (SRS_CoreTst_14108)
[SWS_CorTst_00013] ⌈Core Test 应提供内存保护单元 (MPU) 测试。即使内存管理单元 (MMU) 执行 MPU 功能,这也有效。⌋ (SRS_CoreTst_14109)
[SWS_CorTst_00014] ⌈Core Test 应提供 Cache Controller 测试。特别地,应测试位于内核外部内存中的数据或指令与其相应缓存条目表示之间的一致性。⌋ (SRS_CoreTst_14110)
[SWS_CorTst_00137] ⌈每个 Core Test Interval 应有一个标识符,该标识符在后台模式下每次开始新测试间隔时递增。⌋ (SRS_CoreTst_14133)
[SWS_CorTst_00144] ⌈Core Test 模块应提供后台和前台模式下的测试执行服务。⌋ (SRS_CoreTst_14112, SRS_CoreTst_14114)
后台模式下的 Core Test 状态如图 2 所示。所描述的状态仅是后台操作模式下的驱动状态。
[SWS_CorTst_00153] ⌈状态图(参见图 2)⌋ ()
[SWS_CorTst_00145] ⌈Core Test 结构化为部分测试(硬件资源测试集),可被更高优先级任务中断。⌋ ()
每个部分测试由不能被中断的原子序列组成。
#### 7.1.1 背景与原理
如 Core Test SRS 所述,Core Test 专注于测试内核,包括 CPU 和本地耦合单元(例如 MMU/MPU 和 Interrupt controller)。
由于内核实现的复杂性,要实现 Core Test 需要对内核结构有非常深入的了解。因此假定硅片制造商是实现 Core Test 的合适实体,通过使用 AUTOSAR API 并将测试作为库提供给用户或应用实现者。
此外,假定为避免知识产权流失,Core Test 实现很少作为纯源代码模块由硅片制造商赠送。
### 7.2 错误分类
#### 7.2.1 开发错误
[SWS_CorTst_00016] ⌈Core Test 应根据其构建选项检测以下 API 参数错误:
| ID | 错误类型 | 相关性 | 相关错误代码 | 值[hex] |
| --- | --- | --- | --- | --- |
| SWS_CorTst_00169 | API 服务以错误参数范围调用 | Development | CORTST_E_PARAM_INVALID | 0x11 |
| SWS_CorTst_00170 | 在 Core Test 未初始化时调用 API | Development | CORTST_E_UNINIT | 0x20 |
| SWS_CorTst_00172 | 没有 CorTst_DeInit() 间隔再次调用 CorTst_Init() | Development | CORTST_E_ALREADY_INITIALIZED | 0x23 |
| SWS_CorTst_00180 | 调用 CorTst_GetVersionInfo() 和 CorTst_GetCurrentStatus() 时使用 NULL 指针 | Development | CORTST_E_PARAM_POINTER | 0x24 |
| SWS_CorTst_00181 | 在意外状态下调用特定 API | Development | CORTST_E_STATUS_FAILURE | 0x01 |
⌋ (SRS_BSW_00337, SRS_BSW_00385, SRS_BSW_00327, SRS_CoreTst_14117)
#### 7.2.2 运行时错误
无运行时错误。
#### 7.2.3 瞬态故障
无瞬态故障。
#### 7.2.4 生产错误
本模块未指定生产错误。
#### 7.2.5 扩展生产错误
##### 7.2.5.1 CORTST_E_CORE_FAILURE
[SWS_CorTst_01000] ⌈
| 项 | 值 |
| --- | --- |
| 错误名称 | CORTST_E_CORE_FAILURE |
| 简短描述 | 测试期间核心故障 |
| 详细描述 | 此错误表明 CorTst 模块检测到内核中的故障 |
| 检测准则 | Fail:CorTst_Start 或 CorTst_MainFunction 检测到内核故障时报告 PREFAILED。Pass:CorTst_Start 或 CorTst_MainFunction 能够完成内核测试而未检测到错误时报告 PREPASSED |
| 次要参数 | PREPASSED 和 PREFAILED 检测始终活动。但如果内核不在错误可由软件可靠报告的状态,可能不会报告 PREFAILED 状态 |
| 时间要求 | 检测故障所需时间取决于 CorTst_Start 或 CorTst_MainFunction 调用的频率以及前台或后台测试的数量(见 ECUC_CorTst_00125)。从故障恢复所需时间可能更长,因为应将来自内核的瞬态硬件故障视为故障 |
| 监视频率 | 连续 |
⌋ (SRS_BSW_00339, SRS_BSW_00422, SRS_BSW_00385, SRS_BSW_00386, SRS_BSW_00466, SRS_BSW_00469)
### 7.3 错误通知
[SWS_CorTst_00021] ⌈除了在 CPU 本身内部检测到的故障(例如 ALU、MAC 等),这些故障无法由软件可靠报告。无法通过 Dem_SetEventStatus API 可靠报告的错误应由实现者记录。⌋ (SRS_CoreTst_14117)
### 7.4 通用需求
[SWS_CorTst_00023] ⌈由于 Core Test 是 MCAL 驱动模块,对硬件/软件系统架构没有了解,被测实体和资源(例如 ALU)应在运行时测试执行开始前专门可用。⌋ ()
[SWS_CorTst_00024] ⌈Core Test 实现者应提供有关 Core Test 实现的故障覆盖率成就的指示。⌋ ()
[SWS_CorTst_00026] ⌈Core Test 对被测实体应是非破坏性的。如果 Core Test 自行修改实体的设置、值或选项,它必须在返回调用服务前恢复以前的实体状态。⌋ (SRS_CoreTst_14130)
---
## 8 API 规范
### 8.1 导入类型
本章列出从其他 BSW 模块导入的所有类型:
[SWS_CorTst_00027] ⌈
| 模块 | 头文件 | 导入类型 |
| --- | --- | --- |
| Dem | Rte_Dem_Type.h | Dem_EventIdType |
| Dem | Rte_Dem_Type.h | Dem_EventStatusType |
| Std_Types | StandardTypes.h | Std_ReturnType |
| Std_Types | StandardTypes.h | Std_VersionInfoType |
⌋ (SRS_BSW_00304)
### 8.2 类型定义
#### 8.2.1 CorTst_ConfigType
[SWS_CorTst_01003] ⌈
| 项 | 值 |
| --- | --- |
| Name | CorTst_ConfigType |
| Type | Structure |
| Range | 实现特定 |
| Description | CorTst 模块的配置数据结构 |
| Available via | CorTst.h |
⌋ (SRS_BSW_00414)
#### 8.2.2 CorTst_CsumSignatureType
[SWS_CorTst_00037] ⌈
| 项 | 值 |
| --- | --- |
| Name | CorTst_CsumSignatureType |
| Type | uint16, uint32 |
| Range | 16..32 bit - 大小取决于目标平台 |
| Description | 如果从 API 返回 checksum/signature 给 API 的调用者,这是 Core Test 返回值的类型 |
| Available via | CorTst.h |
⌋ (SRS_BSW_00331)
#### 8.2.3 CorTst_CsumSignatureBgndType
[SWS_CorTst_00176] ⌈
| 项 | 值 |
| --- | --- |
| Name | CorTst_CsumSignatureBgndType |
| Type | Structure |
| Element | uint8/uint16/uint32 - 实现特定类型;uint8/uint16/uint32 - CorTstTestIntervalId 的值,每次测试间隔开始时递增 |
| Description | 后台模式下测试签名的类型 |
| Available via | CorTst.h |
⌋ (SRS_CoreTst_14116)
#### 8.2.4 CorTst_ErrOkType
[SWS_CorTst_00038] ⌈
| 项 | 值 |
| --- | --- |
| Name | CorTst_ErrOkType |
| Type | Structure |
| Element | uint8/uint16/uint32 - CorTstTestIntervalId 的值;CorTst_ResultType returnvalue:CORTST_E_NOT_OK (Core Test 检测到至少一个测试错误)、CORTST_E_OKAY (Core test 通过且无错误)、CORTST_E_NOT_TESTED (无 Core Test 结果可用,默认) |
| Description | 如果从 API 返回状态给 API 的调用者,这是 Core Test 测试返回的类型 |
| Available via | CorTst.h |
⌋ (SRS_BSW_00331)
[SWS_CorTst_00138] ⌈对于类型 CorTst_ErrOkType,枚举值 CORTST_E_NOT_TESTED 应在复位后为默认值。CorTstTestIntervalId 应默认值为零。⌋ ()
#### 8.2.5 CorTst_ResultType
[SWS_CorTst_01005] ⌈
| 项 | 值 |
| --- | --- |
| Name | CorTst_ResultType |
| Type | Enumeration |
| Range | CORTST_E_NOT_OK 0x00 (Core Test 检测到至少一个测试错误)<br>CORTST_E_OKAY 0x01 (Core test 通过且无错误)<br>CORTST_E_NOT_TESTED 0x02 (无 Core Test 结果可用,默认) |
| Description | 如果从 API 返回状态给 API 的调用者,这是 Core Test 测试返回的类型 |
| Available via | CorTst.h |
⌋ (SRS_CoreTst_14131)
#### 8.2.6 CorTst_StateType
[SWS_CorTst_00039] ⌈
| 项 | 值 |
| --- | --- |
| Name | CorTst_StateType |
| Type | Enumeration |
| Range | CORTST_ABORT 0x00 (Core Test 已被 API CorTst_Abort() 取消)<br>CORTST_INIT 0x01 (Core Test 已初始化且可以启动)<br>CORTST_UNINIT 0x02 (Core Test 可以被初始化)<br>CORTST_RUNNING_BGND 0x03 (Core Test 当前正在执行) |
| Description | 这是由 API CorTst_GetState() 返回的状态值 |
| Available via | CorTst.h |
⌋ (SRS_BSW_00331)
#### 8.2.7 CorTst_TestIdFgndType
[SWS_CorTst_00160] ⌈
| 项 | 值 |
| --- | --- |
| Name | CorTst_TestIdFgndType |
| Type | uint8, uint16, uint32 |
| Range | 8..32 bit - 大小取决于目标平台 |
| Description | 这是用于特定前台测试配置运行的参数(Id)的类型。该 Id 应在调用 API CorTst_Start(CorTst_TestIdFgndType TestId) 时使用 |
| Available via | CorTst.h |
⌋ (SRS_CoreTst_14113)
### 8.3 函数定义
这是为上层模块提供的函数列表。
#### 8.3.1 CorTst_Init
[SWS_CorTst_00040] ⌈
| 项 | 值 |
| --- | --- |
| Service name | CorTst_Init |
| Syntax | `void CorTst_Init(const CorTst_ConfigType* ConfigPtr)` |
| Service ID[hex] | 0x00 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | ConfigPtr - 指向所选配置集的指针 |
| Description | Core Test 初始化和状态变更的服务 |
| Available via | CorTst.h |
⌋ (SRS_BSW_00101, SRS_BSW_00406, SRS_BSW_00358, SRS_BSW_00414)
[SWS_CorTst_01004] ⌈配置指针 ConfigPtr 应始终具有 NULL_PTR 值。⌋ (SRS_BSW_00414)
注:配置指针 ConfigPtr 当前未使用,因此应设置为 NULL_PTR 值。
[SWS_CorTst_00041] ⌈函数 CorTst_Init 应使用用于内核测试的适当值初始化所有 CorTst 相关数据结构、全局变量、寄存器和特殊测试硬件(如存在)。⌋ (SRS_BSW_00101, SRS_SPAL_12057)
[SWS_CorTst_00179] ⌈函数 CorTst_Init 应仅初始化已配置的资源,不应触及配置文件中未配置的资源。⌋ (SRS_SPAL_12057, SRS_SPAL_12125)
[SWS_CorTst_00042] ⌈如果在 CORTST_UNINIT 状态调用驱动,执行状态将变为 CORTST_INIT。⌋ ()
[SWS_CorTst_00178] ⌈如果在不在 CORTST_UNINIT 状态时再次调用 CorTst_Init,应报告开发错误 CORTST_E_ALREADY_INITIALIZED。执行状态保持不变,忽略 API 调用 CorTst_Init()。⌋ ()
[SWS_CorTst_00044] ⌈在调用任何其他 CoreTest 函数之前(除了函数 CorTst_GetState 和 CorTst_GetVersionInfo),应首先调用函数 CorTst_Init。如果未遵循此顺序,应向 Default Error Tracer 报告错误代码 CORTST_E_UNINIT(如启用了开发错误检测)。⌋ (SRS_BSW_00406)
#### 8.3.2 CorTst_DeInit
[SWS_CorTst_00045] ⌈
| 项 | 值 |
| --- | --- |
| Service name | CorTst_DeInit |
| Syntax | `void CorTst_DeInit(void)` |
| Service ID[hex] | 0x01 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Description | 从 CORTST_ABORT 或 CORTST_INIT 切换到 CORTST_UNINIT 状态的服务 |
| Available via | CorTst.h |
⌋ (SRS_BSW_00336, SRS_SPAL_12163)
[SWS_CorTst_00046] ⌈函数 API CorTst_DeInit 应使用启动软件运行后(变量/结构)或上电后(HW-default)的默认值初始化所有数据结构、全局变量、寄存器和特殊测试硬件(如存在)。⌋ (SRS_BSW_00336)
[SWS_CorTst_00047] ⌈如果在 CORTST_INIT 状态:状态应从 CORTST_INIT 变为 CORTST_UNINIT 状态。⌋ ()
[SWS_CorTst_00136] ⌈如果在 CORTST_ABORT 状态:状态应从 CORTST_ABORT 变为 CORTST_UNINIT 状态。⌋ ()
[SWS_CorTst_00149] ⌈如果启用 DET 且 CORE Test 模块的状态为 CORTST_RUNNING_BGND,函数 CortTst_DeInit 应向 DET 报告错误值 CORTST_E_STATUS_FAILURE,然后立即返回。⌋ ()
#### 8.3.3 CorTst_Abort
[SWS_CorTst_00048] ⌈
| 项 | 值 |
| --- | --- |
| Service name | CorTst_Abort |
| Syntax | `void CorTst_Abort(void)` |
| Service ID[hex] | 0x02 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Description | 从 CORTST_INIT 变为 CORTST_ABORT 状态的服务 |
| Available via | CorTst.h |
⌋ (SRS_CoreTst_14126)
[SWS_CorTst_00049] ⌈如果当前状态是 CORTST_INIT,状态应从 CORTST_INIT 变为 CORTST_ABORT 状态。⌋ ()
[SWS_CorTst_00105] ⌈如果当前状态是 CORTST_RUNNING_BGND,状态应从 CORTST_RUNNING_BGND 变为 CORTST_ABORT 状态。⌋ ()
[SWS_CorTst_00050] ⌈当调用 CorTst_Abort 函数时,CorTst_MainFunction 应完成正在执行的当前原子序列,并应提供已完成的原子测试序列结果,然后从 CORTST_RUNNING_BGND 变为 CORTST_ABORT 状态。⌋ (SRS_CoreTst_14126)
[SWS_CorTst_00051] ⌈在调用 CorTst_Abort 后,CorTst_MainFunction 在由调度器调用时不应再次开始测试,直到通过再次调用 CorTst_DeInit 和 CorTst_Init 对 Core test 模块进行完全重新初始化。⌋ ()
[SWS_CorTst_00152] ⌈对 CorTst_Abort 的调用应将函数 CorTst_GetCurrentStatus 的结果设置为返回 CORTST_E_NOT_TESTED。⌋ ()
#### 8.3.4 CorTst_GetState
[SWS_CorTst_00053] ⌈
| 项 | 值 |
| --- | --- |
| Service name | CorTst_GetState |
| Syntax | `CorTst_StateType CorTst_GetState(void)` |
| Service ID[hex] | 0x03 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Return value | CorTst_StateType - 见类型定义 |
| Description | 立即返回当前执行的 Core Test 状态的服务 |
| Available via | CorTst.h |
⌋ (SRS_CoreTst_14118)
[SWS_CorTst_00054] ⌈函数 CorTst_GetState 应返回当前 Core Test 执行状态,无论当前执行哪个状态。允许在任何执行状态下调用此函数。⌋ (SRS_CoreTst_14118)
#### 8.3.5 CorTst_GetCurrentStatus
[SWS_CorTst_00055] ⌈
| 项 | 值 |
| --- | --- |
| Service name | CorTst_GetCurrentStatus |
| Syntax | `void CorTst_GetCurrentStatus(CorTst_ErrOkType* ErrOk)` |
| Service ID[hex] | 0x04 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (out) | ErrOk - 见类型定义 |
| Description | 获取上次执行的 Core Test 结果指示器的服务 |
| Available via | CorTst.h |
⌋ (SRS_CoreTst_14131)
[SWS_CorTst_00056] ⌈函数 CorTst_GetCurrentStatus 应返回上次完成的 Core Test 运行结果以及上次后台测试的 Test Interval Id。⌋ (SRS_CoreTst_14131)
[SWS_CorTst_00120] ⌈如果没有结果可用,函数 CorTst_GetCurrentStatus 应默认返回 CORTST_E_NOT_TESTED。⌋ ()
#### 8.3.6 CorTst_GetSignature
[SWS_CorTst_00057] ⌈
| 项 | 值 |
| --- | --- |
| Service name | CorTst_GetSignature |
| Syntax | `CorTst_CsumSignatureBgndType CorTst_GetSignature(void)` |
| Service ID[hex] | 0x05 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Return value | CorTst_CsumSignatureBgndType - 实现特定 |
| Description | 获取后台模式下上次执行的 Core Test 签名的服务 |
| Available via | CorTst.h |
⌋ (SRS_CoreTst_14115, SRS_CoreTst_14116)
[SWS_CorTst_00058] ⌈函数 CorTst_GetSignature 应返回当前挂起的 Core Test 结果签名和后台模式下上次完成测试运行的 Core Test Interval Id。⌋ (SRS_CoreTst_14116)
#### 8.3.7 CorTst_GetFgndSignature
[SWS_CorTst_00060] ⌈
| 项 | 值 |
| --- | --- |
| Service name | CorTst_GetFgndSignature |
| Syntax | `CorTst_CsumSignatureType CorTst_GetFgndSignature(void)` |
| Service ID[hex] | 0x06 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Return value | CorTst_CsumSignatureType - 实现特定 |
| Description | 获取前台模式下上次执行的 Core Test 签名的服务 |
| Available via | CorTst.h |
⌋ (SRS_CoreTst_14115, SRS_CoreTst_14116)
[SWS_CorTst_00061] ⌈函数 CorTst_GetFgndSignature 应返回前台模式下上次完成测试运行的 Core Test 结果签名类型。⌋ (SRS_CoreTst_14116)
#### 8.3.8 CorTst_Start
[SWS_CorTst_00064] ⌈
| 项 | 值 |
| --- | --- |
| Service name | CorTst_Start |
| Syntax | `Std_ReturnType CorTst_Start(CorTst_TestIdFgndType TestId)` |
| Service ID[hex] | 0x07 |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | TestId - 要执行的前台测试配置的 Id |
| Return value | Std_ReturnType - E_OK:前台测试已处理;E_NOT_OK:前台测试未被接受 |
| Description | 执行前台 Core Test 的服务 |
| Available via | CorTst.h |
⌋ (SRS_BSW_00357, SRS_CoreTst_14112, SRS_CoreTst_14113)
[SWS_CorTst_00065] ⌈函数 CorTst_Start 仅适用于前台模式 Core Test 操作。⌋ ()
[SWS_CorTst_00109] ⌈如果在调用此 API 时执行状态是 CORTST_RUNNING_BGND,函数应在不执行任何动作的情况下返回,返回值应为 E_OK。⌋ ()
[SWS_CorTst_00154] ⌈如果测试期间发生错误,如果内核仍能由软件可靠地报告错误,CorTst_Start 函数应向 DEM 报告扩展生产错误 CORTST_E_CORE_FAILURE(见 ECUC_CorTst_00157)为 DEM_EVENT_STATUS_PREFAILED。⌋ (SRS_BSW_00339, SRS_BSW_00422, SRS_BSW_00409, SRS_BSW_00466, SRS_BSW_00469)
[SWS_CorTst_01001] ⌈如果测试期间未发生错误,CorTst_Start 函数应向 DEM 报告扩展生产错误 CORTST_E_CORE_FAILURE 为 DEM_EVENT_STATUS_PREPASSED。⌋ (SRS_BSW_00339, SRS_BSW_00422, SRS_BSW_00409, SRS_BSW_00466, SRS_BSW_00469)
[SWS_CorTst_00161] ⌈如果启用了开发错误检测且参数 TestId 超出范围,应触发 DET 错误值 CORTST_E_PARAM_INVALID,函数应在不执行任何动作的情况下返回,返回值为 E_NOT_OK。⌋ (SRS_BSW_00323)
#### 8.3.9 CorTst_GetVersionInfo
[SWS_CorTst_00112] ⌈
| 项 | 值 |
| --- | --- |
| Service name | CorTst_GetVersionInfo |
| Syntax | `void CorTst_GetVersionInfo(Std_VersionInfoType* versioninfo)` |
| Service ID[hex] | 0x08 |
| Sync/Async | Synchronous |
| Reentrancy | Reentrant |
| Parameters (out) | versioninfo - 指向存储此模块版本信息位置的指针 |
| Description | 此服务返回此模块的版本信息 |
| Available via | CorTst.h |
⌋ (SRS_BSW_00004, SRS_BSW_00407, SRS_BSW_00003, SRS_BSW_00411)
[SWS_CorTst_00118] ⌈如果以 NULL 指针作为参数调用函数 CorTst_GetVersionInfo,它应立即返回不执行任何进一步动作。如果启用了 DET,此函数应向 DET 模块报告错误值 CORTST_E_PARAM_POINTER,然后在不执行任何进一步动作的情况下返回。⌋ (SRS_BSW_00407)
### 8.4 回调通知
由于 Core Test 模块是 MCAL 驱动模块,它不为较低层模块提供任何回调函数。
### 8.5 调度函数
详情请参阅 SWS_BSWGeneral 中第 8.5 章 "Scheduled functions"。
#### 8.5.1 CorTst_MainFunction
[SWS_CorTst_00067] ⌈
| 项 | 值 |
| --- | --- |
| Service name | CorTst_MainFunction |
| Syntax | `void CorTst_MainFunction(void)` |
| Service ID[hex] | 0x0b |
| Description | 由调度器周期性调用以执行 Core Test 处理 |
| Available via | SchM_CorTst.h |
⌋ (SRS_BSW_00433, SRS_CoreTst_14112, SRS_CoreTst_14114)
[SWS_CorTst_00068] ⌈如果 Core Test 间隔内的所有工作都已完成,函数 CorTst_MainFunction 应将状态设置为 CORTST_INIT。⌋ ()
[SWS_CorTst_00069] ⌈如果不需要在 Core Test 内执行任何工作,函数 CorTst_MainFunction 应将状态设置为 CORTST_INIT。⌋ ()
[SWS_CorTst_00070] ⌈如果 CoreTest 模块处于 CORTST_INIT 状态,对 API CorTst_MainFunction 的调用应将模块的状态变为 CORTST_RUNNING_BGND。⌋ ()
[SWS_CorTst_00071] ⌈CorTst_MainFunction 应测试 ECUC_CorTst_00087 中配置的所有选定内核硬件实体。⌋ ()
[SWS_CorTst_00072] ⌈函数 CorTst_MainFunction 应在每个完整测试周期后(该周期本身可能由多个不同的原子测试周期组成)根据 Core Test 的结果将 Core Test 结果状态设置为 CORTST_E_OKAY 或 CORTST_E_NOT_OK。⌋ ()
[SWS_CorTst_00073] ⌈只有在 CorTst_MainFunction 的每个所选原子部分都已成功执行且没有任何错误的情况下,才应将 CORTST_E_OKAY 设置为 CorTst_MainFunction 处理的状态。在所有其他情况下,CORTST_E_NOT_OK 作为当前状态返回。可通过调用 CorTst_GetCurrentStatus 检查状态。⌋ ()
[SWS_CorTst_00139] ⌈函数 CorTst_MainFunction 应在新测试间隔开始前递增 Test Interval Id。第一个测试间隔的 Test Interval Id 应始终 = "0" (=零)。如果 Test Interval Id 变得大于或等于 CorTstTestIntervalIdEndValue,Test Interval Id 应再次从值 "0" (=零) 开始,用于下一个测试间隔。该值应作为后台模式下 CorTst_GetSignature 和 CorTst_GetCurrentStatus 返回值的一部分提供。⌋ (SRS_CoreTst_14133)
[SWS_CorTst_00155] ⌈如果测试期间发生错误,如果内核仍能由软件可靠地报告错误,CorTest_MainFunction 函数应向 DEM 报告扩展生产错误 CORTST_E_CORE_FAILURE 为 DEM_EVENT_STATUS_PREFAILED。⌋ (SRS_BSW_00339, SRS_BSW_00422, SRS_BSW_00409, SRS_BSW_00466, SRS_BSW_00469)
[SWS_CorTst_01002] ⌈如果在 CorTst_MainFunction 调用期间完成核心测试且测试期间未发生错误,CorTst_MainFunction 函数应向 DEM 报告扩展生产错误 CORTST_E_CORE_FAILURE 为 DEM_EVENT_STATUS_PREPASSED。⌋ (SRS_BSW_00339, SRS_BSW_00422, SRS_BSW_00409, SRS_BSW_00466, SRS_BSW_00469)
### 8.6 预期接口
本章列出 Core Test 模块从其他模块所需的所有函数。
#### 8.6.1 强制接口
[SWS_CorTst_00177] ⌈
| API 函数 | 头文件 | 描述 |
| --- | --- | --- |
| Dem_SetEventStatus | Dem.h | 由 SW-Cs 或 BSW 模块调用以向 Dem 报告监视状态信息 |
⌋ (SRS_BSW_00339)
#### 8.6.2 可选接口
[SWS_CorTst_00183] ⌈
| API 函数 | 描述 |
| --- | --- |
| Det_ReportError | 报告开发错误的服务 |
⌋ (SRS_BSW_00369, SRS_BSW_00350)
#### 8.6.3 可配置接口
##### 8.6.3.1 CorTst Test Completed Notification
[SWS_CorTst_00076] ⌈
| 项 | 值 |
| --- | --- |
| Service name | CorTst_TestCompletedNotification |
| Syntax | `void CorTst_TestCompletedNotification(CorTst_ErrOkType ResultOfLastCorTstRun)` |
| Service ID[hex] | 0x0c |
| Sync/Async | Synchronous |
| Reentrancy | Non Reentrant |
| Parameters (in) | ResultOfLastCorTstRun - CORTST_E_OKAY:上次 Core Test 执行成功完成且无错误;CORTST_E_NOT_OK:上次 Core Test 执行完成但有错误 |
| Description | 每当执行完整测试周期时应调用函数 CorTst_TestCompletedNotification |
| Available via | CorTst.h |
⌋ (SRS_BSW_00359, SRS_BSW_00360, SRS_CoreTst_14119)
[SWS_CorTst_00077] ⌈Core Test 模块每次基于后台模式下 Core Test 原子部分组合执行完整 Core Test 周期时,应调用回调通知 CorTst_TestCompletedNotification。⌋ (SRS_CoreTst_14119, SRS_SPAL_00157)
[SWS_CorTst_00140] ⌈函数 CorTst_TestCompletedNotification 的调用应通过配置参数 CorTstNotificationSupported 在预编译时可配置。⌋ ()
---
## 9 序列图
### 9.1 Initialization
```
Generic Elements::CorTst «Module»
User CorTst::CorTst
CorTst_Init(ConfigPtr)
CorTst_Init
```
**图 4 – Core Test Init**
### 9.2 Deinitialization
```
Generic Elements::CoreTst «Module»
User CorTst::CorTst
CorTst_DeInit()
CorTst_DeInit
```
**图 5 – Core Test De-initialization**
### 9.3 Background Test
#### 9.3.1 Core Test 模块内的测试结果计算
序列描述了 CorTst_Init 后,BSW scheduler 周期性调用 CorTst_MainFunction,在状态变更为 CORTST_RUNNING 后执行测试。完成测试后通过 CorTst_TestCompletedNotification 通知,然后调用 CorTst_GetCurrentStatus 获取结果。
#### 9.3.2 提供给调用实体的 Core Test 签名
序列描述了 CorTst_GetSignature 用于在后台模式下获取签名,作为对 CorTst_GetCurrentStatus 的补充。
---
## 10 配置规范
### 10.1 如何阅读本章
详情请参阅 SWS_BSWGeneral 中第 10.1 章 "Introduction to configuration specification"。
[SWS_CorTst_01006] DRAFT ⌈Core Test 模块应拒绝具有实现不支持的分区映射的配置。⌋
### 10.2 容器与配置参数
#### 10.2.1 CorTst
| 项 | 值 |
| --- | --- |
| SWS Item | ECUC_CorTst_00125 |
| Module Name | CorTst |
| Module Description | CorTst 模块的配置 |
| Post-Build Variant Support | false |
| Supported Config Variants | VARIANT-LINK-TIME, VARIANT-PRE-COMPILE |
**包含的容器**:
- **CorTstBackgroundConfigSet** (0..*):多个配置集容器,定义后台模式
- **CorTstConfigApiServices** (1)
- **CorTstDemEventParameterRefs** (0..1):对 DemEventParameter 元素的引用容器
- **CorTstForegroundConfigSet** (1..*):多个配置集容器,定义前台模式
- **CorTstGeneral** (1)
#### 10.2.2 CorTstGeneral
| 项 | 值 |
| --- | --- |
| SWS Item | ECUC_CorTst_00081 |
| Container Name | CorTstGeneral |
**主要配置参数**:
- **CorTstDevErrorDetect** (ECUC_CorTst_00082):开关开发错误检测和通知的开/关
- **CorTstFgndTestNumber** (ECUC_CorTst_00159):此参数保留前台测试可用的测试配置数
- **CorTstNotificationSupported** (ECUC_CorTst_00083):指示是否支持通知的开关
- **CorTstTestIntervalIdEndValue** (ECUC_CorTst_00143):定义 Test Interval Id 的结束值
- **CorTstTestResultMode** (ECUC_CorTst_00086):启用 Core test 驱动内测试结果比较的开关。在此模式下,Core test 驱动不计算 Core test 结果 OK 或 NOTOK。在 Core test 驱动内不处理与参考值的比较
- **CorTstEcucPartitionRef** (ECUC_CorTst_00160):将 Core test 映射到零个或多个 ECUC partitions(Draft)
[SWS_CorTst_01007] DRAFT ⌈模块将作为每个分区中的独立实例运行,这意味着被调用的 API 仅针对它在其中被调用的分区。⌋
#### 10.2.3 CorTstSelect
| 项 | 值 |
| --- | --- |
| SWS Item | ECUC_CorTst_00089 |
| Container Name | CorTstSelect |
| Description | 此容器指定配置参数以选择前台模式和后台模式的各个测试。可用性是硬件和实现特定的 |
**主要配置参数**:
- **CorTstAddress** (ECUC_CorTst_00130):启用/禁用核心地址测试
- **CorTstAlu** (ECUC_CorTst_00129):启用/禁用核心 ALU 测试
- **CorTstCache** (ECUC_CorTst_00133):启用/禁用核心 cache 测试
- **CorTstInterrupt** (ECUC_CorTst_00128):启用/禁用核心中断测试
- **CorTstMemoryIf** (ECUC_CorTst_00131):启用/禁用核心内存接口测试
- **CorTstMpu** (ECUC_CorTst_00132):启用/禁用核心 MPU 测试
- **CorTstRegister** (ECUC_CorTst_00127):启用/禁用核心寄存器测试
#### 10.2.4 CorTstBackgroundConfigSet
| 项 | 值 |
| --- | --- |
| SWS Item | ECUC_CorTst_00087 |
| Container Name | CorTstBackgroundConfigSet |
| Description | 多个配置集容器,定义后台模式 |
**主要配置参数**:
- **CorTstBackgroundEcucPartitionRef** (ECUC_CorTst_00161):将后台测试配置映射到零个或一个 ECUC partitions(Draft)
**包含的容器**:
- **CorTstSelect** (1)
[SWS_CorTst_01008] DRAFT ⌈CorTstBackgroundEcucPartitionRef 引用的 ECUC partitions 应是 CorTstEcucPartitionRef 引用的 ECUC partitions 的子集。⌋
#### 10.2.5 CorTstForegroundConfigSet
| 项 | 值 |
| --- | --- |
| SWS Item | ECUC_CorTst_00088 |
| Container Name | CorTstForegroundConfigSet |
| Description | 多个配置集容器,定义前台模式 |
**主要配置参数**:
- **CorTstTestIdFgnd** (ECUC_CorTst_00158):此特定前台测试配置的 Id。该值应在调用 API CorTst_Start(CorTst_TestIdFgndType TestId) 时使用
- **CorTstForegroundEcucPartitionRef** (ECUC_CorTst_00162):将前台测试配置映射到零个或一个 ECUC partitions(Draft)
**包含的容器**:
- **CorTstSelect** (1)
#### 10.2.6 CorTstConfigApiServices
| 项 | 值 |
| --- | --- |
| SWS Item | ECUC_CorTst_00092 |
| Container Name | CorTstConfigApiServices |
**主要配置参数**:
- **CorTstAbortApi** (ECUC_CorTst_00094):从代码中添加/移除服务 CorTst_Abort()
- **CorTstGetCurrentStatus** (ECUC_CorTst_00104):从代码中添加/移除服务 CorTst_GetCurrentStatus()
- **CorTstGetFgndSignature** (ECUC_CorTst_00103):从代码中添加/移除服务 CorTst_GetFgndSignature()
- **CorTstGetSignature** (ECUC_CorTst_00097):从代码中添加/移除服务 CorTst_GetSignature()
- **CorTstGetStateApi** (ECUC_CorTst_00096):从代码中添加/移除服务 CorTst_GetState()
- **CorTstStartApi** (ECUC_CorTst_00093):从代码中添加/移除服务 CorTst_Start()
- **CorTstVersionInfoApi** (ECUC_CorTst_00098):从代码中添加/移除服务 CorTst_GetVersionInfo()
#### 10.2.7 CorTstDemEventParameterRefs
| 项 | 值 |
| --- | --- |
| SWS Item | ECUC_CorTst_00156 |
| Container Name | CorTstDemEventParameterRefs |
| Description | 对 DemEventParameter 元素的引用容器,在发生相应错误时应使用 API Dem_SetEventStatus 调用 |
**主要配置参数**:
- **CORTST_E_CORE_FAILURE** (ECUC_CorTst_00157):对发生 "CORE failure" 错误时应发出的 DemEventParameter 的引用
### 10.3 已发布信息
详情请参阅 SWS_BSWGeneral 中第 10.3 章 "Published Information"。
---
## 11 不适用的需求
[SWS_CorTst_00999] ⌈这些需求不适用于本规范。⌋ (SRS_BSW_00167, SRS_BSW_00168, SRS_BSW_00339, SRS_BSW_00344, SRS_BSW_00375, SRS_BSW_00383, SRS_BSW_00386, SRS_BSW_00398, SRS_BSW_00399, SRS_BSW_00404, SRS_BSW_00405, SRS_BSW_00409, SRS_BSW_00416, SRS_BSW_00417, SRS_BSW_00422, SRS_BSW_00423, SRS_BSW_00424, SRS_BSW_00425, SRS_BSW_00426, SRS_BSW_00428, SRS_BSW_00429, SRS_BSW_00432, SRS_BSW_00437, SRS_BSW_00438, SRS_BSW_00005, SRS_BSW_00006, SRS_BSW_00009, SRS_BSW_00010, SRS_BSW_00161, SRS_BSW_00162, SRS_BSW_00170, SRS_BSW_00171, SRS_BSW_00172, SRS_BSW_00301, SRS_BSW_00302, SRS_BSW_00306, SRS_BSW_00308, SRS_BSW_00309, SRS_BSW_00310, SRS_BSW_00312, SRS_BSW_00314, SRS_BSW_00318, SRS_BSW_00321, SRS_BSW_00325, SRS_BSW_00328, SRS_BSW_00330, SRS_BSW_00333, SRS_BSW_00334, SRS_BSW_00341, SRS_BSW_00346, SRS_BSW_00371, SRS_BSW_00374, SRS_BSW_00378, SRS_BSW_00379, SRS_BSW_00413, SRS_CoreTst_14125, SRS_CoreTst_14124)
---
## 翻译说明
- 本文档由 AUTOSAR CP 4.4.0 英文原文翻译。
- 模块缩写(Core Test、MCAL、CPU、MPU、MMU、MCU、DEM、DET、ALU、BSW、ECU、IRQ 等)保留原文。
- API 标识符(CorTst_Init、CorTst_DeInit、CorTst_Start 等)保留原文。
- 需求 ID(SWS_CorTst_xxxxx、SRS_CoreTst_xxxxx、SRS_BSW_xxxxx、ECUC_CorTst_xxxxx)保留原文。
- AUTOSAR 方括号符 `⌈ ⌋` 保留原貌,以保持需求结构的可追溯性。
- 版权声明保持英文原文。
- 跨文档引用以英文文件名形式保留。
- 错误代码(CORTST_E_UNINIT、CORTST_E_CORE_FAILURE 等)、状态枚举(CORTST_INIT、CORTST_RUNNING_BGND 等)、DEM 事件状态(DEM_EVENT_STATUS_PREFAILED、DEM_EVENT_STATUS_PREPASSED)等以英文枚举形式保留。
- 由于源文档大量使用图形和复杂表格,部分图形以简化的代码块形式展示,文字描述保持完整。
MCAL/AUTOSAR_SWS_GPTDriver.md
+1152
View File
File diff suppressed because it is too large Load Diff
MCAL/AUTOSAR_SWS_MCUDriver.md
+1041
View File
File diff suppressed because it is too large Load Diff