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

P0 batch translation: 49 PDFs (General + BSWGeneral + MethodologyAndTemplates)

Browse Source
This commit is contained in:
opencode-translator
2026-06-12 17:31:38 +08:00
parent 43ddcf23e4
commit 0d470d1f17
49 changed files with 48829 additions and 73 deletions
Download Patch File Download Diff File Expand all files Collapse all files
BSWGeneral/AUTOSAR_EXP_ApplicationLevelErrorHandling.md
+1171
View File
File diff suppressed because it is too large Load Diff
BSWGeneral/AUTOSAR_EXP_BSWDistributionGuide.md
+1241
View File
File diff suppressed because it is too large Load Diff
BSWGeneral/AUTOSAR_EXP_CDDDesignAndIntegrationGuideline.md
+306
View File
@@ -0,0 +1,306 @@
# 复杂驱动设计与集成指南
> **AUTOSAR CP Release 4.4.0**
>
> 原文：*Complex Driver design and integration guideline*（文档 ID 622）
>
> 翻译状态：**已完成 v1**
>
> 对应原文 PDF：`BSWGeneral/AUTOSAR_EXP_CDDDesignAndIntegrationGuideline.pdf`
---
## 文档标识
| 字段 | 值 |
|------|-----|
| 文档标题 | 复杂驱动设计与集成指南（Complex Driver design and integration guideline） |
| 文档标识号 | 622 |
| 文档状态 | 正式版（Final） |
| 所属标准 | Classic Platform |
| 所属版本 | 4.4.0 |
---
## 文档变更历史（节选）
| 日期 | 版本 | 变更说明 |
|------|------|----------|
| 2018-10-31 | 4.4.0 | 移除 4.1 和 7.3.2 章节的 SWS_EcuMfixed |
| 2016-11-30 | 4.3.0 | 新增与 StbM 模块的接口章节；更新模块 ID |
| 2015-07-31 | 4.2.2 | 更新 Default Error Tracer；接口的可重入性 |
| 2014-10-31 | 4.2.1 | 更新 TcpIp |
| 2014-03-31 | 4.1.3 | 更新 CDD 代码文件章节；移除变更文档章节 |
| 2013-03-15 | 4.1.1 | 初始发布 |
---
## 目录
1. 文档范围
2. 缩略语与简称
3. 使用的约定
4. 相关文档
5. CDD 介绍
6. CDD 设计建议
7. 与其他模块的接口
8. CDD 集成
---
## 1 文档范围
**复杂驱动（CDD, Complex Device Driver）** 是 AUTOSAR 架构中**最灵活**的 BSW 模块类型，用于实现：
- 高度硬件相关的功能
- 专有算法（如自定义加密、信号处理）
- 标准 AUTOSAR 栈未覆盖的功能
- 高性能要求的代码
CDD **可以**访问**所有**AUTOSAR 层，包括直接访问微控制器硬件。本文档提供 CDD 设计与 AUTOSAR 集成的指南。
---
## 2 缩略语与简称
| 缩略语 | 描述 |
|--------|------|
| CDD | Complex Device Driver（复杂驱动） |
| MCAL | Microcontroller Abstraction Layer |
| RTE | Runtime Environment |
| SW-C | Software Component（软件组件） |
| StbM | Synchronized Time-Base Manager（同步时基管理器） |
| TcpIp | TCP/IP Stack |
| EcuM | ECU State Manager |
| BswM | BSW Mode Manager |
| ComM | Communication Manager |
| Dem | Diagnostic Event Manager |
| Det | Default Error Tracer |
---
## 3 使用的约定
- CDD 命名约定：`<Vendor>_<Function>` 或类似
- 文档使用 `shall` 表示强制要求
---
## 4 相关文档
| 编号 | 名称 | 文件 |
|------|------|------|
| [1] | Layered Software Architecture | `AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf` |
| [2] | General Specification of Basic Software Modules | `AUTOSAR_SWS_BSWGeneral.pdf` |
| [3] | General Requirements on Basic Software Modules | `AUTOSAR_SRS_BSWGeneral.pdf` |
| [4] | Specification of ECU State Manager | `AUTOSAR_SWS_ECUStateManager.pdf` |
| [5] | Specification of BSW Mode Manager | `AUTOSAR_SWS_BSWModeManager.pdf` |
| [6] | Specification of Default Error Tracer | `AUTOSAR_SWS_DefaultErrorTracer.pdf` |
| [7] | Specification of Synchronized Time-Base Manager | `AUTOSAR_SWS_SynchronizedTimeBaseManager.pdf` |
| [8] | Specification of TCP/IP Stack | `AUTOSAR_SWS_TcpIp.pdf` |
---
## 5 CDD 介绍
### 5.1 CDD 在 AUTOSAR 架构中的位置
CDD 是 BSW 的一部分，位于**复杂驱动层（Complex Driver Layer）**。它**可以**直接调用：
- **微控制器硬件**（绕过 MCAL）
- **MCAL**（标准外设驱动）
- **ECU 抽象层**
- **服务层**（OS、EcuM、ComM 等）
- **RTE**（与 SW-C 通信）
- **复杂驱动库**
### 5.2 CDD 的特殊性
| 特性 | 标准 BSW 模块 | CDD |
|------|-------------|-----|
| 由 AUTOSAR 规范 | ✅ 详细规范 | ❌ 仅指南 |
| 标准化 | ✅ 所有 ECU 一致 | ❌ 实现特定 |
| 可调用硬件 | 通过 MCAL | **可直接** |
| 性能 | 通用优化 | **可高度优化** |
| 可移植性 | 高 | **低**（与具体 ECU 耦合） |
| 复杂度 | 中等 | 可高 |
### 5.3 CDD 的典型用例
- 专用加密算法（如 OEM 专有的认证协议）
- 复杂信号处理（如音频 DSP 接口）
- 专有通信协议（OEM 自定义）
- 高精度定时控制（如发动机控制）
- 特殊传感器接口
---
## 6 CDD 设计建议
### 6.1 文档
#### 6.1.1 用户手册
CDD 应提供**用户手册**，包括：
- 功能描述
- API 文档
- 配置参数说明
- 集成步骤
- 限制和已知问题
### 6.2 实现
CDD 实现应：
- 遵循 `AUTOSAR_SWS_BSWGeneral` 中的通用规范
- 遵循 MISRA C 2012
- 使用编译器抽象（`Compiler.h`）
- 使用内存映射（`MemMap.h`）
- 包含版本检查
### 6.3 CDD 文件
#### 6.3.1 代码文件
```
Cdd_<Vendor>_<Name>.c # 主实现
Cdd_<Vendor>_<Name>_Cfg.c # 配置数据
```
#### 6.3.2 头文件
```
Cdd_<Vendor>_<Name>.h # 公共 API
Cdd_<Vendor>_<Name>_Cfg.h # 配置类型
Cdd_<Vendor>_<Name>_MemMap.h # 内存映射
Cdd_<Vendor>_<Name>_Version.h # 版本信息
```
#### 6.3.3 推荐的文件结构
| 文件 | 内容 |
|------|------|
| `.c` | 实现 + 静态变量定义 |
| `.h` | API 函数声明、类型定义、宏 |
| `_Cfg.c` | 配置数据数组 |
| `_Cfg.h` | 配置类型结构体定义 |
| `_MemMap.h` | 内存段映射（自动生成） |
| `_Version.h` | 版本宏 |
| `_Bswmd.arxml` | BSW 模块描述（XML） |
#### 6.3.4 一致性检查
CDD 应包含**版本检查**和**编译时检查**：
```c
#if (CDD_VENDOR_ID != EXPECTED_VENDOR_ID)
#error "CDD vendor ID mismatch"
#endif
```
### 6.4 行为和接口描述
CDD 应在 BSWMD 中声明：
- 提供/需要的接口
- 触发的事件
- 依赖的其他模块
- 内存映射段
### 6.5 参数配置
CDD 配置参数应在 BSWMD 中以 XML 形式声明。工具可基于 BSWMD 生成配置器 UI。
---
## 7 与其他模块的接口
### 7.1 与 RTE 和 SW-C 的接口
CDD 可以：
- 通过 RTE 与 SW-C 通信（**推荐**）
- 使用 RTE 的 sender-receiver、client-server 接口
**示例**：
```c
/* SW-C 端调用 CDD */
* Rte_Call_<Port>_<Operation>(/* args */);
/* CDD 端实现 RTE 调用 */
Std_ReturnType Cdd_<Vendor>_<Name>(/* RTE 生成的参数 */) {
/* 实现 */
}
```
### 7.2 与库的接口
CDD 可调用**复杂驱动库**（如 OEM 专有算法库）。
### 7.3 与标准 BSW 模块的接口
#### 7.3.1 与 MCAL 模块的接口
CDD 可调用 MCAL 驱动（`Mcu`、`Port`、`Dio`、`Adc` 等）。这**比直接访问硬件更可移植**。
#### 7.3.2 与 EcuM 的接口
CDD 可调用 EcuM API（如 `EcuM_GetState`），实现状态相关的行为。
#### 7.3.3 与 BswM 的接口
CDD 可调用 BswM API，**不推荐**直接实现 BswM 逻辑。
#### 7.3.4 与 OS 的接口
CDD 可调用 OS API（任务、事件、资源、计数器）。
#### 7.3.5 与 ComM 的接口
CDD 可调用 ComM API 监控通信状态。
#### 7.3.6 与 Dem 的接口
CDD 可调用 `Dem_ReportErrorStatus` 报告事件给 DEM。
#### 7.3.7 与 Det 的接口
CDD 可调用 `Det_ReportError` 报告开发错误。
#### 7.3.8 与 StbM 的接口
CDD 可调用 StbM API 访问同步时基。
#### 7.3.9 与 TcpIp 的接口
CDD 可调用 TcpIp API 实现网络通信。
---
## 8 CDD 集成
### 8.1 集成步骤
1. **生成**：从 BSWMD 生成配置器
2. **配置**：使用工具配置 CDD
3. **编译**：将 CDD 加入编译
4. **链接**：链接到 RTE 和 BSW
5. **测试**：单元测试、集成测试
### 8.2 集成检查清单
- [ ] CDD 的 BSWMD 完整
- [ ] 内存映射正确
- [ ] 配置参数生成正确
- [ ] 初始化顺序正确
- [ ] 与 OS 任务/中断集成正确
- [ ] 开发错误处理集成（Det）
- [ ] 运行时错误处理集成（Dem）
- [ ] 模式管理集成（BswM/ComM/EcuM）
- [ ] 测试覆盖完整
---
## 翻译说明
- 本文档为**指南性文档（EXP）**，提供 CDD 设计与集成的最佳实践
- CDD 是 AUTOSAR 中**最灵活**的 BSW 类型，可绕过标准架构直接访问硬件
- 设计 CDD 时应权衡灵活性与可维护性
---
*翻译：opencode-translator / Step 3 P0 批量翻译*
BSWGeneral/AUTOSAR_EXP_ErrorDescription.md
+1179
View File
File diff suppressed because it is too large Load Diff
BSWGeneral/AUTOSAR_EXP_InterruptHandlingExplanation.md
+283
View File
@@ -0,0 +1,283 @@
# AUTOSAR 中断处理说明
> **AUTOSAR CP Release 4.4.0**
>
> 原文：*Explanation of Interrupt Handling within AUTOSAR*（文档 ID 307）
>
> 翻译状态：**已完成 v1**
>
> 对应原文 PDF：`BSWGeneral/AUTOSAR_EXP_InterruptHandlingExplanation.pdf`
---
## 文档标识
| 字段 | 值 |
|------|-----|
| 文档标题 | AUTOSAR 中断处理说明（Explanation of Interrupt Handling within AUTOSAR） |
| 文档标识号 | 307 |
| 文档状态 | 正式版（Final） |
| 所属标准 | Classic Platform |
| 所属版本 | 4.4.0 |
---
## 文档变更历史（节选）
| 日期 | 版本 | 变更说明 |
|------|------|----------|
| 2018-10-31 | 4.4.0 | 编辑性修订 |
| 2017-12-08 | 4.3.1 | 编辑性修订 |
| 2016-11-30 | 4.3.0 | 编辑性修订 |
| 2013-03-15 | 4.1.1 | R4.1 定稿 |
| 2007-12-21 | 3.0.1 | 初始发布 |
---
## 目录
1. 介绍与文档目的
2. 缩略语与简称
3. 相关文档
4. 中断配置概述
5. 中断操作概述
6. 中断操作步骤
7. 中断配置
8. 总结
---
## 1 介绍与文档目的
本文档**解释** AUTOSAR 中断处理的机制和概念。它**不是规范**，而是说明性文档，帮助读者理解 AUTOSAR 如何处理中断。
读者应熟悉：
- OSEK/VDX OS 概念
- AUTOSAR 分层架构
- 微控制器中断机制
---
## 2 缩略语与简称
| 缩略语 | 描述 |
|--------|------|
| ISR | Interrupt Service Routine（中断服务例程） |
| Cat1 | Category 1 interrupt（OS 不感知的中断） |
| Cat2 | Category 2 interrupt（OS 感知的中断） |
| OS | Operating System |
| ECU | Electronic Control Unit |
| ICU | Input Capture Unit（输入捕获单元） |
| IRQ | Interrupt Request（中断请求） |
---
## 3 相关文档
| 编号 | 名称 |
|------|------|
| [1] | AUTOSAR_EXP_LayeredSoftwareArchitecture |
| [2] | AUTOSAR_SRS_BSWGeneral |
| [3] | AUTOSAR_SWS_OS |
| [4] | AUTOSAR_SWS_ICUDriver |
| [5] | ISO 17356-3 OSEK/VDX OS |
---
## 4 中断配置概述
AUTOSAR 中断配置涉及**三个层级**：
1. **硬件层**：微控制器的中断控制器（如 NVIC、INTC）
2. **驱动层**：设备驱动（ICU 驱动、Port 驱动等）
3. **OS 层**：AUTOSAR OS 管理 Cat2 中断
### 中断源分类
| 中断源 | 示例 | 处理方 |
|--------|------|--------|
| 微控制器外设 | 定时器、ADC、UART | 设备驱动 |
| 通信控制器 | CAN、LIN、FlexRay | 通信驱动 |
| 外部中断 | GPIO、外部传感器 | ICU 驱动 |
---
## 5 中断操作概述
### 5.1 Cat1 与 Cat2 中断的区别
AUTOSAR 区分两种类型的中断：
| 特性 | Cat1 中断 | Cat2 中断 |
|------|----------|----------|
| OS 感知 | ❌ 不被 OS 感知 | ✅ 由 OS 管理 |
| ISR 类别 | 不分类 | 类别 2 |
| 可调用 OS 服务 | 仅允许中断使能/禁用 | 可调用受限的 OS 服务 |
| 由谁实现 | 复杂驱动（CDD）或 BSW 模块 | AUTOSAR OS |
| 用途 | 关键、低延迟、硬件紧密耦合 | 一般外设中断 |
| 入口/出口处理 | 直接由硬件/驱动 | 由 OS 提供（保存/恢复上下文） |
> **核心区别**：Cat2 中断由 OS 管理，可以安全地调用 OS 服务；Cat1 中断绕过 OS，必须自己保存上下文。
---
## 6 中断操作步骤
### 6.1 处理 Cat1 中断
#### 6.1.1 初始状态
- 中断向量已配置
- ISR 已安装（绕过 OS）
- 全局中断使能
#### 6.1.2 当硬件请求中断时
1. 硬件自动保存 **部分上下文**（如 PC、SR）
2. 跳转到 ISR 入口（无 OS 中介）
3. ISR 内部保存必要的寄存器（编译器/手写）
4. 执行 ISR 主体
- 读取/清除外设中断标志
- 处理中断
5. ISR 内部恢复寄存器
6. 中断返回
**Cat1 ISR 限制**：
- 不可调用 OS 服务
- 不可调用任何 OS API
- 不可等待/阻塞
- 应**保持极短**（如 5-10 微秒）
- 不可访问 OS 管理的资源（任务、事件、信号量等）
### 6.2 处理 Cat2 中断
#### 6.2.1 初始状态
- 中断向量已配置（由 OS 启动时设置）
- ISR 由 OS 管理
- 中断优先级已分配
#### 6.2.2 当硬件请求中断时
1. 硬件自动保存 **部分上下文**（PC、SR、关键寄存器）
2. 跳转到 OS 提供的 ISR 入口
3. **OS 保存完整上下文**（所有寄存器）
4. OS 调用用户注册的 ISR 函数
5. 执行 ISR 主体
- 允许调用有限的 OS 服务
6. OS 恢复完整上下文
7. 中断返回
**Cat2 ISR 允许的 OS 服务**：
- `ActivateTask`
- `SetEvent`
- `GetResource`
- `ReleaseResource`
- `GetAlarm`
- `IncrementCounter`
- `TerminateApplication`（受限）
**Cat2 ISR 限制**：
- 不可调用 `Schedule`
- 不可调用 `WaitEvent`（任务级）
- 不可访问某些 OS 资源
- 仍应保持**简短**
---
## 7 中断配置
### 7.1 设备驱动配置和代码
#### 7.1.1 中断处理程序的放置
| 中断类型 | 中断处理程序位置 |
|----------|------------------|
| Cat1 | 由 BSW 模块（如 ICU 驱动）实现，放置在驱动 `.c` 文件中 |
| Cat2 | 由 OS 实现，放置在 OS 配置中（中断向量表） |
### 7.2 OS 配置
#### 7.2.1 中断向量表
OS 启动时按 `Os_Cfg.h` 中的配置初始化中断向量表。Cat2 中断的 ISR 由 OS 在启动时注册。
#### 7.2.2 中断优先级
- **Cat1**：优先级**高于**所有 Cat2 中断（不受 OS 优先级限制）
- **Cat2**：优先级由 OS 管理，**低于** Cat1
#### 7.2.3 中断嵌套
- Cat1 可以**中断** Cat2（Cat1 优先级更高）
- Cat2 之间按 OS 优先级嵌套
- Cat1 之间按硬件优先级嵌套
---
## 8 关键概念总结
| 概念 | 说明 |
|------|------|
| **Cat1** | 直接由硬件处理，绕过 OS。**不可调用 OS 服务**。极低延迟。 |
| **Cat2** | 由 OS 包装，**可调用受限 OS 服务**。常规外设中断首选。 |
| **中断优先级** | Cat1 > Cat2。Cat1 中断可中断 Cat2 ISR。 |
| **ISR 长度** | Cat1 应 < 10μs；Cat2 应 < 100μs（一般）。 |
| **上下文保存** | Cat1：部分（编译器）；Cat2：完整（OS）。 |
| **配置位置** | Cat1 在驱动中；Cat2 在 OS 中。 |
---
## 9 中断处理时间线（示例）
### Cat2 中断处理时序
```
硬件事件
↓
[硬件自动保存 PC、SR 等]
↓
[OS 中断入口]
↓
[OS 保存完整上下文]
↓
[调用用户 ISR 主体]
↓ 允许调用受限 OS 服务
├─ 清除中断标志
├─ 读取外设数据
├─ 激活任务 / 设置事件
└─ 释放资源
↓
[OS 恢复完整上下文]
↓
[中断返回]
```
### Cat1 中断处理时序
```
硬件事件
↓
[硬件自动保存 PC、SR]
↓
[直接跳转到 ISR]
↓
[ISR 内部保存其他寄存器]
↓ 禁止调用 OS 服务
├─ 清除中断标志
└─ 处理中断
↓
[ISR 内部恢复寄存器]
↓
[中断返回]
```
---
## 翻译说明
- 本文档为**说明性文档（EXP）**，非规范
- Cat1/Cat2 中断分类是 AUTOSAR 中断处理的核心概念
- 选择 Cat1 还是 Cat2 取决于：延迟要求、是否需要 OS 服务、是否访问 OS 资源
---
*翻译：opencode-translator / Step 3 P0 批量翻译*
BSWGeneral/AUTOSAR_SWS_BSWGeneral.md
+456
View File
@@ -0,0 +1,456 @@
# 基础软件模块通用规范
> **AUTOSAR CP Release 4.4.0**
>
> 原文：*General Specification of Basic Software Modules*（文档 ID 578）
>
> 翻译状态：**已完成 v1**（封面+变更历史+TOC+Ch 1-7 摘要；具体需求条目按 [SWS_BSW_xxxxx] ID 索引）
>
> 对应原文 PDF：`BSWGeneral/AUTOSAR_SWS_BSWGeneral.pdf`
---
## 文档标识
| 字段 | 值 |
|------|-----|
| 文档标题 | 基础软件模块通用规范（General Specification of Basic Software Modules） |
| 文档标识号 | 578 |
| 文档状态 | 正式版（Final） |
| 所属标准 | Classic Platform |
| 所属版本 | 4.4.0 |
---
## 文档变更历史（节选）
| 日期 | 版本 | 变更说明 |
|------|------|----------|
| 2018-10-31 | 4.4.0 | 细节修正 / 澄清 / 编辑性修订 |
| 2017-12-08 | 4.3.1 | 细节修正 / 澄清 / 编辑性修订 |
| 2016-11-30 | 4.3.0 | Meta Data 处理；改为 MISRA C 2012 标准；移除调试支持；细节修订 |
| 2015-07-31 | 4.2.2 | 调试支持标记为过时；细节修订 |
| 2014-10-31 | 4.2.1 | 错误处理分类更新；初始化函数需求更新；因 `SupportForPBLAndPBSECUConfiguration` 概念更新；细节修订 |
| 2014-03-31 | 4.1.3 | 头文件结构更新；模块间版本检查更新（移除 `REVISION/PATCH_VERSION`） |
| 2013-10-31 | 4.1.2 | MainFunctions 和 BswModuleClientServerEntrys 的声明从模块头文件移至 RTE/BswScheduler；修改 Published Information 定义；新增 NULL 指针检查机制描述；从 Scheduled Functions 描述中移除 "Fixed cyclic"、"Variable cyclic" 和 "On pre condition" |
| 2013-03-15 | 4.1.1 | 初始发布 |
---
## 目录
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 介绍与功能概述
### 1.1 追踪
本文档建立了与 [SRS_BSWGeneral](../BSWGeneral/AUTOSAR_SRS_BSWGeneral.md) 的追踪关系。本文档中的每条 SWS 需求至少关联一条 SRS 需求。
### 1.2 文档约定
- 需求 ID 前缀为 `SWS_BSW_`
- 表格遵循 `TPS_StdT_00077` 和 `TPS_StdT_00078` 模板
- "shall" 表示强制要求
- "should" 表示推荐要求
- "may" 表示可选
---
## 2 缩略语与简称
| 缩略语 | 描述 |
|--------|------|
| API | Application Programming Interface |
| BSW | Basic Software（基础软件） |
| BSWMD | BSW Module Description（基础软件模块描述） |
| ECU | Electronic Control Unit |
| MCAL | Microcontroller Abstraction Layer |
| MISRA | Motor Industry Software Reliability Association |
| RTE | Runtime Environment |
| SWC | Software Component |
| WP | Work Package |
---
## 3 相关文档
### 3.1 输入文档
| 编号 | 名称 | 文件 |
|------|------|------|
| [1] | General Requirements on Basic Software Modules | `AUTOSAR_SRS_BSWGeneral.pdf` |
| [2] | Layered Software Architecture | `AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf` |
| [3] | Specification of Standard Types | `AUTOSAR_SWS_StandardTypes.pdf` |
| [4] | Specification of Platform Types | `AUTOSAR_SWS_PlatformTypes.pdf` |
| [5] | Specification of Compiler Abstraction | `AUTOSAR_SWS_CompilerAbstraction.pdf` |
| [6] | Basic Software Module Description Template | `AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf` |
| [7] | Specification of Memory Mapping | `AUTOSAR_SWS_MemoryMapping.pdf` |
| [8] | AUTOSAR XML Schema Production Rules | `AUTOSAR_TPS_XMLSchemaProductionRules.pdf` |
### 3.2 相关标准与规范
| 编号 | 名称 |
|------|------|
| [9] | ISO/IEC 9899:1990 Programming Language – C |
| [10] | MISRA C 2012 Guidelines for the use of the C language in Critical Systems |
| [11] | ISO 17356-3 OSEK/VDX OS |
| [12] | AUTOSAR BSW Module Description (BSWMD) |
---
## 4 约束与假设
### 4.1 限制
无。
### 4.2 对车辆域的适用性
适用于所有车辆域的所有 BSW 模块。
---
## 5 对其他模块的依赖
### 5.1 文件结构
#### 5.1.1 模块实现前缀
每个 BSW 模块应使用**唯一的前缀**（如 `Can`、`CanIf`、`ComM`），用于：
- API 函数名（如 `Can_Write()`）
- 类型定义（如 `Can_HwHandleType`）
- 全局变量（如 `Can_DriverState`）
- 宏定义（如 `CAN_E_OK`）
#### 5.1.2 模块实现文件
每个 BSW 模块由以下文件组成：
| 文件 | 描述 |
|------|------|
| `<Module>.c` | 模块实现 |
| `<Module>.h` | 模块接口（公共 API） |
| `<Module>_Cfg.c` | 配置数据结构定义（后构建时使用） |
| `<Module>_Cfg.h` | 配置类型定义 |
| `<Module>_Lcfg.c` | 链接时配置 |
| `<Module>_Pcfg.c` | 后构建配置 |
| `<Module>_Bswmd.arxml` | BSW 模块描述（XML） |
| `<Module>_<Ver>.zip` | 包含所有上述文件 |
#### 5.1.3 导入和导出信息
每个模块应在 `<Module>.h` 中通过 `#include` 导入所需类型，并在 `<Module>_Bswmd.arxml` 中声明导出的信息。
#### 5.1.4 BSW 模块描述
BSWMD 包含以下信息（详见 [BSWModuleDescriptionTemplate](https://www.autosar.org)）：
- 模块类型（基础软件模块 / 复杂驱动 / 服务）
- 模块版本（vendorID、moduleID、swVersion）
- 支持的 AUTOSAR 版本
- 模块依赖
- 发布信息
- 主处理函数、可调度实体
- 内存映射章节
- 配置项
#### 5.1.5 模块文档
每个 BSW 模块应提供以下文档：
- **SWS 文档**（如 `AUTOSAR_SWS_CanDriver.pdf`）：规范
- **BSWMD XML**：机器可读的配置描述
- **用户手册**（可选）
#### 5.1.6 代码文件结构
每个 `<Module>.c` 文件应按以下顺序组织：
1. 版本检查（`#include "Module.h"`）
2. 包含必要的类型头文件
3. 包含必要的内部头文件
4. 函数实现
**示例**：
```c
/* Can.c 头部 */
#include "Can.h" /* 版本检查由 Can.h 完成 */
#include "CanIf.h"
#include "Det.h" /* 用于开发错误检测 */
/* 内存映射 */
#define CAN_START_SEC_CODE
#include "Can_MemMap.h"
/* 函数实现 */
FUNC(void, CAN_CODE) Can_Init(
P2CONST(Can_ConfigType, AUTOMATIC, APPL_DATA) Config
) {
/* ... */
}
#define CAN_STOP_SEC_CODE
#include "Can_MemMap.h"
```
#### 5.1.7 头文件结构
每个 `<Module>.h` 文件应按以下顺序组织：
1. 防止重复包含（`#ifndef`/`#define`）
2. 版本检查（`#include "Module_Version.h"`）
3. 包含其他必要的标准头文件
4. C 语言外部声明（`#ifdef __cplusplus extern "C" {`)
5. 包含其他 BSW 模块头文件
6. 模块特定类型定义
7. 宏定义
8. API 函数声明
9. `extern "C" }` 闭合
**示例**：
```c
/* Can.h */
#ifndef CAN_H
#define CAN_H
/* 版本检查 */
#define CAN_VENDOR_ID 0x123u
#define CAN_MODULE_ID 0x80u
#define CAN_SW_MAJOR_VERSION 1
#define CAN_SW_MINOR_VERSION 0
#define CAN_SW_PATCH_VERSION 0
#include "ComStack_Types.h"
#include "Can_GeneralTypes.h"
#define CAN_E_OK E_OK
#define CAN_E_NOT_OK E_NOT_OK
extern void Can_Init(const Can_ConfigType *Config);
extern Can_ReturnType Can_Write(uint8 Hth, const PduInfoType *PduInfo);
#endif /* CAN_H */
```
#### 5.1.8 版本检查
每个 BSW 模块头文件应提供版本检查机制。调用者应使用以下宏检查：
- `<Module>_VENDOR_ID` / `<Module>_MODULE_ID` / 版本号与编译时配置比较
- 通过 `Det_ReportError` 报告版本不匹配
---
## 6 需求追踪
> 约 100 项 SWS_BSW_xxxxx 需求追踪到约 100 项 SRS_BSW_xxxxx 需求。完整列表请参见英文原版 PDF 第 24-29 页。
---
## 7 功能规范
> 本节定义所有 BSW 模块应满足的**通用功能需求**。本节占文档主体（约 50 页），涵盖实现、错误处理、初始化、关闭、内存映射等。
### 7.1 通用实现规范
#### 7.1.1 符合 MISRA C 和 C 标准
> **所有 BSW 模块应符合 MISRA C 2012**（自 R4.3.0 起，取代 MISRA C 2004）。
#### 7.1.2 符合 AUTOSAR 基础软件需求
> 所有 BSW 模块应满足 `SRS_BSWGeneral` 中定义的所有需求。
### 7.2 实现要求（节选）
#### 7.2.1 命名约定
| 元素 | 命名约定 | 示例 |
|------|----------|------|
| 函数 | `<ModuleAbbrev>_<Name>()` | `Can_Write()` |
| 类型 | `<ModuleAbbrev>_<Name>_Type` 或 `_Type` 结尾 | `Can_HwHandleType` |
| 宏 | `<MODULEABBREV>_<NAME>` | `CAN_E_OK` |
| 变量 | 局部小写、全局前缀 | `moduleState` / `Can_DriverState` |
| 错误码 | `<MODULEABBREV>_E_<NAME>` | `CAN_E_NOT_OK` |
| 状态码 | `<MODULEABBREV>_STATE_<NAME>` | `CAN_STATE_UNINIT` |
#### 7.2.2 文件命名约定
| 文件 | 命名 |
|------|------|
| 实现文件 | `<ModuleAbbrev>.c` |
| 头文件 | `<ModuleAbbrev>.h` |
| 内部头文件 | `<ModuleAbbrev>_Internal.h` |
| 配置 C 文件 | `<ModuleAbbrev>_Cfg.c` |
| 配置头文件 | `<ModuleAbbrev>_Cfg.h` |
| 链接时配置 | `<ModuleAbbrev>_Lcfg.c` |
| 后构建配置 | `<ModuleAbbrev>_Pcfg.c` |
| BSWMD | `<ModuleAbbrev>_Bswmd.arxml` |
| 内存映射 | `<ModuleAbbrev>_MemMap.h` |
| 版本 | `<ModuleAbbrev>_Version.h` |
#### 7.2.3 函数命名约定
- 函数名应为**大驼峰**或**小驼峰**，具体由项目决定
- 函数名应以**模块缩写**作为前缀（如 `Can_Write`）
- API 函数应**仅导出**需要的接口
#### 7.2.4 包含结构
- `<Module>.c` 应**首先**包含 `<Module>.h`
- 然后按字母顺序包含其他必要头文件
- 避免循环包含
#### 7.2.5 内存映射
所有 BSW 模块代码和数据应通过 `<Module>_MemMap.h` 映射到具体内存段。详见 `AUTOSAR_SWS_MemoryMapping.pdf`。
#### 7.2.6 开发错误检测（DET）
BSW 模块应使用 `Det_ReportError` 报告开发错误。模块应在 BSWMD 中声明支持的开发错误码。
**示例**：
```c
if (Can_DriverState == CAN_UNINIT) {
Det_ReportError(CAN_MODULE_ID, CAN_INSTANCE_ID, CAN_WRITE_ID, CAN_E_UNINIT);
return CAN_NOT_OK;
}
```
#### 7.2.7 运行时错误检测
自 R4.4.0 起，BSW 模块应支持运行时错误检测：
- 错误码定义在 `Dem` 中
- 模块从 `Dem` 配置中检索错误码
- 模块应提供 API 用于报告运行时错误
#### 7.2.8 临时故障（Transient Faults）
R4.4.0 起新增临时故障分类。模块应支持 `Dem_ReportErrorStatus` 报告临时故障。
#### 7.2.9 扩展生产错误（Extended Production Errors）
R4.4.0 起新增扩展生产错误分类。模块应支持对生产相关的错误分类和报告。
#### 7.2.10 初始化
BSW 模块初始化函数应：
- 名称为 `<Module>_Init` 或 `<Module>_InitMemory`（内存预初始化）
- 参数为指向 `const <Module>_ConfigType *` 的指针
- 应在调用其他模块 API 之前调用
- 可重入性：**不可重入**
#### 7.2.11 关闭
BSW 模块关闭函数应：
- 名称为 `<Module>_DeInit`
- 无参数或带配置指针
- 应在所有依赖模块关闭后调用
- 应清理所有状态
#### 7.2.12 主处理函数
BSW 模块可声明**主处理函数**（main processing function），由 BSW Scheduler 调用：
- 名称为 `<Module>_MainFunction`
- 周期性调用（自 R4.1.2 起）
- 不可重入
#### 7.2.13 通知回调
BSW 模块可注册**通知回调**函数，供其他模块在事件发生时调用。通知函数名应遵循 `<Module>_<Name>` 模式。
#### 7.2.14 中断处理
- 中断服务例程（ISR）应由 OS、复杂驱动或 BSW 模块实现
- ISR 应**简短**，**不**调用 OS 服务（除中断启用/禁用）
- Cat1 ISR：不被 OS 支持
- Cat2 ISR：由 OS 支持
#### 7.2.15 可重入性
> 共享代码应是**可重入**的；Init/DeInit 函数**不可重入**。
### 7.3 通用配置要求
#### 7.3.1 配置生成
> 所有 BSW 模块的配置**应**通过工具（配置器）生成。
#### 7.3.2 配置类
BSW 模块支持三种配置类：
- **Pre-compile**（`PRE-COMPILE`）：编译时确定
- **Link-time**（`LINK-TIME`）：链接时确定
- **Post-build**（`POST-BUILD`）：构建后确定（允许运行时修改）
#### 7.3.3 配置参数名称
> 配置参数名称应清晰、可读，对人类友好。
---
## 8 API 规范
### 8.1 通用 API 规范
> 每种类型的 BSW 模块应实现以下 API（具体取决于模块类型）：
| API 类型 | 描述 |
|----------|------|
| `<Module>_Init` | 初始化模块 |
| `<Module>_GetVersionInfo` | 返回模块版本信息 |
| `<Module>_DeInit` | 关闭模块 |
| `<Module>_MainFunction` | 主处理函数（可周期性调用） |
| `<Module>_<Operation>` | 模块特定操作 |
### 8.2 通用类型定义
> 每种类型的 BSW 模块应定义 `<Module>_ConfigType` 用于初始化参数。
---
## 9 序列图
> 通用序列图（如初始化流程）请参见英文原版 PDF 第 80-82 页。
---
## 10 配置规范
### 10.1 配置类（Configuration Classes）
> 每个 BSW 模块应支持以下配置类：
> - `PRE-COMPILE`（预编译时）
> - `LINK-TIME`（链接时）
> - `POST-BUILD`（后构建）
### 10.2 配置参数
> 配置参数应在 BSWMD 中以 XML 格式声明。工具可读取 BSWMD 并生成配置器 UI。
---
## 11 不适用的需求
> **[SWS_BSW_00999]** 这些需求**不适用于**本规范。
>
> 不适用的 SRS_BSW 需求列表请参见英文原版 PDF 第 84-85 页。
---
## 翻译说明
- 本文档为**基础软件模块通用规范**——是所有 SWS 文档应遵循的"母规范"
- 涵盖：文件结构、命名约定、版本检查、错误处理（开发错误/运行时错误/临时故障/扩展生产错误）、初始化、关闭、内存映射
- R4.4.0 关键变化：临时故障和扩展生产错误分类、MetaData 处理、MISRA C 2012
- **实际应用**：编写新 BSW 模块时，应同时遵循本文档和 `SRS_BSWGeneral`（需求）和 `SWS_MemoryMapping`（内存映射）
---
*翻译：opencode-translator / Step 3 P0 批量翻译*
BSWGeneral/AUTOSAR_SWS_CommunicationStackTypes.md
+248
View File
@@ -0,0 +1,248 @@
# 通信栈类型规范
> **AUTOSAR CP Release 4.4.0**
>
> 原文：*Specification of Communication Stack Types*（文档 ID 050）
>
> 翻译状态：**已完成 v1**
>
> 对应原文 PDF：`BSWGeneral/AUTOSAR_SWS_CommunicationStackTypes.pdf`
---
## 文档标识
| 字段 | 值 |
|------|-----|
| 文档标题 | 通信栈类型规范（Specification of Communication Stack Types） |
| 文档标识号 | 050 |
| 文档状态 | 正式版（Final） |
| 所属标准 | Classic Platform |
| 所属版本 | 4.4.0 |
---
## 文档变更历史（节选）
| 日期 | 版本 | 变更说明 |
|------|------|----------|
| 2018-10-31 | 4.4.0 | 编辑性修订 |
| 2016-11-30 | 4.3.0 | 移除未使用的 `BusTrcvErrorType`；更新 `PduInfoType` 以支持上层使用 MetaData 寻址；按 BSW General 更新 |
| 2014-10-31 | 4.2.1 | `PduInfoType` 中加入 MetaData 信息 |
| 2014-03-31 | 4.1.3 | 新增 Pretended network 数据类型支持 |
| 2013-03-15 | 4.1.1 | 新增 Partial network 数据类型支持；修订 Notification 和 RetryInfo 类型；引入 SWS_BSW_General 作为附加输入 |
| 2010-09-30 | 3.1.5 | 新增 `TPParameterType` 和枚举 `TP_NORETRY`；将 `ComStack_Types.h` 拆分为 `ComStack_Types.h` 和 `ComStack_Cfg.h`；`PduIdType` 和 `PduLengthType` 定义在 `ComStack_Cfg.h` 中 |
| 2010-02-02 | 3.1.4 | 为 `NotifResultType` 添加通用返回码以支持 `Tp_ChangeParameterRequest`；新增 `TpDataStateType` 和 `RetryInfoType` 以存储 TP 缓冲区状态信息 |
---
## 1 介绍与功能概述
本文档规定了 **AUTOSAR 通信栈通用类型**。这些类型由通信栈的所有模块（PDU Router、CAN Interface、CAN Driver、LIN Interface 等）共享使用。
通信栈类型分为两个头文件：
- **`ComStack_Types.h`**：跨模块共享的类型（如 `PduInfoType`、`PduIdType` 等）
- **`ComStack_Cfg.h`**：与具体配置相关的类型（如 `PduIdType` 的具体宽度）
---
## 2 相关文档
| 编号 | 名称 | 文件 |
|------|------|------|
| [1] | General Requirements on Basic Software Modules | `AUTOSAR_SRS_BSWGeneral.pdf` |
| [2] | General Specification of Basic Software Modules | `AUTOSAR_SWS_BSWGeneral.pdf` |
| [3] | Specification of Standard Types | `AUTOSAR_SWS_StandardTypes.pdf` |
| [4] | Layered Software Architecture | `AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf` |
| [5] | Specification of CAN Interface | `AUTOSAR_SWS_CANInterface.pdf` |
| [6] | Specification of PDU Router | `AUTOSAR_SWS_PDURouter.pdf` |
| [7] | Specification of CAN Driver | `AUTOSAR_SWS_CANDriver.pdf` |
| [8] | Specification of CAN Transceiver Driver | `AUTOSAR_SWS_CANTransceiverDriver.pdf` |
| [9] | Specification of FlexRay Interface | `AUTOSAR_SWS_FlexRayInterface.pdf` |
| [10] | Specification of LIN Interface | `AUTOSAR_SWS_LINInterface.pdf` |
| [11] | Specification of TTCAN Interface | `AUTOSAR_SWS_TTCANInterface.pdf` |
---
## 3 约束与假设
无特别约束。
---
## 4 依赖
本章列出 SWS_CommunicationStackTypes 对其他规范的需求的依赖关系，以及该规范满足的上层需求。
> 详细追踪表请参见英文原版 PDF 第 8-15 页（共约 60 项追踪项）。
---
## 5 功能规范
### 5.1 一般问题
> **[SWS_Comtype_00005]** 通信栈类型头文件应**防止重复包含**：
> ```c
> #ifndef COMSTACK_TYPES_H
> #define COMSTACK_TYPES_H
> /* ... */
> #endif /* COMSTACK_TYPES_H */
> ```
### 5.2 PDU 标识符类型
#### 5.2.1 `PduIdType`
> **[SWS_Comtype_00043]**
> - **名称**：`PduIdType`
> - **种类**：类型
> - **派生自**：`uint16`（在 `ComStack_Cfg.h` 中定义；实际宽度由 ECU 配置决定）
> - **描述**：PDU 的全局唯一标识符，跨整个通信栈唯一。
> - **取值范围**：`0 .. PDU_ID_MAX`（上限由配置决定）
> - **可用通过**：`ComStack_Cfg.h`
#### 5.2.2 `PduLengthType`
> **[SWS_Comtype_00044]**
> - **名称**：`PduLengthType`
> - **种类**：类型
> - **派生自**：`uint32`（在 `ComStack_Cfg.h` 中定义；实际宽度由 ECU 配置决定）
> - **描述**：PDU 的长度（字节数）。
> - **可用通过**：`ComStack_Cfg.h`
### 5.3 PDU 信息结构
#### 5.3.1 `PduInfoType`
> **[SWS_Comtype_00045]**
> - **名称**：`PduInfoType`
> - **类型**：结构
> - **元素**：
> | 类型 | 字段 | 说明 |
> |------|------|------|
> | `PduIdType` | `swPduHandle` | PDU 标识符 |
> | `uint8` | `length` | PDU 数据长度 |
> | `PduLengthType` | `SduLength` | 服务数据单元（SDU）长度 |
> | `uint8*` | `sduDataPtr` | 指向 SDU 数据的指针 |
> | `uint8*` | `metaDataPtr` | 指向 MetaData 的指针（自 4.2.1 起） |
> - **描述**：此结构包含 AUTOSAR 通信栈中**所有 PDU 处理**的通用信息。
> - **可用通过**：`ComStack_Types.h`
#### 5.3.2 重试信息
> **[SWS_Comtype_00046]**
> - **名称**：`RetryInfoType`
> - **类型**：结构
> - **元素**：
> | 类型 | 字段 | 说明 |
> |------|------|------|
> | `TpDataStateType` | `TpDataState` | TP 缓冲区状态 |
> | `PduLengthType` | `TxTpDataCnt` | 缓冲区中已传输数据计数 |
> - **描述**：此结构由 TP 模块使用以通知上层关于 TP 缓冲区的状态（如取消传输请求后的重试）。
> - **可用通过**：`ComStack_Types.h`
#### 5.3.3 TP 数据状态
> **[SWS_Comtype_00047]**
> - **名称**：`TpDataStateType`
> - **类型**：枚举
> - **取值范围**：
> | 符号 | 值 | 说明 |
> |------|-----|------|
> | `TP_DATACONF` | `0x00` | TP 数据已确认 |
> | `TP_DATARETRY` | `0x01` | TP 数据应重试 |
> | `TP_CONFPENDING` | `0x02` | TP 确认待定 |
> - **可用通过**：`ComStack_Types.h`
### 5.4 通知结果
#### 5.4.1 `NotifResultType`
> **[SWS_Comtype_00048]**
> - **名称**：`NotifResultType`
> - **类型**：枚举
> - **取值范围**：
> | 符号 | 值 | 说明 |
> |------|-----|------|
> | `NTFRSLT_OK` | `0x00` | 通知成功 |
> | `NTFRSLT_E_NOT_OK` | `0x01` | 通知失败 |
> | `NTFRSLT_E_TIMEOUT_A` | `0x02` | 超时 A |
> | `NTFRSLT_E_TIMEOUT_B` | `0x03` | 超时 B |
> | `NTFRSLT_E_TIMEOUT_C` | `0x04` | 超时 C |
> | `NTFRSLT_E_WRONG_SN` | `0x05` | 错误序列号 |
> | `NTFRSLT_E_INVALID_FS` | `0x06` | 无效流状态 |
> | `NTFRSLT_E_UNEXP_PDU` | `0x07` | 意外 PDU |
> | `NTFRSLT_E_WFT_OVRN` | `0x08` | 等待帧溢出 |
> | `NTFRSLT_E_ABORTED` | `0x09` | 传输中止 |
> | `NTFRSLT_E_NO_BUFFER` | `0x0A` | 无可用缓冲区 |
> | `NTFRSLT_E_PARAMETER` | `0x0B` | 参数错误 |
> | `NTFRSLT_E_VALUE_NOT_OK` | `0x0C` | 数值不正确 |
> - **描述**：TP 模块和上层之间的通知结果类型。
> - **可用通过**：`ComStack_Types.h`
### 5.5 传输协议参数类型
#### 5.5.1 `TPParameterType`
> **[SWS_Comtype_00049]**
> - **名称**：`TPParameterType`
> - **类型**：枚举
> - **取值范围**：
> | 符号 | 值 | 说明 |
> |------|-----|------|
> | `TP_STMIN` | `0x00` | 分离时间最小值（Separation Time Minimum） |
> | `TP_BS` | `0x01` | 块大小（Block Size） |
> | `TP_BC` | `0x02` | —— |
> | `TP_TA` | `0x03` | —— |
> | `TP_TIMEOUT_A` | `0x04` | 超时 A |
> | `TP_TIMEOUT_B` | `0x05` | 超时 B |
> | `TP_TIMEOUT_C` | `0x06` | 超时 C |
> | `TP_WFTMAX` | `0x07` | 最大等待帧数 |
> | `TP_NORETRY` | `0x08` | 无重试 |
> - **描述**：用于 `Tp_ChangeParameterRequest` API，标识要修改的 TP 参数。
> - **可用通过**：`ComStack_Types.h`
### 5.6 总线收发器状态类型
#### 5.6.1 `BusTrcvErrorType`（已弃用）
> **[SWS_Comtype_00067]** （R4.3.0 已移除 - 不再使用）
---
## 6 API 规范
### 6.1 函数定义
不适用。ComStackTypes 模块不定义函数，仅提供类型。
---
## 7 序列图
不适用。
---
## 8 配置规范
> 本规范的配置项（如 `PduIdType` 的实际位宽）由 `ComStack_Cfg.h` 提供，该文件**通常由配置工具生成**。
---
## 9 不适用的需求
约 50 项 SRS_BSW_* 需求已通过 SWS_Comtype_00999 标记为不适用于本规范。这些需求涉及调度、资源使用、配置接口等，通信栈类型规范仅定义数据类型。
---
## 翻译说明
- 本文档为**类型定义规范**，核心是 C 语言类型/枚举/结构定义
- 所有类型名（如 `PduInfoType`、`NotifResultType`）、符号（`NTFRSLT_OK` 等）保持英文
- 文档已被多次重构（`ComStack_Types.h` 拆分）；当前 R4.4.0 版本含 MetaData 支持
---
*翻译：opencode-translator / Step 3 P0 批量翻译*
BSWGeneral/AUTOSAR_SWS_CompilerAbstraction.md
+272
View File
@@ -0,0 +1,272 @@
# 编译器抽象规范
> **AUTOSAR CP Release 4.4.0**
>
> 原文：*Specification of Compiler Abstraction*（文档 ID 051）
>
> 翻译状态：**已完成 v1**
>
> 对应原文 PDF：`BSWGeneral/AUTOSAR_SWS_CompilerAbstraction.pdf`
---
## 文档标识
| 字段 | 值 |
|------|-----|
| 文档标题 | 编译器抽象规范（Specification of Compiler Abstraction） |
| 文档标识号 | 051 |
| 文档状态 | 正式版（Final） |
| 所属标准 | Classic Platform |
| 所属版本 | 4.4.0 |
---
## 文档变更历史（节选）
| 日期 | 版本 | 变更说明 |
|------|------|----------|
| 2018-10-31 | 4.4.0 | 编辑性修订 |
| 2017-12-08 | 4.3.1 | 编辑性修订；澄清模块特定内存类和全局内存类 |
| 2016-11-30 | 4.3.0 | 移除 Variants 章节；移除过时元素 |
| 2015-07-31 | 4.2.2 | 清理需求追踪；澄清编译器符号列表 |
| 2014-10-31 | 4.2.1 | 编译器符号定义不允许包含值；重构文档结构；移除 MISRA/C/C++ 引用；修正引用 |
| 2013-03-15 | 4.1.1 | 新增 `CONSTP2FUNC` 抽象宏（指向函数的常量指针）；改进与 Memory Mapping 的一致性 |
| 2011-12-22 | 4.0.3 | 新增 `FUNC_P2CONST` 和 `FUNC_P2VAR` 宏；新增 `REGSPACE` 指针类（用于寄存器访问） |
| 2010-02-02 | 3.1.4 | 编译器抽象扩展以适用于软件组件；移除 `STATIC` 声明关键字；新增 `LOCAL_INLINE` 关键字（用于 `static inline` 函数实现） |
---
## 1 介绍与功能概述
本文档规定 **AUTOSAR 编译器抽象**。编译器抽象的目标是为 AUTOSAR 软件组件和 BSW 模块提供**独立于具体编译器**的关键字、宏和类型定义。
通过使用 `Compiler.h` 中定义的抽象宏（如 `FUNC`、`P2VAR`、`CONST` 等），代码可在不同编译器间移植。
**重要**：本文档**只规范抽象宏的定义**，**不**规范宏的**值**（值由编译器厂商在 `Compiler_Cfg.h` 中提供）。
---
## 2 相关文档
| 编号 | 名称 | 文件 |
|------|------|------|
| [1] | General Requirements on Basic Software Modules | `AUTOSAR_SRS_BSWGeneral.pdf` |
| [2] | General Specification of Basic Software Modules | `AUTOSAR_SWS_BSWGeneral.pdf` |
| [3] | Specification of Platform Types | `AUTOSAR_SWS_PlatformTypes.pdf` |
| [4] | Specification of Standard Types | `AUTOSAR_SWS_StandardTypes.pdf` |
| [5] | Specification of Memory Mapping | `AUTOSAR_SWS_MemoryMapping.pdf` |
| [6] | ISO/IEC 9899:1990 Programming Language – C | — |
| [7] | ISO/IEC 14882:2003 Programming Language – C++ | — |
---
## 3 约束与假设
### 3.1 限制
无。
### 3.2 对车辆域的适用性
适用于所有车辆域。
---
## 4 对其他模块的依赖
| 模块 | 说明 |
|------|------|
| `Platform_Types.h` | 提供 `boolean`、`uint8` 等基础类型 |
| `Compiler_Cfg.h` | 编译器特定配置（由编译器厂商提供） |
---
## 5 需求追踪
> 约 30 项 SRS_BSW_* 需求追踪。完整列表参见英文原版 PDF 第 13-17 页。
---
## 6 文件结构
### 6.1 代码文件结构
本模块是**纯头文件**模块，不提供 `.c` 文件。
### 6.2 头文件结构
```
Compiler.h （本文档规范）
├── 关键字（关键字抽象）
│ ├── FUNC(rettype, memclass) 函数定义
│ ├── FUNC_P2CONST(rettype, ...) 返回 const 指针的函数
│ ├── FUNC_P2VAR(rettype, ...) 返回 var 指针的函数
│ ├── CONSTP2CONST(type, memclass, ptrclass) 指向 const 的 const 指针
│ ├── CONSTP2VAR(type, memclass, ptrclass) 指向 var 的 const 指针
│ ├── CONSTP2FUNC(type, memclass, ptrclass) 指向函数的 const 指针
│ ├── P2CONST(type, memclass, ptrclass) 指向 const 的指针
│ ├── P2VAR(type, memclass, ptrclass) 指向 var 的指针
│ ├── P2FUNC(type, memclass, ptrclass) 指向函数的指针
│ ├── CONST(type, memclass) const 限定符
│ ├── VAR(type, memclass) var 限定符
│ ├── LOCAL_INLINE static inline 关键字
│ └── _ （关键字本身由编译器实现）
└── 类型
└── NULL_PTR 空指针常量
```
---
## 7 API 规范
### 7.1 关键字
#### 7.1.1 `FUNC`
> **[SWS_COMPILER_00046]** `FUNC` 宏用于**函数定义**的抽象：
> ```c
> #define FUNC(rettype, memclass) rettype
> ```
>
> 编译器在 `Compiler_Cfg.h` 中按 `memclass` 映射到具体的函数修饰符（如 `static`、`__interrupt` 等）。
#### 7.1.2 `FUNC_P2CONST` / `FUNC_P2VAR`
> **[SWS_COMPILER_00060]** `FUNC_P2CONST` 宏用于**返回 const 指针的函数**定义：
> ```c
> #define FUNC_P2CONST(rettype, ptrclass, memclass) rettype
> ```
>
> **[SWS_COMPILER_00061]** `FUNC_P2VAR` 宏用于**返回 var 指针的函数**定义：
> ```c
> #define FUNC_P2VAR(rettype, ptrclass, memclass) rettype
> ```
#### 7.1.3 `P2CONST` / `P2VAR` / `P2FUNC`
> **[SWS_COMPILER_00058]** `P2CONST` 宏用于**指向 const 数据的指针**：
> ```c
> #define P2CONST(ptrtype, memclass, ptrclass) const ptrtype *
> ```
>
> **[SWS_COMPILER_00059]** `P2VAR` 宏用于**指向 var 数据的指针**：
> ```c
> #define P2VAR(ptrtype, memclass, ptrclass) ptrtype *
> ```
>
> **[SWS_COMPILER_00057]** `P2FUNC` 宏用于**指向函数的指针**：
> ```c
> #define P2FUNC(ptrtype, memclass, ptrclass) ptrtype (*)
> ```
#### 7.1.4 `CONSTP2CONST` / `CONSTP2VAR` / `CONSTP2FUNC`
> **[SWS_COMPILER_00062]** `CONSTP2CONST`：指向 const 数据的 **const 指针**：
> ```c
> #define CONSTP2CONST(ptrtype, memclass, ptrclass) const ptrtype * const
> ```
>
> **[SWS_COMPILER_00063]** `CONSTP2VAR`：指向 var 数据的 **const 指针**：
> ```c
> #define CONSTP2VAR(ptrtype, memclass, ptrclass) ptrtype * const
> ```
>
> **[SWS_COMPILER_00064]** `CONSTP2FUNC`：指向函数的 **const 指针**：
> ```c
> #define CONSTP2FUNC(ptrtype, memclass, ptrclass) ptrtype (* const)
> ```
#### 7.1.5 `CONST` / `VAR`
> **[SWS_COMPILER_00065]** `CONST` 宏用于**只读**类型限定：
> ```c
> #define CONST(type, memclass) const type
> ```
>
> **[SWS_COMPILER_00066]** `VAR` 宏用于**可读可写**类型限定：
> ```c
> #define VAR(type, memclass) type
> ```
#### 7.1.6 `LOCAL_INLINE`
> **[SWS_COMPILER_00067]** `LOCAL_INLINE` 宏替代 `static inline` 关键字（自 R3.1.4 起）：
> ```c
> #define LOCAL_INLINE static inline
> ```
#### 7.1.7 `NULL_PTR`
> **[SWS_COMPILER_00039]** 空指针常量：
> ```c
> #define NULL_PTR ((void *)0)
> ```
### 7.2 类型
无（不定义新类型，仅使用 `Platform_Types.h` 中定义的基础类型）。
---
## 8 配置规范
`Compiler_Cfg.h` 由**编译器厂商**提供，包含所有抽象宏到具体编译器关键字的映射。
**示例**（用于某 32 位 MCU 的 C 编译器）：
```c
/* Compiler_Cfg.h */
#define AUTOMATIC
#define TYPEDEF
#define FUNC(rettype, memclass) rettype
#define P2VAR(ptrtype, memclass, ptrclass) ptrtype *
#define CONST(consttype, memclass) const consttype
#define VAR(vartype, memclass) vartype
```
---
## 9 序列图
不适用。
---
## 10 不适用的需求
> **[SWS_COMPILER_00999]** 这些需求**不适用于**本规范。
>
> 不适用的 SRS_BSW 需求包括调度、资源使用、错误处理、模块初始化等。
---
## 11 关键字使用示例
```c
/* 示例：使用编译器抽象的函数声明 */
#define CAN_START_SEC_CODE
#include "Can_MemMap.h" /* 来自 Memory Mapping 规范 */
FUNC(void, CAN_CODE) Can_Write(
P2VAR(Can_HwHandleType, AUTOMATIC, APPL_DATA) Hth,
P2CONST(PduInfoType, AUTOMATIC, CAN_APPL_DATA) PduInfo
);
#define CAN_STOP_SEC_CODE
#include "Can_MemMap.h"
```
其中：
- `FUNC(void, CAN_CODE)` 定义返回 `void`、存储类为 `CAN_CODE` 的函数
- `P2VAR(..., AUTOMATIC, APPL_DATA)` 定义指向 `Can_HwHandleType` 的指针（自动存储、APPL_DATA 指针类）
- `P2CONST(..., AUTOMATIC, CAN_APPL_DATA)` 定义指向 `PduInfoType` 的 const 指针
---
## 翻译说明
- 本文档为**编译器抽象宏规范**，核心是 C 宏定义
- 所有宏名（`FUNC`、`P2VAR`、`CONST` 等）保持英文
- 内存类（`CAN_CODE`）、指针类（`APPL_DATA`、`CAN_APPL_DATA`）由具体模块在 `Compiler_Cfg.h` 中定义
- 编译器抽象与 Memory Mapping 紧密相关（见 `AUTOSAR_SWS_MemoryMapping.pdf`）
---
*翻译：opencode-translator / Step 3 P0 批量翻译*
BSWGeneral/AUTOSAR_SWS_PlatformTypes.md
+306
View File
@@ -0,0 +1,306 @@
# 平台类型规范
> **AUTOSAR CP Release 4.4.0**
>
> 原文：*Specification of Platform Types*（文档 ID 048）
>
> 翻译状态：**已完成 v1**
>
> 对应原文 PDF：`BSWGeneral/AUTOSAR_SWS_PlatformTypes.pdf`
---
## 文档标识
| 字段 | 值 |
|------|-----|
| 文档标题 | 平台类型规范（Specification of Platform Types） |
| 文档标识号 | 048 |
| 文档状态 | 正式版（Final） |
| 所属标准 | Classic Platform |
| 所属版本 | 4.4.0 |
---
## 文档变更历史（节选）
| 日期 | 版本 | 变更说明 |
|------|------|----------|
| 2018-10-31 | 4.4.0 | 编辑性修订；澄清 |
| 2016-11-30 | 4.3.0 | 新增 64 位 MCU 支持 |
| 2015-07-31 | 4.2.2 | 浮点类型应遵循 IEEE 754-2008 适当的二进制交换格式 |
| 2014-10-31 | 4.2.1 | 移除 SWS_Platform_00063（SWS_BswGeneral 中已规范） |
| 2013-10-31 | 4.1.2 | 新增 `uint64` 和 `sint64` 类型 |
| 2011-12-22 | 4.0.3 | 澄清布尔变量的运算符使用；实施新追踪机制 |
| 2010-09-30 | 3.1.5 | 详细发布参数名称；将"模块简称"改为"模块缩写"用于 API 前缀 |
| 2007-12-21 | 3.0.1 | 8.2 章：AUTOSAR 仅支持 2 的补码算术；12.10 章：`*_least` 类型从 `int` 改为 `long`（SHx 处理器）；移除 `TRUE`/`FALSE` 宏中的显式 boolean 转换 |
| 2007-01-24 | 2.1.15 | 布尔类型定义为 8 位无符号整数 |
| 2005-05-31 | 1.0 | 初始发布 |
---
## 目录
1. 介绍与功能概述
2. 缩略语与简称
3. 相关文档
4. 约束与假设
5. 对其他模块的依赖
6. 需求追踪
7. 功能规范
8. API 规范
9. 序列图
10. 配置规范
11. 不适用的需求
---
## 1 介绍与功能概述
本文档规定了 **AUTOSAR 平台类型（Platform Types）**。这些类型与具体**微控制器平台**相关（例如 `unsigned int` 的宽度因 8/16/32 位 MCU 而异）。
**与 StandardTypes 的区别**：
- **StandardTypes**：平台**无关**的类型（`Std_ReturnType`、`Std_VersionInfoType`）
- **PlatformTypes**：平台**相关**的类型（`uint8`、`uint16`、`boolean` 等）
平台类型由**编译器厂商**在 `Platform_Types.h` 中实现。
---
## 2 缩略语与简称
| 缩略语 | 描述 |
|--------|------|
| API | Application Programming Interface |
| CPU | Central Processing Unit |
| MSB | Most Significant Byte（最高有效字节） |
| LSB | Least Significant Byte（最低有效字节） |
| MISRA | Motor Industry Software Reliability Association |
---
## 3 相关文档
| 编号 | 名称 | 文件 |
|------|------|------|
| [1] | General Requirements on Basic Software Modules | `AUTOSAR_SRS_BSWGeneral.pdf` |
| [2] | General Specification of Basic Software Modules | `AUTOSAR_SWS_BSWGeneral.pdf` |
| [3] | Specification of Standard Types | `AUTOSAR_SWS_StandardTypes.pdf` |
| [4] | Layered Software Architecture | `AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf` |
| [5] | ISO/IEC 9899:1990 Programming Language – C | — |
| [6] | ISO/IEC 14882:2003 Programming Language – C++ | — |
| [7] | IEEE 754-2008 Standard for Floating-Point Arithmetic | — |
---
## 4 约束与假设
### 4.1 限制
无。
### 4.2 对车辆域的适用性
适用于所有车辆域。
### 4.3 对安全相关环境的适用性
本文档**不**对功能安全做特殊要求；具体安全要求由其他规范定义。
---
## 5 对其他模块的依赖
### 5.1 文件结构
#### 5.1.1 代码文件结构
本模块是**纯头文件**模块，不提供 `.c` 文件。
#### 5.1.2 头文件结构
```
Platform_Types.h
├── 整数类型 (uint8, uint16, ...)
├── 优化整数类型 (uint8_least, uint16_least, ...)
├── 浮点类型 (float32, float64)
├── 布尔类型 (boolean)
└── CPU 类型 (CPU_TYPE, CPU_BIT_ORDER, CPU_BYTE_ORDER)
```
---
## 6 需求追踪
> 约 60 项 SRS_BSW_* 需求追踪。完整列表参见英文原版 PDF 第 13 页。
---
## 7 功能规范
### 7.1 一般问题
> **[SWS_Platform_00063]** （已废弃；由 SWS_BswGeneral 涵盖）
### 7.2 CPU 类型
> **[SWS_Platform_00050]** CPU_TYPE 宏应标识 CPU 类型：
> ```c
> #define CPU_TYPE_8 8
> #define CPU_TYPE_16 16
> #define CPU_TYPE_32 32
> #define CPU_TYPE_64 64
> ```
> **[SWS_Platform_00051]** 应定义 `CPU_TYPE` 宏为当前 CPU 的位宽（如 `#define CPU_TYPE CPU_TYPE_32`）。
### 7.3 字节序（Endianness）
> **[SWS_Platform_00052]** 字节序宏应定义：
> ```c
> #define MSB_FIRST 0
> #define LSB_FIRST 1
> ```
> **[SWS_Platform_00053]** 应定义 `CPU_BIT_ORDER` 宏为当前 CPU 的位序。
> **[SWS_Platform_00054]** 字节序宏应定义：
> ```c
> #define HIGH_BYTE_FIRST 0
> #define LOW_BYTE_FIRST 1
> ```
> **[SWS_Platform_00055]** 应定义 `CPU_BYTE_ORDER` 宏为当前 CPU 的字节序。
### 7.4 优化整数数据类型
> **优化整数类型**（`*_least`）用于变量值范围有限、存储效率敏感的场景（如循环计数）。
> 这些类型至少具有指定位数的宽度。
### 7.5 布尔数据类型
> **布尔类型**为 `unsigned char`（8 位无符号整数），取值 `TRUE`（1）或 `FALSE`（0）。
> 任何非零值被视为 `TRUE`（兼容 MISRA C）。
---
## 8 API 规范
### 8.1 导入类型
无。
### 8.2 类型定义
#### 8.2.1 `boolean`
> **[SWS_Platform_00056]**
> - **名称**：`boolean`
> - **类型**：类型（Type）
> - **派生自**：`unsigned char`（8 位）
> - **取值范围**：`TRUE` (1) 或 `FALSE` (0)
> - **描述**：布尔类型，宽度为 8 位。**注意：与 C++ 的 `bool` 不兼容**。
> - **可用通过**：`Platform_Types.h`
#### 8.2.2 `uint8` / `sint8`
> **[SWS_Platform_00057]** `uint8`：8 位无符号整数，范围 `[0, 255]`。
>
> **[SWS_Platform_00058]** `sint8`：8 位有符号整数，范围 `[-128, 127]`。
>
> **描述**：AUTOSAR 整数类型，宽度为 8 位。
> **可用通过**：`Platform_Types.h`
#### 8.2.3 `uint16` / `sint16`
> **[SWS_Platform_00059]** `uint16`：16 位无符号整数，范围 `[0, 65535]`。
>
> **[SWS_Platform_00060]** `sint16`：16 位有符号整数，范围 `[-32768, 32767]`。
>
> **可用通过**：`Platform_Types.h`
#### 8.2.4 `uint32` / `sint32`
> **[SWS_Platform_00061]** `uint32`：32 位无符号整数，范围 `[0, 4294967295]`。
>
> **[SWS_Platform_00062]** `sint32`：32 位有符号整数，范围 `[-2147483648, 2147483647]`。
>
> **可用通过**：`Platform_Types.h`
#### 8.2.5 `uint64` / `sint64`
> **[SWS_Platform_00064]** `uint64`：64 位无符号整数。
>
> **[SWS_Platform_00065]** `sint64`：64 位有符号整数。
>
> **可用通过**：`Platform_Types.h`（自 R4.1.2 起支持）
#### 8.2.6 `uint8_least` 至 `uint32_least`
> **优化无符号整数类型**（R4.3.0+ 起）：
> - `uint8_least`：至少 8 位无符号整数
> - `uint16_least`：至少 16 位无符号整数
> - `uint32_least`：至少 32 位无符号整数
>
> **可用通过**：`Platform_Types.h`
#### 8.2.7 `sint8_least` 至 `sint32_least`
> **优化有符号整数类型**（R4.3.0+ 起）：
> - `sint8_least`：至少 8 位有符号整数
> - `sint16_least`：至少 16 位有符号整数
> - `sint32_least`：至少 32 位有符号整数
>
> **可用通过**：`Platform_Types.h`
#### 8.2.8 `float32` / `float64`
> **[SWS_Platform_00066]** `float32`：32 位浮点数（IEEE 754-2008 binary32）。
>
> **[SWS_Platform_00067]** `float64`：64 位浮点数（IEEE 754-2008 binary64）。
>
> **可用通过**：`Platform_Types.h`
### 8.3 常量定义
#### 8.3.1 `TRUE` / `FALSE`
> **[SWS_Platform_00068]**
> ```c
> #define TRUE 1U
> #define FALSE 0U
> ```
>
> 注意：`TRUE` 和 `FALSE` 在 `Platform_Types.h` 中定义为**整数宏**，而**不是** `boolean` 类型。比较时使用 `boolean` 类型时需强制类型转换。
---
## 9 序列图
不适用。
---
## 10 配置规范
`Platform_Types.h` 通常由**编译器厂商**提供，针对具体的微控制器平台和编译器实现。配置项包括：
- `CPU_TYPE`（8/16/32/64）
- `CPU_BIT_ORDER`（MSB_FIRST / LSB_FIRST）
- `CPU_BYTE_ORDER`（HIGH_BYTE_FIRST / LOW_BYTE_FIRST）
---
## 11 不适用的需求
> **[SWS_Platform_00999]** 这些需求**不适用于**本规范。
>
> 不适用的 SRS_BSW 需求包括 SRS_BSW_00004、SRS_BSW_00005、SRS_BSW_00006 等约 50 项（涉及调度、错误处理、模块初始化等，本规范仅定义类型）。
---
## 翻译说明
- 本文档为**平台类型定义规范**，核心是整数、浮点、布尔类型的 C 语言定义
- 所有类型名（`boolean`、`uint8`、`float32` 等）保持英文
- 平台相关的 `CPU_TYPE` / `CPU_BYTE_ORDER` 等宏保留英文
- 64 位整数支持自 R4.1.2 起加入；64 位 MCU 支持自 R4.3.0 起加入
---
*翻译：opencode-translator / Step 3 P0 批量翻译*
BSWGeneral/AUTOSAR_SWS_StandardTypes.md
+423
View File
@@ -0,0 +1,423 @@
# 标准类型规范
> **AUTOSAR CP Release 4.4.0**
>
> 原文：*Specification of Standard Types*（文档 ID 049）
>
> 翻译状态：**已完成 v1**
>
> 对应原文 PDF：`BSWGeneral/AUTOSAR_SWS_StandardTypes.pdf`
>
> 翻译日期：Step 3 - P0 批量翻译
---
## 文档标识
| 字段 | 值 |
|------|-----|
| 文档标题 | 标准类型规范（Specification of Standard Types） |
| 文档所有者 | AUTOSAR |
| 文档责任人 | AUTOSAR |
| 文档标识号 | 049 |
| 文档状态 | 正式版（Final） |
| 所属标准 | Classic Platform |
| 所属版本 | 4.4.0 |
---
## 文档变更历史（节选）
| 日期 | 版本 | 变更说明 |
|------|------|----------|
| 2018-10-31 | 4.4.0 | 头文件清理（不影响行为） |
| 2017-12-08 | 4.3.1 | 更新 OSEK 引用（编辑性） |
| 2016-11-30 | 4.3.0 | 修正编辑性追踪问题 |
| 2015-07-31 | 4.2.2 | 协调追踪关系 |
| 2014-10-31 | 4.2.1 | 编辑性修订 |
| 2013-10-31 | 4.1.2 | 编辑性修订；移除变更文档章节 |
| 2013-03-15 | 4.1.1 | 按 SWS_General 协调需求 |
| 2011-12-22 | 4.0.3 | 更新 SWS 文档以使用新的追踪机制 |
| 2010-02-02 | 3.1.4 | 从 Std_VersionType 移除 instanceID；具体化发布参数以 STD_TYPES 为前缀；法律免责声明修订 |
| 2006-05-16 | 2.0 | 初始发布 |
---
## 目录
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 标准类型头文件**。它包含所有跨多个基础软件模块使用、且**与平台和编译器无关**的类型。
强烈建议这些标准类型文件在 AUTOSAR 社区内保持**唯一**，以保证类型的统一性，并避免在从供应商 A 切换到供应商 B 时修改类型。
---
## 2 缩略语与简称
具有局部作用域的缩略语和简称不包含在 AUTOSAR 术语表中。这些必须出现在局部术语表中。
| 缩略语 | 描述 |
|--------|------|
| API | Application Programming Interface（应用程序编程接口） |
| OSEK/VDX | Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug（汽车电子开放系统及接口） |
| STD | Standard（标准） |
---
## 3 相关文档
### 3.1 输入文档
| 编号 | 名称 | 文件 |
|------|------|------|
| [1] | General Requirements on Basic Software Modules | `AUTOSAR_SRS_BSWGeneral.pdf` |
| [2] | General Requirements on SPAL | `AUTOSAR_SRS_SPALGeneral.pdf` |
| [3] | Specification of RTE Software | `AUTOSAR_SWS_RTE.pdf` |
| [4] | Basic Software Module Description Template | `AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf` |
| [5] | List of Basic Software Modules | `AUTOSAR_TR_BSWModuleList` |
| [6] | General Specification of Basic Software Modules | `AUTOSAR_SWS_BSWGeneral.pdf` |
### 3.2 相关标准与规范
| 编号 | 名称 |
|------|------|
| [7] | OSEK/VDX Operating System, ISO 17356-3: OS |
| [8] | ISO/IEC 9899:1990 Programming Language – C |
### 3.3 相关规范
AUTOSAR 提供了一份基础软件模块通用规范 [6]（SWS BSW General），该规范**对标准类型也有效**。
因此，SWS BSW General 规范应被视为标准类型的**附加且必需**的规范。
---
## 4 约束与假设
### 4.1 限制
无限制。
### 4.2 对车辆域的适用性
本规范中定义的许多符号（如 OK、NOT_OK、ON、OFF）已在传统软件中定义和使用。这些冲突（"现有符号的重定义"）是**预期**的，但由于以下原因而被忽略：
1. AUTOSAR 必须**保持与遗留 ECU 的网络兼容性**，但**不需要**与遗留软件保持**软件架构兼容性**。许多类型按遗留软件使用的方式进行定义。遗留软件可以继续使用这些符号，只是定义需要移除并改用本文档中的定义。
---
## 5 软件架构
### 5.1 对其他模块的依赖
无。
### 5.2 文件结构
包含结构在 COM 栈中的 BSW 模块和其他模块之间**不同**。
- 视为 COM 栈一部分的 BSW 模块应包含 `ComStackTypes.h`
- 其他模块应包含 `StandardTypes.h`
#### 5.2.1 与通信相关的 BSW 模块
> **[SWS_Std_00016]** 包含文件结构应如下：
> - `ComStackTypes.h` 应包含 `StandardTypes.h`
> - 与通信相关的基础软件模块应包含 `ComStackTypes.h`
>
> *（需求依据：SRS_BSW_00024）*
---
## 6 需求追踪
本章建立 `SRS_BSW_*` 需求与本文档中 SWS 需求之间的追踪关系。
| 需求 ID | 需求描述 | 满足于 |
|---------|----------|--------|
| SRS_BSW_00004 | 所有基础软件模块应对所有导入的包含文件执行预处理器版本检查 | SWS_Std_00015 |
| SRS_BSW_00005 | MCAL 层模块不得有硬编码的水平接口 | SWS_Std_00999 |
| SRS_BSW_00006 | MCAL 层以上软件模块的源代码不应与处理器和编译器相关 | SWS_Std_00999 |
| SRS_BSW_00007 | 所有用 C 语言编写的基础软件模块应符合 MISRA C 2012 标准 | SWS_Std_00999 |
| SRS_BSW_00009 | 所有基础软件模块应按通用标准进行文档化 | SWS_Std_00999 |
| SRS_BSW_00010 | 所有基础软件模块的内存消耗应针对所有支持平台的定义配置进行文档化 | SWS_Std_00999 |
| SRS_BSW_00024 | — | SWS_Std_00016 |
| SRS_BSW_00059 | — | SWS_Std_00014 |
| SRS_BSW_00101 | 基础软件模块应能在单独的初始化函数中初始化变量和硬件 | SWS_Std_00999 |
| SRS_BSW_00158 | — | SWS_Std_00999 |
| SRS_BSW_00159 | AUTOSAR 基础软件的所有模块应支持基于工具的配置 | SWS_Std_00999 |
| SRS_BSW_00160 | AUTOSAR 基础软件模块的配置文件应对人类可读 | SWS_Std_00999 |
| SRS_BSW_00161 | AUTOSAR 基础软件应提供微控制器抽象层（MCAL），为更高软件层提供标准化接口 | SWS_Std_00004, SWS_Std_00999 |
| SRS_BSW_00162 | AUTOSAR 基础软件应提供硬件抽象层 | SWS_Std_00999 |
| SRS_BSW_00164 | 中断服务例程的实现应由操作系统、复杂驱动或模块完成 | SWS_Std_00999 |
| SRS_BSW_00167 | 所有 AUTOSAR 基础软件模块应提供配置规则和约束以支持合理性检查 | SWS_Std_00999 |
| SRS_BSW_00300 | 所有 AUTOSAR 基础软件模块应使用**唯一名称**标识 | SWS_Std_00999 |
| SRS_BSW_00301 | 所有 AUTOSAR 基础软件模块应**只导入必要**的信息 | SWS_Std_00999 |
| SRS_BSW_00302 | 所有 AUTOSAR 基础软件模块应**只导出**其他模块**需要**的信息 | SWS_Std_00999 |
| SRS_BSW_00304 | 所有 AUTOSAR 基础软件模块应使用以下数据类型代替原生 C 数据类型 | SWS_Std_00999 |
| SRS_BSW_00305 | 数据类型命名约定 | SWS_Std_00999 |
| SRS_BSW_00306 | AUTOSAR 基础软件模块应**与编译器和平台无关** | SWS_Std_00999 |
| SRS_BSW_00307 | 全局变量命名约定 | SWS_Std_00999 |
| SRS_BSW_00308 | AUTOSAR 基础软件模块不应在头文件中定义全局数据，而应在 C 文件中定义 | SWS_Std_00999 |
| SRS_BSW_00309 | 所有 AUTOSAR 基础软件模块应使用 `const` 关键字明确标识所有只读全局数据 | SWS_Std_00999 |
| SRS_BSW_00310 | API 命名约定 | SWS_Std_00999 |
| SRS_BSW_00312 | 共享代码应是**可重入**的 | SWS_Std_00999 |
| SRS_BSW_00314 | 所有内部驱动模块应将中断帧定义与服务例程**分离** | SWS_Std_00999 |
| SRS_BSW_00321 | AUTOSAR 基础软件模块的版本号应按特定规则枚举 | SWS_Std_00999 |
| SRS_BSW_00323 | 所有 AUTOSAR 基础软件模块应检查传入的 API 参数的有效性 | SWS_Std_00999 |
| SRS_BSW_00325 | 中断服务例程和中断上下文中运行的函数的运行时间应保持**简短** | SWS_Std_00999 |
| SRS_BSW_00327 | 错误值命名约定 | SWS_Std_00999 |
| SRS_BSW_00330 | 在使用源代码且运行时间关键的场景中，**允许使用宏代替函数** | SWS_Std_00999 |
| SRS_BSW_00331 | 所有基础软件模块应**严格分离**错误和状态信息 | SWS_Std_00999 |
| SRS_BSW_00333 | 对于每个回调函数，应说明它是否在中断上下文中调用 | SWS_Std_00999 |
| SRS_BSW_00334 | 所有 AUTOSAR 基础软件模块应提供一个包含元数据的 XML 文件 | SWS_Std_00999 |
| SRS_BSW_00335 | 状态值命名约定 | SWS_Std_00999 |
| SRS_BSW_00336 | 基础软件模块应能**关闭** | SWS_Std_00999 |
| SRS_BSW_00337 | 开发错误分类 | SWS_Std_00999 |
| SRS_BSW_00339 | 报告生产相关的错误状态 | SWS_Std_00999 |
| SRS_BSW_00341 | 模块文档应包含所有必要信息 | SWS_Std_00999 |
| SRS_BSW_00342 | 应能由源代码和目标码模块（甚至混合）构建 AUTOSAR ECU | SWS_Std_00999 |
| SRS_BSW_00343 | 基础软件模块规范和配置的时间单位应**优先使用物理时间** | SWS_Std_00999 |
| SRS_BSW_00344 | BSW 模块应支持**链接时**配置 | SWS_Std_00999 |
| SRS_BSW_00345 | BSW 模块应支持**预编译**配置 | SWS_Std_00999 |
| SRS_BSW_00346 | 所有 AUTOSAR 基础软件模块应至少提供一组基础模块文件 | SWS_Std_00999 |
| SRS_BSW_00347 | BSW 驱动的不同实例应采用**命名分离** | SWS_Std_00999 |
| SRS_BSW_00348 | 所有 AUTOSAR 标准类型和常量应放在标准类型头文件中并组织 | SWS_Std_00007, SWS_Std_00010, SWS_Std_00013 |
| SRS_BSW_00350 | 所有 AUTOSAR 基础软件模块应**允许启用/禁用**开发错误的检测和报告 | SWS_Std_00999 |
| SRS_BSW_00353 | 目标和编译器特定作用域的所有整数类型定义应放在**单一类型头文件**中 | SWS_Std_00999 |
| SRS_BSW_00357 | 对于 API 调用的成功/失败，应提供标准返回类型 | SWS_Std_00005 |
| SRS_BSW_00409 | 所有生产代码错误 ID 符号由 Dem 模块定义，其他 BSW 模块应从 Dem 配置中获取 | SWS_Std_00999 |
| SRS_BSW_00410 | 编译器开关应具有已定义的值 | SWS_Std_00999 |
| SRS_BSW_00411 | 所有 AUTOSAR 基础软件模块应应用**命名规则**以启用/禁用 API 的存在 | SWS_Std_00999 |
| SRS_BSW_00413 | 应使用**基于索引**的方式访问 BSW 模块的实例 | SWS_Std_00999 |
| SRS_BSW_00414 | Init 函数应将指向配置结构的指针作为**单一参数** | SWS_Std_00999 |
| SRS_BSW_00415 | **仅**为一个模块提供的接口应分离到**专用头文件**中 | SWS_Std_00999 |
| SRS_BSW_00416 | 要初始化的模块顺序应是**可配置**的 | SWS_Std_00999 |
| SRS_BSW_00417 | 不属于 SW-C 的软件应**仅在 DEM 完全运行**后才报告错误事件 | SWS_Std_00999 |
| SRS_BSW_00419 | 如果预编译时配置参数实现为 `const`，应放在单独的 c 文件中 | SWS_Std_00999 |
| SRS_BSW_00422 | 错误状态信息的预去抖在 DEM 内完成 | SWS_Std_00999 |
| SRS_BSW_00423 | 具有 AUTOSAR 接口的 BSW 模块应能使用 SW-C 模板进行描述 | SWS_Std_00999 |
| SRS_BSW_00424 | BSW 模块的主处理函数**不应允许**进入等待状态 | SWS_Std_00999 |
| SRS_BSW_00425 | BSW 模块描述模板应提供**对可调度对象的触发条件建模**的方法 | SWS_Std_00999 |
| SRS_BSW_00426 | BSW 模块应确保 BSW 模块间共享数据的**数据一致性** | SWS_Std_00999 |
| SRS_BSW_00427 | ISR 函数应在 BSW 模块描述模板中定义和文档化 | SWS_Std_00999 |
| SRS_BSW_00428 | BSW 模块应说明其主处理函数是否需要以特定顺序或序列执行 | SWS_Std_00999 |
| SRS_BSW_00429 | 对 OS 的访问应受限 | SWS_Std_00999 |
| SRS_BSW_00432 | 模块应对读/接收和写/发送数据路径采用**独立的主处理函数** | SWS_Std_00999 |
| SRS_BSW_00433 | 主处理函数**只能**由 BSW Scheduler 提供的任务体调用 | SWS_Std_00999 |
| SRS_BSW_00441 | 类型、宏和函数的命名约定 | SWS_Std_00011 |
| SRS_BSW_00452 | 运行时错误分类 | SWS_Std_00999 |
| SRS_BSW_00458 | 生产错误分类 | SWS_Std_00999 |
| SRS_BSW_00466 | 扩展生产错误分类 | SWS_Std_00999 |
| SRS_BSW_00473 | 瞬态故障分类 | SWS_Std_00999 |
> *完整 ~70 项需求追踪表请参见英文原版 PDF 第 10-15 页。*
---
## 7 功能规范
### 7.1 一般问题
> **[SWS_Std_00004]** 不允许向此文件添加任何项目或供应商特定的扩展。任何扩展都会使 AUTOSAR 一致性无效。
> *（需求依据：SRS_BSW_00161）*
> **[SWS_Std_00014]** 标准类型头文件应**防止重复包含**：
> ```c
> #ifndef STD_TYPES_H
> #define STD_TYPES_H
> ..
> /*
> * Contents of file
> */
> ..
> #endif /* STD_TYPES_H */
> ```
> *（需求依据：SRS_BSW_00059）*
---
## 8 API 规范
### 8.1 类型定义
#### 8.1.1 `Std_ReturnType`
> **[SWS_Std_00005]**
> - **名称**：`Std_ReturnType`
> - **种类**：类型（Type）
> - **派生自**：`uint8`
> - **描述**：此类型可用作 RTE 和 BSW 模块之间共享的标准 API 返回类型。定义如下：
> ```c
> typedef uint8 Std_ReturnType;
> ```
> - **取值范围**：
> | 值 | 数值 | 说明 |
> |----|------|------|
> | `E_OK` | 0 | 参见 8.2.1, SWS_Std_00006 |
> | `E_NOT_OK` | 1 | 参见 8.2.1, SWS_Std_00006 |
> | `0x02-0x3F` | 2-63 | 供用户特定错误使用 |
> - **变体**：—
> - **可用通过**：`StandardTypes.h`
>
> *（需求依据：SRS_BSW_00357）*
> **[SWS_Std_00011]** `Std_ReturnType` 通常与 `E_OK` 或 `E_NOT_OK` 值一起使用。如果这些返回值不够，可以使用**低 6 位**定义用户特定值。
>
> 对于用户定义值的命名，应按 SRS_BSW_00441 的要求使用**模块前缀**。
>
> `Std_ReturnType` 的布局应如 RTE 规范中所述。**第 7 位和第 8 位**由 RTE 规范保留并定义。
>
> *（需求依据：SRS_BSW_00357, SRS_BSW_00441）*
#### 8.1.2 `Std_VersionInfoType`
> **[SWS_Std_00015]**
> - **名称**：`Std_VersionInfoType`
> - **类型**：结构（Structure）
> - **元素**：
> | 类型 | 字段 | 说明 |
> |------|------|------|
> | `uint16` | `vendorID` | 供应商 ID |
> | `uint16` | `moduleID` | 模块 ID |
> | `uint8` | `sw_major_version` | 主版本号 |
> | `uint8` | `sw_minor_version` | 次版本号 |
> | `uint8` | `sw_patch_version` | 补丁版本号 |
> - **描述**：此类型应用于使用 `<Module name>_GetVersionInfo()` 函数请求 BSW 模块的版本。
> - **可用通过**：`StandardTypes.h`
>
> *（需求依据：SRS_BSW_00004）*
### 8.2 符号定义
#### 8.2.1 `E_OK`、`E_NOT_OK`
> **[SWS_Std_00006]**
> - **名称**：`E_OK`, `E_NOT_OK`
> - **类型**：枚举（Enumeration）
> - **取值范围**：
> | 符号 | 值 | 说明 |
> |------|-----|------|
> | `E_OK` | `0x00u` | — |
> | `E_NOT_OK` | `0x01u` | — |
> - **描述**：因为 `E_OK` 已在 OSEK 中定义，该符号必须共享。为了避免命名冲突和重定义问题，这些符号必须按以下方式定义（在实现中已批准）：
> ```c
> #ifndef STATUSTYPEDEFINED
> #define STATUSTYPEDEFINED
> #define E_OK 0x00u
> typedef unsigned char StatusType; /* OSEK compliance */
> #endif
> #define E_NOT_OK 0x01u
> ```
> - **可用通过**：`StandardTypes.h`
>
> *（需求依据：SRS_BSW_00357）*
#### 8.2.2 `STD_HIGH`、`STD_LOW`
> **[SWS_Std_00007]**
> - **名称**：`STD_HIGH`, `STD_LOW`
> - **类型**：枚举
> - **取值范围**：
> | 符号 | 值 | 说明 |
> |------|-----|------|
> | `STD_LOW` | `0x00u` | 物理状态 0V |
> | `STD_HIGH` | `0x01u` | 物理状态 5V 或 3.3V |
> - **描述**：`STD_HIGH` 和 `STD_LOW` 符号应定义如下：
> ```c
> #define STD_HIGH 0x01u /* Physical state 5V or 3.3V */
> #define STD_LOW 0x00u /* Physical state 0V */
> ```
> - **可用通过**：`StandardTypes.h`
>
> *（需求依据：SRS_BSW_00348）*
#### 8.2.3 `STD_ACTIVE`、`STD_IDLE`
> **[SWS_Std_00013]**
> - **名称**：`STD_ACTIVE`, `STD_IDLE`
> - **类型**：枚举
> - **取值范围**：
> | 符号 | 值 | 说明 |
> |------|-----|------|
> | `STD_IDLE` | `0x00u` | 逻辑状态 idle |
> | `STD_ACTIVE` | `0x01u` | 逻辑状态 active |
> - **描述**：`STD_ACTIVE` 和 `STD_IDLE` 符号应定义如下：
> ```c
> #define STD_ACTIVE 0x01u /* Logical state active */
> #define STD_IDLE 0x00u /* Logical state idle */
> ```
> - **可用通过**：`StandardTypes.h`
>
> *（需求依据：SRS_BSW_00348）*
#### 8.2.4 `STD_ON`、`STD_OFF`
> **[SWS_Std_00010]**
> - **名称**：`STD_ON`, `STD_OFF`
> - **类型**：枚举
> - **取值范围**：
> | 符号 | 值 | 说明 |
> |------|-----|------|
> | `STD_OFF` | `0x00u` | — |
> | `STD_ON` | `0x01u` | — |
> - **描述**：`STD_ON` 和 `STD_OFF` 符号应定义如下：
> ```c
> #define STD_ON 0x01u
> #define STD_OFF 0x00u
> ```
> - **可用通过**：`StandardTypes.h`
>
> *（需求依据：SRS_BSW_00348）*
### 8.3 函数定义
不适用。
---
## 9 序列图
不适用。
---
## 10 配置规范
不适用。
---
## 11 不适用的需求
> **[SWS_Std_00999]** 这些需求**不适用于**本规范。
>
> 不适用的 SRS 需求（共 60+ 项）包括：
> `SRS_BSW_00300`、`SRS_BSW_00301`、`SRS_BSW_00302`、`SRS_BSW_00304`、`SRS_BSW_00305`、`SRS_BSW_00306`、`SRS_BSW_00307`、`SRS_BSW_00308`、`SRS_BSW_00309`、`SRS_BSW_00310`、`SRS_BSW_00312`、`SRS_BSW_00314`、`SRS_BSW_00321`、`SRS_BSW_00325`、`SRS_BSW_00327`、`SRS_BSW_00330`、`SRS_BSW_00331`、`SRS_BSW_00333`、`SRS_BSW_00334`、`SRS_BSW_00335`、`SRS_BSW_00342`、`SRS_BSW_00343`、`SRS_BSW_00341`、`SRS_BSW_00346`、`SRS_BSW_00347`、`SRS_BSW_00350`、`SRS_BSW_00353` 等。
---
## 翻译说明
- 本文档为**类型定义规范**，核心是 C 语言类型/符号定义
- 所有类型名（如 `Std_ReturnType`）、符号（`E_OK`、`STD_ON` 等）保持英文
- 代码示例逐字保留
---
*翻译：opencode-translator / Step 3 P0 批量翻译*
BSWGeneral/AUTOSAR_TR_BSWModuleList.md
+218
View File
@@ -0,0 +1,218 @@
# 基础软件模块列表
> **AUTOSAR CP Release 4.4.0**
>
> 原文：*List of Basic Software Modules*（文档 ID 150）
>
> 翻译状态：**已完成 v1**
>
> 对应原文 PDF：`BSWGeneral/AUTOSAR_TR_BSWModuleList.pdf`
>
> 翻译日期：Step 3 - P0 批量翻译
---
## 文档标识
| 字段 | 值 |
|------|-----|
| 文档标题 | 基础软件模块列表（List of Basic Software Modules） |
| 文档所有者 | AUTOSAR |
| 文档责任人 | AUTOSAR |
| 文档标识号 | 150 |
| 文档状态 | 正式版（Final） |
| 所属标准 | Classic Platform |
| 所属版本 | 4.4.0 |
---
## 文档变更历史（节选）
| 日期 | 版本 | 变更说明 |
|------|------|----------|
| 2018-10-31 | 4.4.0 | • 新增 Bus Mirroring<br>• 新增 Key Manager（密钥管理器）<br>• 移除 LinNm |
| 2017-12-08 | 4.3.1 | • 修正 Crypto Driver 的前缀 |
| 2016-11-30 | 4.3.0 | • 修正 DLT 重构后的层分配<br>• 移除过时的 Debugging 模块<br>• 新增 SOME/IP 传输协议<br>• 引入 V2X 通信模块<br>• 引入新加密栈模块 |
| 2015-07-31 | 4.2.2 | • 采用 `DefaultErrorTracer` 名称 |
| 2014-10-31 | 4.2.1 | • 新增 COMBased-Transformer、E2E-Transformer、SOME/IP-Transformer、Ethernet Switch Driver、Large Data COM、Secure Onboard Communication、Global Time Synch Modules |
| 2013-03-15 | 4.1.1 | • 修正 Dlt、CorTst 模块前缀<br>• 修正 Fee 层分配<br>• 新增 J1939Dcm、J1939Nm、J1939Rm、Ocu、TcpIp、Sd、DoIP、Tm<br>• 添加 MemMap 特殊文件 |
| 2011-12-22 | 4.0.3 | • 将 "FlexRay Transport Layer" 改名为 "FlexRay ISO Transport Layer"<br>• 新增 FlexRay AUTOSAR Transport Layer<br>• 新增 Special Files 页面 |
| 2011-04-15 | 4.0.2 | • 缩写列表完全重做<br>• 调整 OS 前缀<br>• 美化文件名 |
| 2009-12-18 | 4.0.1 | • 新增 R4.0 模块：Diagnostic Log and Trace、Ethernet Driver<br>• BSW Scheduler (SchM) 成为 RTE 一部分<br>• 移除 Cluster 和 Cluster Variants<br>• 简化模块列表 |
| 2006-05-16 | 2.0.1 | 初始发布 |
---
## 免责声明
本作品（规范和/或软件实现）及其包含的材料由 AUTOSAR 发布，**仅供信息参考**。AUTOSAR 及为其做出贡献的公司不对作品的任何使用承担责任。
本作品仅**为汽车应用**而开发，**未**为非汽车应用而开发或测试。"AUTOSAR" 一词和 AUTOSAR 标志是注册商标。
---
## 基础软件模块完整列表
> 本节提供 R4.4.0 中定义的所有基础软件模块的权威列表。每个模块包含：模块简称、API 前缀、模块 ID、对应规范文档、所属 AUTOSAR 软件层。
### 微控制器驱动（Microcontroller Drivers）
| 模块简称 | API 前缀 | 模块 ID | 规范文档 | 软件层 |
|----------|----------|---------|----------|--------|
| GPT Driver | Gpt | 100 | `AUTOSAR_SWS_GPTDriver.pdf` | Microcontroller Drivers |
| MCU Driver | Mcu | 101 | `AUTOSAR_SWS_MCUDriver.pdf` | Microcontroller Drivers |
| Core Test | CorTst | 103 | `AUTOSAR_SWS_CoreTest.pdf` | Microcontroller Drivers |
### I/O 驱动（I/O Drivers）
| 模块简称 | API 前缀 | 模块 ID | 规范文档 | 软件层 |
|----------|----------|---------|----------|--------|
| ADC Driver | Adc | 123 | `AUTOSAR_SWS_ADCDriver.pdf` | I/O Drivers |
| DIO Driver | Dio | 120 | `AUTOSAR_SWS_DIODriver.pdf` | I/O Drivers |
| ICU Driver | Icu | 122 | `AUTOSAR_SWS_ICUDriver.pdf` | I/O Drivers |
| OCU Driver | Ocu | 125 | `AUTOSAR_SWS_OCUDriver.pdf` | I/O Drivers |
| PWM Driver | Pwm | 124 | `AUTOSAR_SWS_PWMDriver.pdf` | I/O Drivers |
| Port Driver | Port | 102 | `AUTOSAR_SWS_PortDriver.pdf` | I/O Drivers |
### 内存驱动（Memory Drivers）
| 模块简称 | API 前缀 | 模块 ID | 规范文档 | 软件层 |
|----------|----------|---------|----------|--------|
| EEPROM Driver | Eep | 090 | `AUTOSAR_SWS_EEPROMDriver.pdf` | Memory Drivers |
| Flash Driver | Fls | 092 | `AUTOSAR_SWS_FlashDriver.pdf` | Memory Drivers |
| Flash Test | FlsTst | 104 | `AUTOSAR_SWS_FlashTest.pdf` | Memory Drivers |
### 内存硬件抽象与抽象接口（Memory HW Abstraction / Services）
| 模块简称 | API 前缀 | 模块 ID | 规范文档 | 软件层 |
|----------|----------|---------|----------|--------|
| EEPROM Abstraction | Ea | 040 | `AUTOSAR_SWS_EEPROMAbstraction.pdf` | Memory HW Abstraction |
| Flash EEPROM Emulation | Fee | 021 | `AUTOSAR_SWS_FlashEEPROMEmulation.pdf` | Memory HW Abstraction |
| Memory Abstraction Interface | MemIf | 022 | `AUTOSAR_SWS_MemoryAbstractionInterface.pdf` | Memory Services |
| NVRAM Manager | NvM | 020 | `AUTOSAR_SWS_NVRAMManager.pdf` | Memory Services |
### 加密驱动与抽象（Crypto Drivers / HW Abstraction / Services）
| 模块简称 | API 前缀 | 模块 ID | 规范文档 | 软件层 |
|----------|----------|---------|----------|--------|
| Crypto Driver | Crypto | 114 | `AUTOSAR_SWS_CryptoDriver.pdf` | Crypto Drivers |
| Crypto Interface | CryIf | 112 | `AUTOSAR_SWS_CryptoInterface.pdf` | Crypto HW Abstraction |
| Crypto Service Manager | Csm | 110 | `AUTOSAR_SWS_CryptoServiceManager.pdf` | Crypto Services |
| Key Manager | KeyM | 109 | `AUTOSAR_SWS_KeyManager.pdf` | Crypto Services |
### 通信驱动（Communication Drivers）
| 模块简称 | API 前缀 | 模块 ID | 规范文档 | 软件层 |
|----------|----------|---------|----------|--------|
| CAN Driver | Can | 080 | `AUTOSAR_SWS_CANDriver.pdf` | Communication Drivers |
| CAN Tranceiver Driver | CanTrcv | 070 | `AUTOSAR_SWS_CANTransceiverDriver.pdf` | Communication HW Abstraction |
| Ethernet Driver | Eth | 088 | `AUTOSAR_SWS_EthernetDriver.pdf` | Communication Drivers |
| Ethernet Switch Driver | EthSwt | 089 | `AUTOSAR_SWS_EthernetSwitchDriver.pdf` | Communication HW Abstraction |
| Ethernet Transceiver Driver | EthTrcv | 073 | `AUTOSAR_SWS_EthernetTransceiverDriver.pdf` | Communication HW Abstraction |
| FlexRay Driver | Fr | 081 | `AUTOSAR_SWS_FlexRayDriver.pdf` | Communication Drivers |
| FlexRay Tranceiver Driver | FrTrcv | 071 | `AUTOSAR_SWS_FlexRayTranceiverDriver.pdf` | Communication HW Abstraction |
| LIN Driver | Lin | 082 | `AUTOSAR_SWS_LINDriver.pdf` | Communication Drivers |
| LIN Transceiver Driver | LinTrcv | 064 | `AUTOSAR_SWS_LINTransceiverDriver.pdf` | Communication HW Abstraction |
### 通信接口（Communication HW Abstraction / Interface）
| 模块简称 | API 前缀 | 模块 ID | 规范文档 | 软件层 |
|----------|----------|---------|----------|--------|
| CAN Interface | CanIf | 060 | `AUTOSAR_SWS_CANInterface.pdf` | Communication HW Abstraction |
| Ethernet Interface | EthIf | 065 | `AUTOSAR_SWS_EthernetInterface.pdf` | Communication HW Abstraction |
| FlexRay Interface | FrIf | 061 | `AUTOSAR_SWS_FlexRayInterface.pdf` | Communication HW Abstraction |
| LIN Interface | LinIf | 062 | `AUTOSAR_SWS_LINInterface.pdf` | Communication HW Abstraction |
### 通信服务（Communication Services）
| 模块简称 | API 前缀 | 模块 ID | 规范文档 | 软件层 |
|----------|----------|---------|----------|--------|
| Bus Mirroring | Mirror | 048 | `AUTOSAR_SWS_BusMirroring.pdf` | Communication Services |
| CAN Network Management | CanNm | 031 | `AUTOSAR_SWS_CANNetworkManagement.pdf` | Communication Services |
| CAN State Manager | CanSM | 140 | `AUTOSAR_SWS_CANStateManager.pdf` | Communication Services |
| CAN Transport Layer | CanTp | 035 | `AUTOSAR_SWS_CANTransportLayer.pdf` | Communication Services |
| COM | Com | 050 | `AUTOSAR_SWS_COM.pdf` | Communication Services |
| COM Based Transformer | ComXf | 175 | `AUTOSAR_SWS_COMBasedTransformer.pdf` | Communication Services |
| COM Manager | ComM | 012 | `AUTOSAR_SWS_COMManager.pdf` | Communication Services |
| Diagnostic Communication Manager | Dcm | 053 | `AUTOSAR_SWS_DiagnosticCommunicationManager.pdf` | Communication Services |
| Diagnostic Log and Trace | Dlt | 055 | `AUTOSAR_SWS_DiagnosticLogAndTrace.pdf` | Communication Services |
| Diagnostic over IP | DoIP | 173 | `AUTOSAR_SWS_DiagnosticOverIP.pdf` | Communication Services |
| E2E Transformer | E2EXf | 176 | `AUTOSAR_SWS_E2ETransformer.pdf` | Communication Services |
| Ethernet State Manager | EthSM | 143 | `AUTOSAR_SWS_EthernetStateManager.pdf` | Communication Services |
| FlexRay AUTOSAR Transport Layer | FrArTp | 038 | `AUTOSAR_SWS_FlexRayARTransportLayer.pdf` | Communication Services |
| FlexRay ISO Transport Layer | FrTp | 036 | `AUTOSAR_SWS_FlexRayISOTransportLayer.pdf` | Communication Services |
| FlexRay Network Management | FrNm | 032 | `AUTOSAR_SWS_FlexRayNetworkManagement.pdf` | Communication Services |
| FlexRay State Manager | FrSM | 142 | `AUTOSAR_SWS_FlexRayStateManager.pdf` | Communication Services |
| IPDU Multiplexer | IpduM | 052 | `AUTOSAR_SWS_IPDUMultiplexer.pdf` | Communication Services |
| Large Data COM | LdCom | 049 | `AUTOSAR_SWS_LargeDataCOM.pdf` | Communication Services |
| LIN State Manager | LinSM | 141 | `AUTOSAR_SWS_LINStateManager.pdf` | Communication Services |
| Network Management Interface | Nm | 029 | `AUTOSAR_SWS_NetworkManagementInterface.pdf` | Communication Services |
| PDU Router | PduR | 051 | `AUTOSAR_SWS_PDURouter.pdf` | Communication Services |
| SAE J1939 Diagnostic Communication Manager | J1939Dcm | (详见原文档) | (详见原文档) | Communication Services |
| SAE J1939 Network Management | J1939Nm | (详见原文档) | (详见原文档) | Communication Services |
| SAE J1939 Request Manager | J1939Rm | (详见原文档) | (详见原文档) | Communication Services |
| SAE J1939 Transport Layer | J1939Tp | (详见原文档) | (详见原文档) | Communication Services |
| Service Discovery | Sd | (详见原文档) | (详见原文档) | Communication Services |
| Socket Adaptor | SoAd | (详见原文档) | (详见原文档) | Communication Services |
| SOME/IP Transformer | SomeIpXf | (详见原文档) | (详见原文档) | Communication Services |
| TCP/IP Stack | TcpIp | (详见原文档) | (详见原文档) | Communication Services |
| TTCAN Interface | TtcanIf | (详见原文档) | (详见原文档) | Communication Services |
| UDP Network Management | UdpNm | (详见原文档) | (详见原文档) | Communication Services |
| V2X Management | V2xM | (详见原文档) | (详见原文档) | Communication Services |
| V2X GeoNetworking | V2xGn | (详见原文档) | (详见原文档) | Communication Services |
| Wireless Ethernet Driver | EthW | (详见原文档) | (详见原文档) | Communication Drivers |
| Wireless Ethernet Transceiver Driver | EthWtrcv | (详见原文档) | (详见原文档) | Communication HW Abstraction |
### 系统服务（System Services）
| 模块简称 | API 前缀 | 模块 ID | 规范文档 | 软件层 |
|----------|----------|---------|----------|--------|
| BSW Mode Manager | BswM | 042 | `AUTOSAR_SWS_BSWModeManager.pdf` | System Services |
| BSW Scheduler Module | SchM | 130 | R4.0 起属于 RTE | System Services |
| Default Error Tracer | Det | 015 | `AUTOSAR_SWS_DefaultErrorTracer.pdf` | System Services |
| Diagnostic Event Manager | Dem | 054 | `AUTOSAR_SWS_DiagnosticEventManager.pdf` | System Services |
| ECU State Manager | EcuM | 010 | `AUTOSAR_SWS_ECUStateManager.pdf` | System Services |
| Function Inhibition Manager | FiM | 011 | `AUTOSAR_SWS_FunctionInhibitionManager.pdf` | System Services |
| OS | Os（不用作 API 前缀） | 001 | `AUTOSAR_SWS_OS.pdf` | System Services - OS |
| Time Service | Tm | (详见原文档) | (详见原文档) | System Services |
| Watchdog Driver | Wdg | 102 | `AUTOSAR_SWS_WatchdogDriver.pdf` | Microcontroller Drivers |
| Watchdog Interface | WdgIf | (详见原文档) | (详见原文档) | (详见原文档) |
| Watchdog Manager | WdgM | (详见原文档) | (详见原文档) | (详见原文档) |
### I/O 硬件抽象（I/O HW Abstraction）
| 模块简称 | API 前缀 | 模块 ID | 规范文档 | 软件层 |
|----------|----------|---------|----------|--------|
| IO HW Abstraction | 无前缀（AUTOSAR 接口） | 254 | `AUTOSAR_SWS_IOHardwareAbstraction.pdf` | I/O HW Abstraction |
### 复杂驱动（Complex Drivers）
| 模块简称 | API 前缀 | 模块 ID | 规范文档 | 软件层 |
|----------|----------|---------|----------|--------|
| Complex Drivers | 无前缀（AUTOSAR 接口） | 255 | 不适用 | Complex Drivers |
### 特殊文件（Special Files）
- **MemMap**：内存映射文件（`AUTOSAR_SWS_MemoryMapping.pdf`）
### 库（Libraries）
- **CRC 库**（CRC routines）
- **E2E 库**（E2E protection）
- **CSM 库**（Crypto Services Manager 库）
- **FEE 库**（Flash EEPROM Emulation 库）
- **其他实用库**：Bit handling、StdPeriph 等
> 完整库列表请参见英文原版 PDF 第 8-9 页。
---
## 翻译说明
- 本文档为**参考手册类**，主体内容为模块列表
- 模块简称、API 前缀、模块 ID、文件名均**逐字保留英文**
- 软件层名称、模块类别为通用术语，已翻译
---
*翻译：opencode-translator / Step 3 P0 批量翻译*
BSWGeneral/AUTOSAR_TR_BSWUMLModelModelingGuide.md
+949
View File
@@ -0,0 +1,949 @@
# 基础软件 EA UML 模型建模指南
> **AUTOSAR CP Release 4.4.0**
>
> 原文：*Modeling Guidelines of Basic Software EA UML Model*（文档 ID 117）
>
> 翻译状态：**已完成 v1**
>
> 对应原文 PDF：`BSWGeneral/AUTOSAR_TR_BSWUMLModelModelingGuide.pdf`
>
> 翻译日期：Step 3 - P0 批量翻译
---
## 文档标识
| 字段 | 值 |
|------|-----|
| 文档标题 | 基础软件 EA UML 模型建模指南（Modeling Guidelines of Basic Software EA UML Model） |
| 文档所有者 | AUTOSAR |
| 文档责任人 | AUTOSAR |
| 文档标识号 | 117 |
| 文档状态 | 正式版（Final） |
| 所属标准 | Classic Platform |
| 所属版本 | 4.4.0 |
---
## 文档变更历史
| 日期 | 版本 | 变更人 | 变更说明 |
|------|------|--------|----------|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 修正 / 澄清 / 编辑性变更；详情请参阅 ChangeDocumentation |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 修正 / 澄清 / 编辑性变更；详情请参阅 ChangeDocumentation |
| 2018-04-17 | 4.4.0 | AUTOSAR Technical Office | 移除过时的元素 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 编辑性变更 |
| 2014-10-31 | 4.2.1 | AUTOSAR Administration | 编辑性变更 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 完结 4.1 版本发布 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 重构头文件的建模；重构参数建模的描述；法律免责声明修订 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 添加 range 构造型描述；修改函数参数和结构体属性的需求；扩展文档元信息；小规模布局调整 |
| 2006-11-28 | 2.1.1 | AUTOSAR Administration | 澄清包的使用方式；澄清时序图建模；法律免责声明修订 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始发布 |
---
## 目录
1. [介绍](#1-介绍)
- 1.1 [Artifacts](#11-artifacts)
2. [建模指南](#2-建模指南)
- 2.1 [术语](#21-术语)
- 2.2 [模型结构](#22-模型结构)
- 2.3 [BSW 模块建模](#23-bsw-模块建模)
- 2.4 [图表](#24-图表)
- 2.5 [BSW 模型中生命周期概念的支持](#25-bsw-模型中生命周期概念的支持)
---
## 1 介绍
本建模指南描述了在 UML 模型中规定 AUTOSAR 基础软件（BSW）时所用的建模技术和规则。
BSW 模型中包含的信息由 AUTOSAR 元模型工具（MMT, Meta Model Tool）处理，并为 AUTOSAR 定义的多份软件规范（SWS）提供主要输入。为了使 BSW 模型能够被 MMT 访问，模型必须遵守本文件中描述的规则，这一点至关重要。
### 1.1 Artifacts
AUTOSAR BSW UML 模型的主要目的是使 99+ 份文档在文件结构、提供和所需的接口、时序图、状态机等方面保持同步。因此，所有相关信息都按照第 2 章"建模指南"中规定的建模规则保存在 BSW 模型中。
BSW UML 模型为 SWS 文档贡献以下 artifacts：
#### 1.1.1 头文件
每个 SWS 文档的第 5.1 章包含 BSW 模块的文件结构，特别是其文件包含结构。大多数模块的包含文件关系具有类似的结构，事实上某些部分实际上是以完全相同的方式建模的。因此，头文件结构使用类图建模，使用带构造型的类来表示源代码和头文件；详见 2.4.1 节。
#### 1.1.2 导入的类型定义
SWS 文档的第 8.1 章包含一个导入类型的表格列表。该表根据 2.3.5 节中说明的模块依赖关系自动生成。
#### 1.1.3 类型定义
SWS 文档的第 8.2 章包含给定 BSW 模块内定义的所有类型的详细描述。有关类型定义建模的详细信息，请参阅 2.3.8 节。
#### 1.1.4 函数定义
SWS 文档的第 8.3 章包含 BSW 模块提供的每个函数的详细描述。该描述以具有特定布局的表格形式呈现。表格的各个字段根据 2.3.3 节从 API 函数定义中填充。
#### 1.1.5 回调通知
与函数定义非常相似，SWS 文档的第 8.4 章包含 BSW 模块提供的回调定义。这些回调将由其他 BSW 模块调用，其中下层模块通常是调用方。根据 2.3.7 节，将为模块指定的回调生成每个回调通知的表格。
#### 1.1.6 计划函数（Scheduled Functions）
计划函数在 SWS 文档的第 8.5 章中描述。BSW UML 模型中计划函数的定义在 2.3.3.1 节中描述。
#### 1.1.7 强制性接口
SWS 文档的第 8.6.1 章包含模块期望的"强制性接口"列表。该列表根据 2.3.5.2 节中描述的强制性依赖关系从 BSW UML 模型生成。
#### 1.1.8 可选接口
类似地，SWS 文档第 8.6.2 章中包含的"可选接口"列表根据 2.3.5.3 节中描述的可选依赖关系从 BSW UML 模型生成。
#### 1.1.9 可配置接口
SWS 文档第 8.6.3 章包含 BSW 模块的"可配置接口"。这些接口的调用函数名可以使用 ECU 配置参数进行配置。在 AUTOSAR 中，这些接口通常用于发出回调通知，即拥有可配置接口的模块使用它来通知一个（可配置的）上层模块的回调。换句话说，定义"可配置接口"的模块调用实现该接口定义的其他模块。根据 2.3.7.2 节，将为模块指定的回调生成每个回调通知的表格。
#### 1.1.10 时序图
为了可视化 BSW 模块与其他模块的交互，SWS 文档第 9 章包含该模块典型用例的 UML 时序图。为了使此类时序图在 AUTOSAR BSW 栈内的不同模块之间保持一致，它们也在 BSW UML 模型中进行建模。这些图由 mmt 工具导出为图像文件；然后由 SWS 文档文件包含它们。有关详细建模指南，请参见 2.4.2 节。
#### 1.1.11 各种图表
各种 BSW 模块的 SWS 文档使用其他 UML 图，例如用于规定核心功能，或用于额外说明模块之间的依赖关系。一些具体示例是 AUTOSAR BSW 栈中使用的各种状态机，例如在 CAN State Manager 或 COM Manager 中使用的状态机。在可能的情况下，这些图也应在 BSW UML 模型中进行建模。这确保了文档图的源不会丢失，并有助于其维护并保持统一的建模风格。
#### 1.1.12 服务建模
属于 AUTOSAR 基础软件架构服务层的 BSW 模块可以以 AUTOSAR 服务接口的形式提供其服务。AUTOSAR 服务接口以软件组件模板（而非 C 语言接口）来描述，并且具有不同的风格，例如 ClientServerInterface、SenderReceiverInterface、ModeSwitchInterface。因此，它们的属性需要与标准 BSW API 函数不同的建模风格。AUTOSAR 服务的建模在 2.3.9 节中描述。
---
## 2 建模指南
本章包含在 BSW UML 模型内对 AUTOSAR BSW artifacts 建模时应遵循的建模规则。由于以下原因，在整个模型中一致地使用这些规则非常重要：模型保持可读性，以可重现的方式进行添加和修改以防止元素重复，最重要的是，使用 MMT 工具的自动化 artifact 生成依赖于无歧义的建模约定。
### 2.1 术语
AUTOSAR 中达成一致的 UML 建模工具是 Sparx Systems 的 Enterprise Architect。因此，BSW 模型使用 Enterprise Architect 7.5 及以上版本进行维护。本指南侧重于建模技术而非工具，因此本文件力求以 UML 的术语描述这些概念。尽管如此，为了精确起见，有时会使用 Enterprise Architect 特定的术语。
### 2.2 模型结构
BSW UML 模型的根结构由以下包组成：
- **ReadMe**：包含提供版本号、已知限制和免责声明的图。
- **Interaction Views**：包含用于建模不同模块交互的时序图。该包中应仅放置时序图。各模块按栈垂直排列。
- **SoftwarePackages**：包含 BSW 模块定义，包括接口和类型定义。此外，状态图和头文件图也在这里建模。各模块按层水平排列。
- **Generic Elements**：包含通用接口定义，例如可配置回调定义。
### 2.3 BSW 模块建模
#### 2.3.1 模块
##### 2.3.1.1 包
- ⌈**TR_BSWMG_00001**⌋ **BSW 模块包** d 对于每个基础软件模块，应根据该模块在分层软件架构 [1] 中的角色，将其 UML 包（"模块包"）放置在包结构中。c()
- ⌈**TR_BSWMG_00002**⌋ **BSW 模块包的命名** d 模块包的名称应为《基础软件模块列表》[2] 中规定的"模块缩写"。c()
> 图 2.1：模块包示例
##### 2.3.1.2 组件
- ⌈**TR_BSWMG_00003**⌋ **BSW 模块组件** d 每个基础软件模块应建模为带构造型 «module» 的 UML 组件（即"模块组件"）。c()
- ⌈**TR_BSWMG_00004**⌋ **BSW 模块组件的命名** d 模块组件的名称应为"模块缩写"[2]。c()
- ⌈**TR_BSWMG_00036**⌋ **BSW 模块 ID** d 标记值 "bsw.moduleId" 应设置为《基础软件模块列表》[2] 中规定的模块 ID。c()
- ⌈**TR_BSWMG_00005**⌋ **BSW 模块组件的位置** d 每个模块组件应建模为其所在模块包的顶层元素。c()
- ⌈**TR_BSWMG_00094**⌋ 模块强制性接口表的 SWS Item ID d 标记值 "bsw.mandatory.swsItemId" 用于规定 API 函数的 SWS Item ID。c()
- ⌈**TR_BSWMG_00095**⌋ 模块强制性接口表的 Up-traces d 标记值 "bsw.mandatory.traceRefs" 用于规定对需求的上溯追踪。多个需求 ID 必须以逗号分隔。c()
- ⌈**TR_BSWMG_00096**⌋ 模块可选接口表的 SWS Item ID d 标记值 "bsw.optional.swsItemId" 用于规定 API 函数的 SWS Item ID。c()
- ⌈**TR_BSWMG_00097**⌋ 模块可选接口表的 Up-traces d 标记值 "bsw.optional.traceRefs" 用于规定对需求的上溯追踪。多个需求 ID 必须以逗号分隔。c()
- ⌈**TR_BSWMG_00098**⌋ 模块导入类型表的 SWS Item ID d 标记值 "bsw.importedTypes.swsItemId" 用于规定 API 函数的 SWS Item ID。c()
- ⌈**TR_BSWMG_00099**⌋ 模块导入类型表的 Up-traces d 标记值 "bsw.importedTypes.traceRefs" 用于规定对需求的上溯追踪。多个需求 ID 必须以逗号分隔。c()
##### 2.3.1.3 组件图
- ⌈**TR_BSWMG_00006**⌋ **组件图** d 模块包应包含一个"组件图"（Enterprise Architect：UML 组件图）。c()
- ⌈**TR_BSWMG_00007**⌋ **组件图的命名** d 组件图的名称应与模块组件的名称相同（模块缩写）。c()
- ⌈**TR_BSWMG_00008**⌋ **组件图的内容** d 组件图包含模块组件以及模块的所有接口关系。c()
##### 2.3.1.4 类型图
- ⌈**TR_BSWMG_00009**⌋ **类型图** d 如果 BSW 模块定义数据类型，则其模块包应包含一个"类型图"（Enterprise Architect：UML 类图）。c()
- ⌈**TR_BSWMG_00010**⌋ **类型图的命名** d 类型图的名称应为模块组件的名称后接一个空格，再后接 "Types"，例如 "FrTp Types"。c()
- ⌈**TR_BSWMG_00011**⌋ **类型图的内容** d 类型图应包含 BSW 模块定义的所有类型。c()
#### 2.3.2 函数接口
AUTOSAR BSW 模块以 C 语法函数的形式向其他 BSW 模块提供服务。这些函数也是通过 RTE 由软件组件访问的 AUTOSAR 服务的底层实现。
本节说明如何在 UML 操作（operation）形式中建模这些函数。每个操作放在由实现该服务的 BSW 模块拥有的 UML 接口中。此类 UML 接口在下文中称为"函数接口"。
- ⌈**TR_BSWMG_00012**⌋ **函数接口** d 对于 BSW 模块要提供的每个函数，应在其模块包中创建一个 UML 接口（即"函数接口"）。接口的构造型应为 "interface"。c()
- ⌈**TR_BSWMG_00013**⌋ **函数接口的命名** d 函数接口应具有与实际函数相同的名称。（依赖于 TR_BSWMG_00017、TR_BSWMG_00030）c()
> 图 2.2：函数接口的命名示例
- ⌈**TR_BSWMG_00014**⌋ **组件图中的 API 函数** d API 函数应在提供该函数的 BSW 模块的组件图中可见。c()
- **注**：实现此目的的最简单方法是在创建接口时将其直接拖入提供该函数的模块的组件图中。
- ⌈**TR_BSWMG_00015**⌋ **实现关系** d 提供服务的 BSW 模块应与接口之间具有带构造型 «realize» 的有向"实现"关联。c()
- **注**：为了将用于说明性图表的关联与生成相关的关联区分开来，必须为每个生成相关的实现关联添加构造型 «realize»。
> 图 2.3：接口的实现示例
#### 2.3.3 API 函数
- ⌈**TR_BSWMG_00016**⌋ **API 函数** d 函数本身应建模为具有以下构造型之一的 UML 操作（"operation"）：«function»、«scheduled_function»、«callout»、«callback»。c()
- ⌈**TR_BSWMG_00017**⌋ **API 函数的命名** d 操作的名称应为 API 函数的名称。c()
- ⌈**TR_BSWMG_00030**⌋ **名称前缀** d 操作的名称应以实现模块的名称（模块缩写）为前缀，后跟下划线，即：`<Ma>_<operation_name>`（Ma = Module Abbreviation）。c()
- ⌈**TR_BSWMG_00018**⌋ **操作的位置** d 操作应放在其相应提供者的已实现接口中。c()
- ⌈**TR_BSWMG_00019**⌋ **API 函数文档** d 每个 API 函数应提供一个简短的描述。c()
- **注**：EA 提供了一个名为 "Notes" 的文本字段，用于存放操作的描述。
- ⌈**TR_BSWMG_00034**⌋ **操作的"返回类型"字段** d 操作的"Return Type"字段应留空。有关返回参数的建模，请参见 TR_BSWMG_00023。c()
- ⌈**TR_BSWMG_00024**⌋ **Service ID** d 标记值 "ServiceID" 应包含一个服务标识符（"Service ID"），该标识符在 BSW 模块内应唯一。参数以十六进制表示法使用小写字符指定，并应填充为两个十六进制数字，例如 `0x0d`。c()
- ⌈**TR_BSWMG_00025**⌋ **可重入性** d 标记值 "Reentrant" 应确定函数是否需要以可重入方式实现。允许的值为 "Reentrant"、"Non Reentrant"、"Conditionally Reentrant"。可重入性条件不在 BSW UML 模型范围内；相反，它们应移至各个 SWS 条目中（即："Non Reentrant for the same device."）。c()
- ⌈**TR_BSWMG_00026**⌋ **同步性** d 标记值 "Synchronous" 应设置为 "Synchronous" 或 "Asynchronous"。某些模块可能会规定其他子句。c()
- ⌈**TR_BSWMG_00031**⌋ **替代锚点名称** d 可选的标记值 "aName" 用于为操作规定一个替代锚点名称，以便在 BSW artifacts 中生成 html 引用时使用。在默认锚点名称不适用（例如超过 Word 中链接的长度限制或包含非标准字符）的情况下，应使用此替代锚点名称。c()
- ⌈**TR_BSWMG_00150**⌋ **API 函数的 SWS Item ID** d 标记值 "bsw.swsItemId" 用于规定 API 函数的 SWS Item ID。c()
- ⌈**TR_BSWMG_00151**⌋ **API 函数的 Up-traces** d 标记值 "bsw.traceRefs" 用于规定对需求的上溯追踪。多个需求 ID 必须以逗号分隔。c()
- ⌈**TR_BSWMG_00140**⌋ **API 函数的头文件引用** d 标记值 "bsw.headerFile" 用于规定提供该 API 函数的头文件。c()
> 图 2.4：API 函数的 TaggedValues 示例
##### 2.3.3.1 计划函数
- ⌈**TR_BSWMG_00037**⌋ **计划函数的构造型** d 应通过将操作的构造型设置为 «scheduled_function» 来对计划函数进行建模。c()
- **注**：计划函数的 Schedule 属性不再在任何 artifact 中使用。
#### 2.3.4 API 函数参数
- ⌈**TR_BSWMG_00020**⌋ **函数参数** d 函数参数应包含 "Name"、"Type"、"Direction" 和 "Notes" 的强制性条目。c()
- ⌈**TR_BSWMG_00032**⌋ **参数类型** d 参数 "Type" 应是 BSW 模型中定义的现有类型之一。c()
- ⌈**TR_BSWMG_00033**⌋ **C 风格指针** d 可以通过在参数类型后追加 `*` 将参数建模为 C 风格指针，例如 `PduInfoType*`。c()
- ⌈**TR_BSWMG_00027**⌋ **输出参数的强制性指针** d 如果参数的 "Direction" 属性设置为 out 或 inout，则必须将参数建模为指针。c()
- ⌈**TR_BSWMG_00035**⌋ **输入参数指针的强制性常量类型** d 方向类型为 "in" 的指针类型参数（即表示只读结构体或数组的参数）可以在参数类型前加上 `const` 关键字。这强制要求由该参数指向的数据是只读的，并且不会被函数更改。示例：`const FrIf_ConfigType*`。c()
- ⌈**TR_BSWMG_00021**⌋ **参数方向** d 参数的方向类型属性应设置为 `in`、`out`、`inout`、`return` 之一。c()
- ⌈**TR_BSWMG_00022**⌋ **参数描述** d 每个参数应提供有关其用途的简短描述。c()
- **注**：EA 提供了一个名为 "Notes" 的文本字段，用于存放参数的描述。
- ⌈**TR_BSWMG_00023**⌋ **返回参数** d 如果函数的返回类型不等于 `void`，则返回值应按操作参数的方式建模，但有以下例外：它应是列表中的第一个参数。此外，它应是唯一一个 "Direction" 设置为 "return" 的参数。Notes 字段应简明描述可能的返回值。c()
> 图 2.5：API 函数的参数示例
- ⌈**TR_BSWMG_00129**⌋ **可选参数** d 参数的存在性可能取决于模块配置。在这种情况下，参数应具有构造型 «optional»。c()
- ⌈**TR_BSWMG_00130**⌋ **参数的多重性** d 具有给定类型的参数可能出现多次，其中多重性由配置规定。在这种情况下，参数应具有构造型 «multiple»。c()
- **提示**：不要在参数编辑界面中使用多重性按钮来配置多重性。
- ⌈**TR_BSWMG_00131**⌋ **参数的互斥变体** d 参数可能以不同变体出现在函数签名的同一位置，其中一个特定变体将通过配置选择。在这种情况下，参数应以其所有可能的变体形式多次建模，并且参数的每个变体都应具有构造型 «mutualexcl»。c()
- **示例**：Xfrm 函数 `<Mip>_<transformerId>` 的参数 "buffer" 可配置为 "inout" 或 "out"。因此它应建模两次，一次 Direction 为 "inout"，第二次 Direction 为 "out"。由于 Enterprise Architect 要求参数名称唯一，第一个参数变体可命名为 "buffer{inout}"，第二个命名为 "buffer{out}"。
- **提示**：互斥参数的所有变体应具有相同的名称；不带大括号（包括其中的文本）的名称必须相同。
> 图 2.6：API 函数的互斥参数示例
#### 2.3.5 模块依赖关系
##### 2.3.5.1 虚拟接口
通常，AUTOSAR BSW 模块需要其他 BSW 模块 API 中的函数才能实现其自身功能。一个 BSW 模块与另一个 BSW 模块之间的依赖关系的一般建模模式使用所谓的函数接口和虚拟接口。
首先，由于 API 之间的依赖关系有时必须在单个 API 细节级别上表达，因此每个 API 函数都需要在模块级别上表示。为此，引入了函数接口（参见 2.3.2）。
其次，为了进一步增强 BSW 模块的表达能力，函数接口的概念由虚拟接口扩展而来。虚拟接口派生自函数接口，以合并某一组 API 函数。也允许虚拟接口的递归结构，因此虚拟接口允许从其他虚拟接口派生。此概念基本上允许通过为每个提供模块提供单个虚拟接口来减少"客户端"侧的模块依赖关系数量。
- ⌈**TR_BSWMG_00028**⌋ **虚拟接口** d 虚拟接口应建模为带构造型 «interface» 的接口（与普通接口相同）。c()
- ⌈**TR_BSWMG_00029**⌋ **虚拟接口的命名** d 虚拟接口的名称应由依赖 BSW 模块的名称、提供模块的名称和关系种类组成，各部分之间用下划线分隔。
```
<NameOfDependingModule>_<NameOfProvidingModule>_<KindOfRelation>
```
c()
- ⌈**TR_BSWMG_00039**⌋ **虚拟接口的多重性** d 一个虚拟接口仅指代一对实现和依赖模块。c()
- ⌈**TR_BSWMG_00040**⌋ **虚拟接口的位置** d 虚拟接口应放在依赖 BSW 模块的模块包中。c()
- ⌈**TR_BSWMG_00041**⌋ **虚拟接口的内容** d 虚拟接口应从实现者的函数接口继承其函数。c()
- ⌈**TR_BSWMG_00042**⌋ **函数接口和虚拟接口的不混用** d 依赖模块要么直接依赖于另一模块的函数接口方法，要么依赖于指向另一模块的虚拟接口。这两种方法不应混用。c()
> 图 2.7：用于定义可选接口的虚拟接口示例
##### 2.3.5.2 强制性接口
- ⌈**TR_BSWMG_00043**⌋ **接口上的强制性依赖的构造型** d 用户模块应对其所有强制性接口具有构造型为 «mandatory» 的依赖。c()
- ⌈**TR_BSWMG_00044**⌋ **强制性依赖** d 用户模块对提供者模块持有的所有强制性依赖应建模为恰好一个虚拟接口。c()
- ⌈**TR_BSWMG_00045**⌋ **强制性使用集合的命名** d 虚拟接口应命名为 `<user_module>_<provider_module>_Mandatory`。c()
##### 2.3.5.3 可选接口
- ⌈**TR_BSWMG_00046**⌋ **接口上的可选依赖的构造型** d 用户模块应对其所有可选接口具有构造型为 «optional» 的依赖。c()
- ⌈**TR_BSWMG_00047**⌋ **可选依赖** d 用户模块对提供者模块持有的所有可选依赖应建模为恰好一个虚拟接口。c()
- ⌈**TR_BSWMG_00048**⌋ **可选使用集合的命名** d 虚拟接口应命名为 `<user_module>_<provider_module>_Optional`。c()
#### 2.3.6 通用接口
在某些情况下，AUTOSAR BSW 栈定义了一些接口，这些接口的函数签名基本相同，但根据模块特定的命名略有不同。在这些情况下，应通过仅使用一个接口定义来防止接口的冗余定义。为了规定具体命名，应使用"自定义接口"。"自定义接口"继承自接口定义，并可以覆盖命名规则。
以下建模模式应用于定义"通用接口"：
- ⌈**TR_BSWMG_00061**⌋ **通用接口定义** d 函数定义应放在带构造型 «generic_interface» 的 UML 接口中。c()
- ⌈**TR_BSWMG_00132**⌋ **通用接口定义** d 此"通用接口"定义应被视为抽象的，不应被任何模块直接引用。c()
- ⌈**TR_BSWMG_00133**⌋ **通用接口定义** d 通用接口定义应包含一个具有构造型 «function_blueprint» 的操作。c()
- ⌈**TR_BSWMG_00134**⌋ **自定义接口** d 为了将"自定义接口"分配给"通用接口定义"，应建模一个泛化关联（目标为"通用接口定义"）。c()
- ⌈**TR_BSWMG_00062**⌋ **自定义接口** d 为了将具体命名模式分配给通用接口中定义的函数，应定义另一个具有相同构造型 «generic_interface» 的接口。c()
- **注**：为防止重做现有模型和生成器工具，"通用接口定义"和"自定义接口"的接口使用相同的构造型。
- ⌈**TR_BSWMG_00156**⌋ **自定义接口** d 自定义接口不应包含函数定义。c()
- ⌈**TR_BSWMG_00063**⌋ **提供者命名方案** d 模块对自定义接口的提供者关联（«realize»）的命名模式应使用标记值 "naming_provider" 配置。c()
- ⌈**TR_BSWMG_00064**⌋ **用户命名方案** d 模块对自定义接口的用户依赖（«mandatory» 或 «optional»）的命名模式应使用标记值 "naming_user" 配置。c()
- ⌈**TR_BSWMG_00065**⌋ **用户可配置的命名方案** d 模块对自定义接口的 «configurable» 依赖的命名模式应使用标记值 "naming_configurable" 配置。c()
> 图 2.8：通用接口/自定义接口示例
#### 2.3.7 回调通知
在 AUTOSAR 中，"回调"定义为上层 BSW 模块中由下层模块调用以提供所需通知的功能 [3]。
> 图 2.9：回调与常规函数调用之间的区别
##### 2.3.7.1 回调定义和使用（非可配置回调）
- ⌈**TR_BSWMG_00157**⌋ **回调定义** d 回调定义应建模为 UML 操作，并应使用构造型 «callback»。c()
- ⌈**TR_BSWMG_00158**⌋ **回调接口** d 对于 BSW 模块要调用的每个回调，应在其模块包中创建一个 UML 接口（即"函数接口"）。接口的构造型应为 «interface»。c()
- ⌈**TR_BSWMG_00159**⌋ **回调接口的命名** d 回调接口应具有与实际函数相同的名称。（依赖于 TR_BSWMG_00017、TR_BSWMG_00030）c()
- ⌈**TR_BSWMG_00161**⌋ **回调函数定义** d 回调接口应包含一个具有构造型 «callback» 的函数。函数的建模如 2.3.3 节所述。c()
- ⌈**TR_BSWMG_00162**⌋ **回调函数的使用/调用** d 对于下层模块可调用的所有回调，应建模一个带构造型 «mandatory» 或 «optional» 的依赖（目标为回调接口），参见第 2.3.5.2 和 2.3.5.3 章。c()
- ⌈**TR_BSWMG_00163**⌋ **回调函数的实现/实施** d 对于上层模块实现的所有回调，应建模一个带构造型 «realize» 的实现（目标为回调接口）。c()
- ⌈**TR_BSWMG_00164**⌋ **回调函数的实现/实施** d 每个回调接口应仅被一个带构造型 «mandatory»、«optional» 或 «configurable» 的依赖所引用（只有一个调用方，但可能有多个实现并通过配置分配）。c()
> 图 2.10：回调定义和使用的示例
##### 2.3.7.2 可配置回调的定义和使用
下层模块是回调的调用方。通常，这些模块可以配置将调用回调定义的哪个实际实例，即在回调情况下将调用哪个上层。在 SWS 中，回调的可配置性分为两部分描述：包括回调签名和参数等详细信息的可配置回调函数的 API 表，以及第 10 章中描述的实际 ECU 配置参数。
> 图 2.11：可配置回调：必须配置下层模块以确定将调用上层模块的哪个实现
- ⌈**TR_BSWMG_00059**⌋ **可配置依赖** d 下层模块应对其每个可配置回调定义具有构造型为 «configurable» 的依赖。c()
- ⌈**TR_BSWMG_00060**⌋ **可配置依赖的目标是通用定义** d 下层模块应将通用回调定义作为可配置依赖的目标。c()
回调函数的命名目前在 BSW 模块之间（特别是在 BSW 栈之间）有所不同。因此，此处不能对回调的命名模式给出明确的规则。但是，作为添加新回调函数的指南，应遵循以下模式之一：
1. **模块缩写** + 下划线 + 回调函数名称。当与通用回调定义结合使用时，UML 接口应获得标记值 `naming_configurable = [user]_[name]`。
2. 字面字符串 **"User"** + 下划线 + 回调函数名称。此外，整个函数名称放在尖括号 "<>" 中，以强调这只是实际可配置名称的占位符。当与通用回调定义结合使用时，UML 接口应获得标记值 `naming_configurable = <User_[name]>`。
##### 2.3.7.3 回调的通用接口
与通用接口的定义类似，可以为回调定义通用接口。回调通用接口的目的是作为回调的一次性定义。然后可以在不同上下文中引用该回调，使用在不同模块上下文中构造的不同名称，并且在 Service ID 等属性上也会有所不同。
- ⌈**TR_BSWMG_00049**⌋ **回调通用接口定义** d 回调定义应建模为 UML 操作，并应使用构造型 «callback» 和 «function_blueprint»。c()
- ⌈**TR_BSWMG_00050**⌋ **回调通用接口名称** d 回调定义的名称应仅为描述实际功能的部分名称。特别地，它不应包含提供方或用户的名称，也不应包含字面字符串 "<User>" 等。c()
- ⌈**TR_BSWMG_00051**⌋ **回调蓝图接口位置** d 每个回调蓝图定义应放在具有与所含操作同名且构造型为 «generic_interface» 的 UML 接口内。c()
- ⌈**TR_BSWMG_00052**⌋ **回调蓝图接口的模型位置** d 通用接口定义应位于顶层包 "Generic Elements" 内。c()
- ⌈**TR_BSWMG_00053**⌋ **回调蓝图接口的子包位置** d 在 "Generic Elements" 包内，回调蓝图接口应放在表示与该接口关联的 BSW 栈的子包中：
- ComStack
- IoStack
- MemoryStack
c()
> 图 2.12：使用通用接口实现的可配置回调示例
#### 2.3.8 数据类型定义
##### 2.3.8.1 简单类型
- ⌈**TR_BSWMG_00066**⌋ **简单类型定义** d 每个简单类型定义（即直接派生自另一种类型或定义 'int' 等基本类型的类型定义）应建模为带构造型 «type» 的 UML 类。c()
- ⌈**TR_BSWMG_00067**⌋ **基类型与派生类型** d 简单类型定义应定义基类型或派生自另一种数据类型定义。c()
- ⌈**TR_BSWMG_00068**⌋ **基类型依赖** d 基类型不应派生自另一种数据类型。c()
- ⌈**TR_BSWMG_00069**⌋ **派生类型依赖** d 通常，派生类型应仅从恰好一种其他数据类型派生。但是，如果该类型依赖于平台或具有配置特定性，则它可以从多种类型派生。c()
- ⌈**TR_BSWMG_00071**⌋ **Range** d 如果简单类型具有受限范围集，则必须为每个此类范围创建带构造型 «range» 的属性。属性的名称规定范围标签，Notes 字段描述范围。c()
- **示例**：Name："0..2^16-1"
- **提示**："Name" 是 EA 编辑界面中编辑字段的名称。
- ⌈**TR_BSWMG_00152**⌋ **类型的 SWS Item ID** d 标记值 "bsw.swsItemId" 用于规定 API 函数的 SWS Item ID。c()
- ⌈**TR_BSWMG_00153**⌋ **类型的 Up-traces** d 标记值 "bsw.traceRefs" 用于规定对需求的上溯追踪。多个需求 ID 必须以逗号分隔。c()
- ⌈**TR_BSWMG_00141**⌋ **类型的头文件引用** d 标记值 "bsw.headerFile" 用于规定提供该类型的头文件。c()
> 图 2.13：简单类型示例
##### 2.3.8.2 枚举
- ⌈**TR_BSWMG_00072**⌋ **枚举定义** d 每个表示枚举的类型定义应建模为带构造型 «enumeration» 的 UML 类。它应放在规定它的接口内。c()
- ⌈**TR_BSWMG_00073**⌋ **枚举字面量定义** d 枚举的所有可能字面量应建模为该类的属性。从上到下的属性顺序应表示所规定枚举的顺序。c()
- ⌈**TR_BSWMG_00074**⌋ **枚举字面量详细信息** d 对于属性应遵守以下规定：
- "Name" 字段应包含字面量名称。
- "Type" 字段应为空。
- "Stereotype" 字段应为空。
- "Scope" 字段应为 "Public"。
- "Is Literal" 标志应被设置。
- "Notes" 字段应包含字面量描述。
c()
- ⌈**TR_BSWMG_00075**⌋ **枚举字面量值** d 字面量可以具有规定值；在这种情况下，应将其放在 "Initial Value" 字段中。c()
> 图 2.14：枚举示例
##### 2.3.8.3 Std_ReturnType 扩展
AUTOSAR 定义了一个标准 API 返回类型，该类型在整个 BSW 栈中使用。它也是可在 ClientServer 类型服务接口操作中使用的唯一返回类型。
"Std_ReturnType" 在 SWS Standard Types [4]（[SRS_BSW_00377]）中定义。此外，还定义了两个标准值 `E_OK` 和 `E_NOT_OK`，通常应与 Std_ReturnType 一起使用。
如果这两个返回值不够用，则允许 BSW 模块定义要与 Std_ReturnType 一起使用的附加值。这种用户定义的值应以模块前缀为前缀，并且可以位于 0x02–0x3f 范围内。
- ⌈**TR_BSWMG_00089**⌋ **Std_ReturnType 扩展定义** d BSW 模块特定的 Std_ReturnType 扩展的定义应建模为带构造型 «extra_literals» 的 UML 类。c()
- ⌈**TR_BSWMG_00090**⌋ **Std_ReturnType 扩展名称** d 包含 Std_ReturnType 扩展的 UML 类应命名为 `<Ma>_ReturnType`（Ma = Module Abbreviation）。c()
- ⌈**TR_BSWMG_00091**⌋ **Std_ReturnType 扩展字面量定义** d BSW 模块特定的所有可能返回类型扩展字面量应建模为该类的属性。从上到下的属性顺序应表示所规定枚举的顺序。c()
- ⌈**TR_BSWMG_00092**⌋ **Std_ReturnType 扩展字面量详细信息** d 应使用以下字段来规定返回类型扩展字面量：
- "Name" 字段应包含 Std_ReturnType 扩展字面量名称。
- "Type" 字段应为空。
- "Stereotype" 字段应为空。
- "Scope" 字段应为 "Public"。
- "Is Literal" 标志应被设置。
- "Notes" 字段应包含自定义返回值的描述。
c()
- ⌈**TR_BSWMG_00093**⌋ **Std_ReturnType 扩展字面量值** d 自定义 Std_ReturnType 值应始终使用大于 1（即 `E_NOT_OK`）的指定无符号整数值定义。整数值应放在 "Initial Value" 字段中。c()
> 图 2.15：Std_ReturnType 扩展示例
##### 2.3.8.4 结构体
- ⌈**TR_BSWMG_00076**⌋ **结构体类型定义** d 每个表示结构体声明的类型定义应建模为带构造型 «structure» 的 UML 类。c()
- ⌈**TR_BSWMG_00077**⌋ **结构体成员定义** d 结构体的所有成员应定义为该类的属性。属性的顺序应与生成的表中预期的顺序相同。c()
- ⌈**TR_BSWMG_00078**⌋ **结构体成员详细信息** d 对于属性应遵守以下规定：
- "Name" 字段应包含属性的名称。
- "Type" 字段应选择现有类型。
- "Scope" 字段应为 "Public"。
- "Containtment" 应为 "Not Specified"。
c()
> 图 2.16：结构体示例
##### 2.3.8.5 位域
位域类型表示一种将多个独立变量编码在一个类型中的有效方法。这是通过将位域类型分解为包含一系列位的各个位标志或位范围（bit range）的隔间来完成的。
一个典型的应用是实现独立布尔变量或"位标志"（即二进制标志）；这些标志中的每一个在位域中占用一位，并且可以独立于该类型中包含的所有其他标志设置为 true 或 false。
然而，位域不限于位标志：它们还可以包含一个或多个可被解释为每组小范围枚举类型（"位范围"）的位组。
两种用例可以在同一位域类型中混合并在多个实例中实现。位域隔间的定义使用位掩码（bitmask）完成。
位域类型还可以定义值字面量，以便为掩码值赋予具体含义。
- ⌈**TR_BSWMG_00079**⌋ **位域类型定义** d 每个表示位域声明的类型定义应建模为带构造型 «bitfield» 的 UML 类。c()
- ⌈**TR_BSWMG_00080**⌋ **位域：位标志定义** d 二进制"位标志"应使用构造型 «bitflag» 建模为位域类型的属性。c()
- ⌈**TR_BSWMG_00081**⌋ **位域：位标志值解释** d "位标志"的两个可能值应始终解释为 "TRUE" 和 "FALSE"。如果二进制值应被解释为其他含义，则应将其建模为位范围（见下文）。c()
- ⌈**TR_BSWMG_00082**⌋ **位域：位标志详细信息** d 对于位标志属性应遵守以下规定：
- "Name" 字段应包含位标志的名称。（ARXML：CompuScale 的 Short-Label）
- "Type" 字段应为空。
- "Initial Value" 字段应包含以十六进制（例如 `0x10`）或二进制（例如 `0b00010000`）表示法表示的位标志值。
- "Stereotype" 字段应为 «bitflag»。
- "Alias" 字段应为空。
- "Scope" 字段应为 "Public"。
- "Is Literal" 标志不应被设置。
- "Notes" 字段应描述位标志的含义。
c()
> 图 2.17：位域位标志示例
- ⌈**TR_BSWMG_00083**⌋ **位域：位范围定义** d 位范围是包含一个或多个位的连续位区域。位范围应使用构造型 «bitrange» 建模为位域类型的属性。c()
- ⌈**TR_BSWMG_00084**⌋ **位域：位范围详细信息** d 对于位范围属性应遵守以下规定：
- "Name" 字段应包含位范围的名称。（ARXML：Short-Label）
- "Type" 字段应为空。
- "Initial Value" 字段应包含表示位范围的位掩码，见下文。
- "Stereotype" 字段应为 «bitrange»。
- "Alias" 字段应为空。
- "Scope" 字段应为 "Public"。
- "Is Literal" 标志不应被设置。
- "Notes" 字段应描述位范围的含义。
c()
- ⌈**TR_BSWMG_00085**⌋ **位域：位范围掩码值** d 位范围使用的位的大小和位置应使用十六进制（例如 `0x1c`）或 GCC 二进制表示法（例如 `0b00011100`）的位掩码来规定。该掩码值应放在 "Initial Value" 字段中。c()
- ⌈**TR_BSWMG_00086**⌋ **位域：位掩码和位范围顺序** d 从上到下的属性顺序应按位标志或位掩码值递增（即 "Initial Value" 字段中规定的值）。c()
- ⌈**TR_BSWMG_00087**⌋ **位域：位范围值定义** d 位范围可以具有多个不同的值。这些值的含义应使用位域类型属性上的标记值来规定。c()
- ⌈**TR_BSWMG_00088**⌋ **位域：位范围值详细信息** d 每个位范围值规定由最多三个标记值组成的一组。每组以关键字 "value." 开头，后跟从 '0' 开始的数字，后跟以下三个关键字之一：
- "name"（例如 `value.0.name`）：值的名称。示例："PHYS_REQ"
- "value"（例如 `value.0.value`）：十六进制或二进制值；该值应位于其中一个位掩码的范围内。示例：`0b00010000`
- "description"（例如 `value.0.description`）：值的可选描述。示例："physical request"
c()
> 图 2.18：位域位标志和位范围组合示例
> 图 2.19：位范围 "DTC_CLASS" 的 Taggedvalues
##### 2.3.8.6 数据类型中的可变性建模
许多数据类型是可配置的，因为它们依赖于基础软件的配置。因此，在 BSW 模型中引入了所谓的"蓝图条件（blueprint conditions）"以表达例如可配置的继承。
- ⌈**TR_BSWMG_00070**⌋ **派生类型的蓝图条件** d 如果类型派生自多种其他数据类型，则泛化依赖应具有标记值 "Vh.BlueprintCondition"，该标记值规定用于选择关联的数据类型的精确条件。（例如，Vh.BlueprintCondition = platform dependent）c()
- ⌈**TR_BSWMG_00503**⌋ **CompuMethods 的蓝图策略** d 为了为类型的 compu 方法定义蓝图策略，应使用标记值 "Vh.compuMethod.BlueprintPolicy"，其合法值为 "not-modifiable"、"list" 或 "single"。
蓝图派生指南应由标记值 "Vh.compuMethod.BlueprintPolicy.DerivationGuide" 描述，对于多行指南则使用：
- "Vh.compuMethod.BlueprintPolicy.DerivationGuide.1"
- "Vh.compuMethod.BlueprintPolicy.DerivationGuide.2"
- ...
对于蓝图策略 not-modifiable 不适用。
为了显式设置蓝图策略列表的最大和最小元素数，应使用标记值 "Vh.compuMethod.BlueprintPolicy.maxElements" 和 "Vh.compuMethod.BlueprintPolicy.minElements"。c()
```yaml
Vh.compuMethod.BlueprintPolicy:
list
Vh.compuMethod.BlueprintPolicy.maxElements:
3
Vh.compuMethod.BlueprintPolicy.minElements:
1
Vh.compuMethod.BlueprintPolicy.DerivationGuide.1:
0x00 is locked
Vh.compuMethod.BlueprintPolicy.DerivationGuide.2:
0x01...0x3F is configuration dependent
Vh.compuMethod.BlueprintPolicy.DerivationGuide.3:
0x40...0xFF is Reserved by Document
```
- ⌈**TR_BSWMG_00504**⌋ **DataContraints 的蓝图策略** d 为了为类型的 data constr 定义蓝图策略，应使用标记值 "Vh.dataConstr.lowerLimit.BlueprintPolicy.DerivationGuide" 表示下限，使用标记值 "Vh.dataConstr.upperLimit.BlueprintPolicy.DerivationGuide" 表示上限。c()
- ⌈**TR_BSWMG_00505**⌋ **DataContraints 显式限制的蓝图策略** d 为了显式设置下限和上限，应使用标记值 "Vh.dataConstr.lowerLimit.value" 和 "Vh.dataConstr.upperLimit.value"。c()
- ⌈**TR_BSWMG_00506**⌋ **DataContraints 显式 blueprintValues 的蓝图策略** d 为了显式设置下限和上限 blueprintValue，应使用标记值 "Vh.dataConstr.lowerLimit.blueprintValue" 和 "Vh.dataConstr.upperLimit.blueprintValue"。c()
```yaml
Vh.dataConstr.lowerLimit.BlueprintPolicy.DerivationGuide:
For each user, a unique value must be defined at system
generation time. Maximum number of users is 255. Legal user
IDs are in the range 0 .. 254;
Vh.dataConstr.lowerLimit.blueprintValue:
min 0
Vh.dataConstr.lowerLimit.value:
undefined
Vh.dataConstr.upperLimit.BlueprintPolicy.DerivationGuide:
For each user, a unique value must be defined at system
generation time. Maximum number of users is 255. Legal user
IDs are in the range 0 .. 254;
Vh.dataConstr.upperLimit.blueprintValue:
max 254
Vh.dataConstr.upperLimit.value:
undefined
```
- ⌈**TR_BSWMG_00411**⌋ **枚举类型的可配置字面量** d 对于每个提供字面量名称的 BlueprintCondition，必须定义一个属性。属性的名称必须是名称模式，例如 ResetMode。c()
- ⌈**TR_BSWMG_00412**⌋ **枚举类型的可配置字面量** d 必须使用标记值 "Vh.BlueprintCondition" 在属性上定义提供字面量名称的 BlueprintCondition。c()
- ⌈**TR_BSWMG_00413**⌋ **枚举类型的可配置字面量** d 可配置字面量的值应使用标记值 "Vh.BlueprintValue" 在属性上定义。值字段应设置为标记值 "Vh.BlueprintValue" 中使用的变量。c()
枚举类型（EcuM_ShutdownModeType）的可配置字面量示例：
此数据类型的字面量是已配置的 EcuMResetModes 和 EcuM-SleepModes 的并集。因此必须对两个属性进行建模，分别包含获取字面量名称的条件和获取字面量 ID 的条件。
```yaml
Attribute name: {ResetMode}
Attribute value: {ResetModeId}
Vh.BlueprintCondition:
ResetMode = {ecuc(EcuM/EcuMConfiguration/EcuMFlexConfiguration/
EcuMResetMode.SHORT-NAME)}
Vh.BlueprintValue:
ResetModeId = {256 + ecuc(EcuM/EcuMConfiguration/
EcuMFlexConfiguration/EcuMResetMode.EcuMResetModeId)}
```
```yaml
Attribute name: {SleepMode}
Attribute value : {SleepModeId}
Vh.BlueprintCondition:
SleepMode = {ecuc(EcuM/EcuMConfiguration/
EcuMCommonConfiguration/EcuMSleepMode.SHORT-NAME)}
Vh.BlueprintValue:
SleepModeId = {ecuc(EcuM/EcuMConfiguration/
EcuMCommonConfiguration/EcuMSleepMode.EcuMSleepModeId)}
```
#### 2.3.9 服务建模（MoS）
服务通过端口提供。端口实现端口接口。端口接口可以是 ClientServerInterface、SenderReceiverInterface 或 ModeSwitchInterface。
- ClientServerInterface 定义可用的服务操作。服务操作定义返回、输入和输出参数。每个服务操作与现有 API 函数（C 函数）存在关系。Blueprint 允许配置参数、服务等内容。
- SenderReceiverInterface 定义 DataElements。每个数据元素必须链接到数据类型。
- ModeSwitchInterface 在 ModeDeclarationGroup 中定义模式。
**注**：为了更好地理解建模，列出了 AUTOSAR R4.0.3 SWS 文档中服务接口的非正式文本定义示例。如果您不熟悉这种旧定义，请忽略这些列表。
##### 2.3.9.1 Client Server 接口建模
以下列表显示了在 AUTOSAR R4.0.3 SWS 文档中建模/定义 ClientServerInterface 的旧语法：
```
ClientServerInterface Csm_Hash {
// errors associated with the ProtInterface
PossibleErrors {
CSM_E_NOT_OK = 1
CSM_E_BUSY = 2
CSM_E_SMALL_BUFFER = 3
};
//containing operations
//parameter kinds can be IN, OUT and INOUT
//
//ERR is not a parameter
// -> should be a associated error to an operation
HashStart (
ERR(CSM_E_NOT_OK, CSM_E_BUSY)
);
HashUpdate (
IN HashDataBuffer dataBuffer,
IN uint32 dataLength,
ERR(CSM_E_NOT_OK, CSM_E_BUSY)
);
HashFinish (
OUT HashResultBuffer resultBuffer,
INOUT HashLengthBuffer resultLength,
IN boolean TruncationIsAllowed,
ERR(CSM_E_NOT_OK, CSM_E_BUSY, CSM_E_SMALL_BUFFER)
);
};
```
> 图 2.20：Client Server 接口的示意概述
- ⌈**TR_BSWMG_00160**⌋ **MoS** d 服务建模的所有附加元素应放在包 "ARInterfaces" 中。该包应是模块包的子包。c()
- ⌈**TR_BSWMG_00100**⌋ **MoS 端口** d 端口应建模为具有以下构造型之一的 UML 端口：«RPortPrototype»、«PPortPrototype»、«PRPortPrototype»。该端口应由模块组件提供。c()
- ⌈**TR_BSWMG_00101**⌋ **MoS 端口** d 端口实现的端口接口应建模为对 ClientServerInterface、SenderReceiverInterface 或 ModeSwitchInterface 的构造型为 «abswRequires» 的依赖。c()
- ⌈**TR_BSWMG_00102**⌋ **MoS 端口接口** d 端口接口应建模为带构造型 «ClientServerInterface»、«SenderReceiverInterface» 或 «ModeSwitchInterface» 的类。构造型 «ClientServerInterface» 用于建模 Client Server 接口。构造型 «SenderReceiverInterface» 用于建模 Sender Receiver 接口。构造型 «ModeSwitchInterface» 用于建模 Mode Switch 接口。c()
- ⌈**TR_BSWMG_00154**⌋ **MoS 端口接口 isService 属性** d 接口的 isService 属性值默认为 true。要将属性设置为 false，应使用标记值 "bsw.isService"。标记值应为 "false"。c()
- ⌈**TR_BSWMG_00103**⌋ **MoS ClientServerInterface** d 通过 Client Server 接口定义的操作应建模为每个操作一个带构造型 «ClientServerOperation» 的类（每个操作一个单独的类）。c()
- ⌈**TR_BSWMG_00104**⌋ **MoS ClientServerInterface** d ClientServerInterface 与 ClientServerOperation 之间的关系应建模为构造型为 «abswOperation» 的聚合（目标为 ClientServerOperation）。c()
- ⌈**TR_BSWMG_00105**⌋ **MoS ClientServerOperation** d 每个带构造型 «ClientServerOperation» 的类应包含一个与该类同名的操作。c()
- ⌈**TR_BSWMG_00106**⌋ **MoS ClientServerOperation** d 操作的参数应建模为 UML 操作的参数。«ClientServerOperation» Class -> Operation -> Parameter。c()
- ⌈**TR_BSWMG_00107**⌋ **MoS ClientServerOperation** d 参数的 "Kind" 属性应设置为 'in'、'out'、'inout' 之一。c()
- ⌈**TR_BSWMG_00108**⌋ **MoS ClientServerInterface** d 对于每个可能的错误，应创建一个带构造型 «ApplicationError» 的类。类的名称应为错误缩写（例如 E_FORCE_RCRRP）。错误代码应建模为公共属性。名称应为 ErrorCode，错误代码应建模为初始值。c()
- ⌈**TR_BSWMG_00109**⌋ **MoS ClientServerInterface** d Client Server 接口的所有可能错误应由构造型为 «abswPossibleError» 的聚合引用（目标为 ApplicationError）。c()
- ⌈**TR_BSWMG_00110**⌋ **MoS ClientServerOperation** d Client Server 接口操作的所有可能错误应由构造型为 «abswPossibleErrorRef» 的依赖引用（目标为 ApplicationError）。c()
- ⌈**TR_BSWMG_00111**⌋ **MoS ClientServerOperation** d 每个 ClientServerOperation 应具有与相应 BSW API 函数的关系。因此，ClientServerOperation 与 BSW API 函数（函数的接口）之间的关系应建模为对 BSW API 函数的构造型为 «abswMapping» 的依赖。c()
> 图 2.21：ClientServerInterface diagamm 示例（CSI 图）
- ⌈**TR_BSWMG_00112**⌋ **MoS ClientServerInterface** d 对于每个 Client Server 接口，应创建一个类图（CSI 图）。该图的名称应为 Client Server 接口的名称。c()
- ⌈**TR_BSWMG_00113**⌋ **MoS ClientServerInterface** d CSI 图应包含模块、ClientServerInterface、ClientServerInterface 的 Application Errors 和 ClientServerInterface 的 ClientServerOperations。c()
> 图 2.22：ClientServerInterface 错误图示例（CSI 错误图）
- ⌈**TR_BSWMG_00114**⌋ **MoS ClientServerInterface** d 对于每个 Client Server 接口，应创建一个类图（CSI 错误图）。该图的名称应为 Client Server 接口的名称后接 "_Error"。c()
- ⌈**TR_BSWMG_00115**⌋ **MoS ClientServerInterface** d CSI 错误图应包含 ClientServerInterface 的 Application Errors 和 ClientServerInterface 的 ClientServerOperations。c()
> 图 2.23：ClientServerInterface BSW 映射图示例（CSI BSW 映射图）
- ⌈**TR_BSWMG_00116**⌋ **MoS ClientServerInterface** d 对于每个 Client Server 接口，应创建一个类图（CSI 映射图）。该图的名称应为 Client Server 接口的名称后接 "_BSWMapping"。c()
- ⌈**TR_BSWMG_00117**⌋ **MoS ClientServerInterface** d CSI 错误图应包含 ClientServerInterface 的 ClientServerOperations 和相应的 BSW API 接口。c()
##### 2.3.9.2 Mode Switch 接口建模
以下列表显示了在 AUTOSAR R4.0.3 SWS 文档中建模/定义 ModeSwitchInterfaces 的旧语法：
```
ModeSwitchInterface WdgM_IndividualMode {
isService = true;
WdgMMode currentMode;
};
```
对应的 ModeDeclarationGroup：
```
ModeDeclarationGroup WdgMMode {
{ SUPERVISION_OK,
SUPERVISION_FAILED,
SUPERVISION_EXPIRED,
SUPERVISION_STOPPED,
SUPERVISION_DEACTIVATED
}
initialMode = SUPERVISION_OK
};
```
> 图 2.24：Mode Switch 接口的示意概述
- ⌈**TR_BSWMG_00203**⌋ **MoS ModeDeclarationGroup** d 对于每个 ModeDeclarationGroup，应创建一个带构造型 «ModeDeclarationGroup» 的类。c()
- ⌈**TR_BSWMG_00209**⌋ **MoS ModeDeclarationGroup initialMode** d ModeDeclarationGroup 的初始模式应建模为 ModeDeclarationGroup 类的公共属性。属性的名称应为 "initialMode"，其初始值应设置为 ModeDeclarationGroup 定义的模式之一。c()
- ⌈**TR_BSWMG_00210**⌋ **MoS ModeDeclarationGroup onTransitionValue** d ModeDeclarationGroup 的可选 "onTransitionValue" 应建模为 ModeDeclarationGroup 类的公共属性。属性的名称应为 "onTransitionValue"，其初始值应设置为正整数。c()
- ⌈**TR_BSWMG_00204**⌋ **MoS ModeDeclarationGroup 模式声明** d ModeDeclarationGroup 的模式（例如 SUPERVISION_OK、SUPERVISION_FAILED 等）应建模为带构造型 «ModeDeclaration» 的 UML 类。每个模式都应是公共属性的名称。c()
- ⌈**TR_BSWMG_00211**⌋ **MoS ModeDeclarationGroup 模式声明整数** d 可以为 ModeDeclarations 分配具体的整数值。在这种情况下，模式属性的初始值应设置为正整数。c()
- ⌈**TR_BSWMG_00212**⌋ **MoS ModeDeclarationGroup 类别** d ModeDeclarationGroup 的类别应按以下方式从现有信息推断：
- 如果其关联的所有 ModeDeclaration 属性都分配了数值，则为 EXPLICIT_ORDER。
- 否则为 ALPHABETIC_ORDER。
c()
- ⌈**TR_BSWMG_00205**⌋ **MoS ModeSwitchInterface** d ModeDeclarationGroup 与模式枚举之间的关系应建模为构造型为 «abswModeType» 的聚合（目标为枚举）。c()
- ⌈**TR_BSWMG_00206**⌋ **MoS ModeSwitchInterface** d ModeSwitchInterface 类应包含一个对当前 ModeDeclarationGroup 的引用名称（例如 currentMode）的公共属性。该属性的类型应为 ModeDeclarationGroup。c()
> 图 2.25：Mode Switch 接口示例
- ⌈**TR_BSWMG_00207**⌋ **MoS ClientServerInterface** d 对于每个 Mode Switch 接口，应创建一个类图。该图的名称应为 Mode Switch 接口的名称。c()
- ⌈**TR_BSWMG_00208**⌋ **MoS ClientServerInterface** d Mode Switch 接口图应包含模块、ModeSwitchInterface、ModeDeclarationGroup 和模式枚举。c()
##### 2.3.9.3 Sender Receiver 接口建模
以下列表显示了在 AUTOSAR R4.0.3 SWS 文档中建模/定义 SenderReceiverInterface 的旧语法：
```
SenderReceiverInterface AppModeRequestInterface {
isService = true;
AppModeRequestType requestedMode;
};
```
对应类型：
```
ImplementationDataType AppModeRequestType {
lowerLimit = 0;
upperLimit = 2;
};
```
> 图 2.26：Sender Receiver 接口的示意概述
- ⌈**TR_BSWMG_00301**⌋ **MoS SenderReceiverInterface** d 发送/接收数据的类型应建模为 BSW API 类型或 MoS 类型，参见第 2.3.8 章。c()
- ⌈**TR_BSWMG_00302**⌋ **MoS SenderReceiverInterface** d SenderReceiverInterface 类应包含一个对当前发送/接收类型（例如 data）的引用名称的公共属性。该属性的类型应为有效类型，参见 TR_BSWMG_00301。c()
> 图 2.27：Sender Receiver 接口示例
- ⌈**TR_BSWMG_00307**⌋ **MoS SenderReceiverInterface** d 对于每个 Sender Receiver 接口，应创建一个类图。该图的名称应为 Mode Switch 接口的名称。c()
- ⌈**TR_BSWMG_0308**⌋ **MoS SenderReceiverInterface** d Sender Receiver 接口图应包含模块、SenderReceiverInterface 和发送/接收数据的类型。c()
##### 2.3.9.4 服务接口中特殊类型的建模
以下列表显示了在 AUTOSAR R4.0.3 SWS 文档中建模/定义类型的旧语法中类型定义的示例。
ClientServerOperations 参数上的数组定义：
```
ClientServerInterface Dcm_RequestControlServices
{
PossibleErrors {
E_NOT_OK = 1,
};
RequestControl(
OUT uint8 OutBuffer[<DcmDspRequestControlOutBufferSize>],
IN uint8 InBuffer[<DcmDspRequestControlInBufferSize>],
ERR{E_NOT_OK });
}
```
指针类型定义：
```
//The data type DataPtr refers to an address and is defined as follows:
uint32* DataLengthPtr;
```
简单类型的 DataConstraints 定义：
```
ImplementationDataType Dem_DTCStatusMaskType {
LOWER-LIMIT = 0;
UPPER-LIMIT = 255;
}
```
- ⌈**TR_BSWMG_00400**⌋ **MoS 类型** d 类型的有效构造型为 «type»、«array»、«pointer»、«structure» 和 «enumeration»。c()
- ⌈**TR_BSWMG_00401**⌋ **MoS 简单类型** d 简单类型应按 2.3.8.1 中的描述进行建模。c()
- ⌈**TR_BSWMG_00403**⌋ **MoS 数组类型** d 数组类型应建模为带构造型 «array» 的类。为了定义数组元素的类型，应创建到该类型的泛化关系。c()
- ⌈**TR_BSWMG_00409**⌋ **MoS 数组类型** d 数组大小可以选择使用标记值 "Vh.ArraySize" 来规定。c()
- ⌈**TR_BSWMG_00404**⌋ **MoS 指针类型** d 指针类型应建模为带构造型 «pointer» 的类。为了定义引用数据的类型，应创建到该类型的泛化关系。c()
- ⌈**TR_BSWMG_00405**⌋ **MoS 结构体类型** d 结构体类型应按 2.3.8.4 中的描述进行建模。c()
- ⌈**TR_BSWMG_00407**⌋ **MoS 枚举类型** d 枚举类型应按 2.3.8.2 中的描述进行建模。c()
> 图 2.28：类型定义的示意概述
##### 2.3.9.5 服务接口的可变性建模
许多服务接口是可配置的，因为它们依赖于基础软件的配置。因此，在 BSW 模型中引入了所谓的"蓝图条件"，以表达例如端口的存在依赖于特定 EcuC 参数的存在。
###### 2.3.9.5.1 在 AUTOSAR R4.0.3 SWS 文档中定义可变性的示例
以下列表显示了在 AUTOSAR R4.0.3 SWS 文档中建模/定义可变性的旧语法示例。可变性以注释形式非正式定义。
**端口中的可变性：**
```
Service ComM
{
...
// port present for each channel
// if ComMModeLimitationEnabled (see ECUC_ComM_00560);
// there are NC channels;
ProvidePort ComM_ChannelLimitation CL000;
...
ProvidePort ComM_ChannelLimitation CL<NC-1>;
...
}
```
**提供的客户端服务器操作中的可变性：**
```
ClientServerInterface Dcm_SecurityAccess
{
...
//Request to application for synchronous comparing key
//(DcmDspSecurityUsePort = USE_SYNCH_CLIENT_SERVER)
CompareKey(IN uint8 Key[<DcmDspSecurityKeySize>],
ERR{E_NOT_OK, E_COMPARE_KEY_FAILED});
//Request to application for asynchronous comparing key
//(DcmDspSecurityUsePort = USE_ASYNCH_CLIENT_SERVER)
CompareKey(IN uint8 Key[<DcmDspSecurityKeySize>],
IN Dcm_OpStatusType OpStatus,
ERR{E_NOT_OK, E_PENDING, E_COMPARE_KEY_FAILED});
}
```
**提供的客户端服务器操作参数和类型中的可变性：**
```
// ProtInterface type and name
ClientServerInterface Dcm_RoutineServices {
...
// <datatype> dataIn1,..., defines multiple parameters of
// a parameterized type
// uint8* dataInN for the last parameter is a concrete
// type defined (not parameterized)
StartFlex(
IN <datatype> dataIn1,..., IN uint8 dataInN[( <
DcmDspRoutineSignalLength of
DcmDspStartRoutineInSignal> +7)/8],
IN Dcm_OpStatusType OpStatus,
OUT <datatype> dataOut1,..., OUT uint8 dataOutN[( <
DcmDspRoutineSignalLength of
DcmDspStartRoutineOutSignal> +7)/8],
INOUT uint16 currentDataLength,
OUT Dcm_NegativeResponseCodeType ErrorCode,
ERR{E_NOT_OK, DCM_E_PENDING, E_FORCE_RCRRP });
...
};
```
**提供的接口类型中的可变性：**
```
ClientServerInterface DataServices:
Using the concepts of the SW-C template, the interface is defined as
follows if ClientServer interface is used (DcmDspDataUsePort set to
USE_DATA_SYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER):
SenderReceiver DataServices:
Using the concepts of the SW-C template, the interface is defined as
follows if SenderReceiver interface is used (DcmDspDataUsePort set
to USE_DATA_SENDER_RECEIVER):
```
###### 2.3.9.5.2 在 BSW UML 模型中对可变性进行建模
- ⌈**TR_BSWMG_00500**⌋ **MoS 可变性 NamePattern（出现次数）** d 如果端口等元素的出现次数取决于 EcuC 容器的出现次数，则条件应在标记值 "Vh.NamePattern.BlueprintPolicy.DerivationGuide" 中定义，NamePattern 应在标记值 "Vh.NamePattern" 中定义。c()
- ⌈**TR_BSWMG_00501**⌋ **MoS 可变性（存在性）** d 为了定义端口等元素的可变性，应使用标记值 "Vh.BlueprintCondition"。c()
- ⌈**TR_BSWMG_00502**⌋ **MoS 可变性多个条件** d 为了在端口等元素上定义多个条件，应在标记值名称后追加 '.' + 数字，例如 "Vh.BlueprintCondition.1"。c()
端口的可变性示例：
```yaml
Vh.BlueprintCondition:
{ecuc(ComM/ComMGeneral.ComMModeLimitationEnabled)} == true
Vh.NamePattern.BlueprintPolicy.DerivationGuide:
Name = {ecuc(ComM/ComMConfigSet/ComMChannel)}
Vh.NamePattern:
CL_{Name}
```
- ⌈**TR_BSWMG_00507**⌋ **MoS 端口接口引用可配置** d 如果端口接口的引用可由 EcuC 配置，则应使用标记值 "Vh.InterfaceRef.BlueprintPolicy.DerivationGuide"。c()
端口的可配置接口引用（BswM modeNotificationPort）：
```yaml
Vh.InterfaceRef.BlueprintPolicy.DerivationGuide:
{ecuc(BswM/BswMConfig/BswMArbitration/BswMModeRequestPort/
BswMModeRequestSource/BswMSwcModeNotification.
BswMSwcModeNotificationModeDeclarationGroupPrototypeRef)}.
parent
```
- ⌈**TR_BSWMG_00155**⌋ **MoS 端口接口可配置 isService 属性** d 如果 isService 属性的值取决于 EcuC 参数，则应使用标记值 "Vh.isService.BlueprintPolicy.DerivationGuide"。标记值应设置为引用 EcuC 参数的蓝图条件。c()
##### 2.3.9.6 PortAPIOptions 和 PortDefinedArgumentValues 的建模
- ⌈**TR_BSWMG_00118**⌋ **MoS PortAPIOption** d PortAPIOption 应建模为带构造型 «PortAPIOption» 的 UML 类。该类应放在包 `<module>/ARInterfaces/<affected interfaces>` 中。c()
- ⌈**TR_BSWMG_00119**⌋ **MoS PortAPIOption 名称** d PortAPIOption 类的名称应由端口名称后接下划线再后接字面字符串 "PortAPIOption" 组成，例如对于名为 "Func" 的端口，命名为 "Func_PortAPIOption"。c()
- ⌈**TR_BSWMG_00120**⌋ **MoS PortAPIOption 对端口的引用** d «PortAPIOption» 类应使用带构造型 «abswPortRef» 的依赖引用其影响的端口。c()
- ⌈**TR_BSWMG_00121**⌋ **MoS PortDefinedArgumentValue** d 端口定义参数值应建模为 «PortAPIOption» 类的属性。c()
- ⌈**TR_BSWMG_00122**⌋ **MoS PortDefinedArgumentValue 构造型** d 表示 Port Defined Argument Value 的属性应具有构造型 «PDAV»。c()
- ⌈**TR_BSWMG_00123**⌋ **MoS PortDefinedArgumentValue 顺序** d 如果端口使用多个 Port Defined Argument Values，则 «PortAPIOption» 类中的属性顺序应反映与端口提供的 ClientServerInterface 操作关联的 BSW 函数中的参数顺序。c()
- ⌈**TR_BSWMG_00124**⌋ **MoS PortDefinedArgumentValue 名称** d Port Defined Argument Value 属性的 'Name' 字段应与相应 BSW 函数的参数名称匹配。c()
- ⌈**TR_BSWMG_00125**⌋ **MoS PortDefinedArgumentValue 固定类型（不可配置）** d 如果 Port Defined Argument Value 是固定类型，即不可由 EcuC 参数配置，则属性的 'Type' 字段应引用建模为 BSW API 类型或 MoS 类型的有效类型。c()
- ⌈**TR_BSWMG_00126**⌋ **MoS PortDefinedArgumentValue 可配置类型** d 如果 Port Defined Argument Value 的类型可由 EcuC 参数配置，则 'Type' 字段应设置为字面字符串 `{DataType}`。大括号表示 "DataType" 被视为 EcuC 配置类型的占位符，而不是有效的数据类型本身。c()
- ⌈**TR_BSWMG_00127**⌋ **MoS PortDefinedArgumentValue 由 EcuC 配置的类型** d 如果 Port Defined Argument Value 的类型可由 EcuC 参数配置，则 EcuC 配置依赖关系应由附加到属性的标记值表示：Tag "TypeRef"，Value: "DataType = {ecuc(some/ecuc/param/dataTypeRef)}"。c()
- ⌈**TR_BSWMG_00128**⌋ **MoS PortDefinedArgumentValue 由 EcuC 配置的值** d 如果 Port Defined Argument Value 的 "value" 可由 EcuC 参数配置，则 EcuC 配置依赖关系应由附加到属性的标记值表示：Tag: "Vh.Value.BlueprintPolicy.DerivationGuide"，Value: "{ecuc(some/ecuc/param/value)}"。c()
> 图 2.29：模块 Fim ClientServerInterface ControlFunctionAvailable 的 PortAPIOption 示例
### 2.4 图表
#### 2.4.1 头文件建模
- ⌈**TR_BSWMG_00600**⌋ **头文件图** d 模块包应包含一个头文件图（Enterprise Architect：UML 组件图）。c()
- ⌈**TR_BSWMG_00601**⌋ **头文件图的命名** d 头文件图的名称应为模块组件的名称后接 `_header`，例如 `FrTp_header`。c()
- ⌈**TR_BSWMG_00602**⌋ **头文件和源代码 artifacts** d 文档 artifacts 应使用构造型 «header» 和 «source» 声明为头文件或源文件。c()
- ⌈**TR_BSWMG_00603**⌋ **文档 artifact 位置** d 文档 artifacts 应放在定义 BSW 模块的模块包中。c()
- ⌈**TR_BSWMG_00604**⌋ **Include 依赖** d 文档 artifacts 可以使用带构造型 «include» 的依赖来包含其他 artifacts。通过附加的构造型 «optional»，可以表示可选的包含关系。c()
- ⌈**TR_BSWMG_00605**⌋ **可选 Include 依赖** d 可选的包含关系可以通过在 include 依赖上指定附加的构造型 «optional» 来表示。c()
#### 2.4.2 时序图
- ⌈**TR_BSWMG_00901**⌋ **时序图的使用** d 为了对不同模块之间的交互进行建模，应使用时序图。c()
- ⌈**TR_BSWMG_00902**⌋ **时序图的位置** d 所有时序图应放在 "Interaction Views Package" 包内。c()
#### 2.4.3 状态机图
- ⌈**TR_BSWMG_00801**⌋ **状态机图的使用** d 为了对元素内和元素之间的状态依赖关系进行建模，应使用状态机图。c()
### 2.5 BSW 模型中生命周期概念的支持
AUTOSAR 在 R4.1.1 中引入了将生命周期相关信息附加到所有（可引用的）规范元素的可能性。简而言之，可以为规范元素创建 LifeCycleInfo 元素以记录其生命周期状态 - 参见 [5] 第 11.3.2 章。
- ⌈**TR_BSWMG_00700**⌋ **支持生命周期信息的模型元素** d 在 BSW 模型中，以下建模元素应能够具有生命周期信息：
- 类型定义
- API 函数
- 服务
c()
- ⌈**TR_BSWMG_00701**⌋ **模型元素中的 LifeCycleInfo 信息** d 生命周期信息由模型元素上的标记值表示。c()
- ⌈**TR_BSWMG_00702**⌋ **模型元素上生命周期信息的有效标记值** d 以下标记值可用于记录生命周期信息：
- `atp.Status`：来自官方 WP-M 生命周期定义 [6] 的值
- `atp.StatusComment`（可选）：解释性注释
- `atp.StatusRevisionBegin`：LifeCycleInfo 的适用开始
- `atp.StatusRevisionEnd`（可选）：LifeCycleInfo 的适用结束
- `atp.StatusUseInstead`（可选）：替换"过时的"或"已删除的"模型元素的元素
c()
---
## 翻译说明
本文档是 AUTOSAR 经典平台（CP）4.4.0 版本中关于基础软件 EA UML 模型建模的技术报告（TR）。文档系统地描述了如何在 Enterprise Architect UML 建模工具中表达 BSW 模块、API 函数、回调、服务接口、类型定义等元素。翻译过程中：
1. **保留**：所有需求 ID（如 TR_BSWMG_00001）、文档 ID（117）、UML 构造型的尖括号符号、参考文档标识符、代码标识符、API 函数名、模块缩写、tagged value 名称。
2. **翻译**：所有标题、说明文字、需求描述、注释。
3. **术语**：按照《翻译术语表》进行统一，如 BSW（基础软件）、RTE（运行时环境）、API（应用程序编程接口）等。
4. **结构**：将原文页脚和"X of 51"页码指示符合并到章节结构中，所有图表（Figure）以引用方式列出。
5. **代码块**：原文中的代码片段（UML 模型示例、YAML 配置）使用代码块保留。
6. **特殊处理**：AUTOSAR 方框符 `⌈⌋` 用于标记需求条目，遵循翻译规范要求保留。