P0 batch translation: 49 PDFs (General + BSWGeneral + MethodologyAndTemplates)
This commit is contained in:
opencode-translator
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,667 @@
|
||||
# AUTOSAR 对软件组件与系统建模的需求
|
||||
|
||||
> **AUTOSAR CP Release 4.4.0**
|
||||
>
|
||||
> 原文：*Requirements on SW-C and System Modeling*（文档 ID 267）
|
||||
>
|
||||
> 翻译状态：**已完成 v1**（封面+前言+目录+章节 1-6 完整翻译；所有需求表格已汉化）
|
||||
>
|
||||
> 对应原文 PDF：`General/AUTOSAR_RS_SWCModeling.pdf`
|
||||
>
|
||||
> 翻译日期：Step 3 - P0 批量翻译
|
||||
|
||||
---
|
||||
|
||||
## 文档标识
|
||||
|
||||
| 字段 | 值 |
|
||||
|------|-----|
|
||||
| 文档标题（Document Title） | 对软件组件与系统建模的需求（Requirements on SW-C and System Modeling） |
|
||||
| 文档所有者（Document Owner） | AUTOSAR |
|
||||
| 文档责任人（Document Responsibility） | AUTOSAR |
|
||||
| 文档标识号（Document Identification No） | 267 |
|
||||
| 文档状态（Document Status） | 正式版（Final） |
|
||||
| 所属 AUTOSAR 标准 | Classic Platform（经典平台） |
|
||||
| 所属标准版本 | 4.4.0 |
|
||||
|
||||
> 原文版权：© AUTOSAR — 机密文件
|
||||
> 本中文译文仅供学习参考。
|
||||
|
||||
---
|
||||
|
||||
## 免责声明（Disclaimer）
|
||||
|
||||
本作品（规范和/或软件实现）及其包含的材料由 AUTOSAR 发布，**仅供信息参考**。AUTOSAR 及为其做出贡献的公司不对作品的任何使用承担责任。
|
||||
|
||||
本作品中包含的材料受版权及其他类型知识产权保护。对本作品所含材料的商业利用需要获得这些知识产权的许可。
|
||||
|
||||
本作品可在不作任何修改的情况下、以任何形式或任何手段用于**纯信息性目的**。任何其他目的，未经出版者书面许可，作品的任何部分不得被利用或复制。
|
||||
|
||||
本作品**仅**为汽车应用而开发。它既未为非汽车应用而开发，也未为非汽车应用而进行测试。
|
||||
|
||||
"AUTOSAR" 一词和 AUTOSAR 标志是注册商标。
|
||||
|
||||
---
|
||||
|
||||
## 文档变更历史（Document Change History）
|
||||
|
||||
| 日期 | 版本 | 变更人 | 变更说明 |
|
||||
|------|------|--------|----------|
|
||||
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | • 编辑性修订（Editorial changes） |
|
||||
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | • 编辑性修订（Editorial changes） |
|
||||
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | • 编辑性修订（Editorial changes） |
|
||||
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | • 编辑性修订（Editorial changes） |
|
||||
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | • 需求表采用新格式，以实现 AUTOSAR 官方文档之间完整的可追溯性目标<br>• 根据标准化模板引入官方需求标识流程<br>• 命名约定需求扩展以涵盖 Long Names（长名称）领域 |
|
||||
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | • 与一个方法论小组保持一致，对标签进行重命名 |
|
||||
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | • 移除以下需求：MG015、MG050<br>• 新增以下需求：MG059、MG060、MG061<br>• MG014 中的 short name 长度限制设置为 128 个字符<br>• 修订法律免责声明 |
|
||||
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | • 修订法律免责声明 |
|
||||
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | • 初始发布（Initial Release） |
|
||||
|
||||
---
|
||||
|
||||
## 目录（Table of Contents）
|
||||
|
||||
1. [文档范围（Scope of Document）](#1-文档范围scope-of-document)
|
||||
- 1.1 [术语（Terminology）](#11-术语terminology)
|
||||
2. [使用的约定（Conventions to be used）](#2-使用的约定conventions-to-be-used)
|
||||
3. [缩略语与缩写（Acronyms and Abbreviations）](#3-缩略语与缩写acronyms-and-abbreviations)
|
||||
4. [命名约定需求（Naming Convention Requirements）](#4-命名约定需求naming-convention-requirements)
|
||||
- 4.1 [[RS_SWMG_00001] 区分标准化与非标准化的 ARElement 类型模型元素](#41-rs_swmg_00001-区分标准化与非标准化的-arelement-类型模型元素)
|
||||
- 4.2 [[RS_SWMG_00002] 名称应反映模型元素的用途](#42-rs_swmg_00002-名称应反映模型元素的用途)
|
||||
- 4.3 [[RS_SWMG_00005] 易于创建名称](#43-rs_swmg_00005-易于创建名称)
|
||||
- 4.4 [[RS_SWMG_00006] 模型元素的名称应自解释](#44-rs_swmg_00006-模型元素的名称应自解释)
|
||||
- 4.5 [[RS_SWMG_00007] 区分不同供应商的模型元素](#45-rs_swmg_00007-区分不同供应商的模型元素)
|
||||
- 4.6 [[RS_SWMG_00010] 模型元素名称应遵循语义规则](#46-rs_swmg_00010-模型元素名称应遵循语义规则)
|
||||
- 4.7 [[RS_SWMG_00011] 模型元素名称由标准化关键字排列组成](#47-rs_swmg_00011-模型元素名称由标准化关键字排列组成)
|
||||
- 4.8 [[RS_SWMG_00012] 模型元素名称的语义应允许可变数量的关键字](#48-rs_swmg_00012-模型元素名称的语义应允许可变数量的关键字)
|
||||
- 4.9 [[RS_SWMG_00014] Identifiable 的 short name 长度限制](#49-rs_swmg_00014-identifiable-的-short-name-长度限制)
|
||||
- 4.10 [[RS_SWMG_00016] 名称应允许表明值是直接测量值还是条件值](#410-rs_swmg_00016-名称应允许表明值是直接测量值还是条件值)
|
||||
- 4.11 [[RS_SWMG_00017] 名称应遵循 ISO 8855 进行英文命名](#411-rs_swmg_00017-名称应遵循-iso-8855-进行英文命名)
|
||||
- 4.12 [[RS_SWMG_00030] 使用英语作为名称的标准语言](#412-rs_swmg_00030-使用英语作为名称的标准语言)
|
||||
- 4.13 [[RS_SWMG_00031] 名称中不含架构信息](#413-rs_swmg_00031-名称中不含架构信息)
|
||||
- 4.14 [[RS_SWMG_00034] 关键字的唯一使用](#414-rs_swmg_00034-关键字的唯一使用)
|
||||
- 4.15 [[RS_SWMG_00039] 避免使用尾部下划线](#415-rs_swmg_00039-避免使用尾部下划线)
|
||||
- 4.16 [[RS_SWMG_00040] 避免下划线字符的连续使用](#416-rs_swmg_00040-避免下划线字符的连续使用)
|
||||
- 4.17 [[RS_SWMG_00041] 不仅依赖大小写差异区分名称](#417-rs_swmg_00041-不仅依赖大小写差异区分名称)
|
||||
- 4.18 [[RS_SWMG_00048] 易于在数据库中查找名称](#418-rs_swmg_00048-易于在数据库中查找名称)
|
||||
- 4.19 [[RS_SWMG_00049] 支持主表中已存在的 Identifiable](#419-rs_swmg_00049-支持主表中已存在的-identifiable)
|
||||
- 4.20 [[RS_SWMG_00054] 提供解决命名冲突的指南](#420-rs_swmg_00054-提供解决命名冲突的指南)
|
||||
- 4.21 [[RS_SWMG_00059] 应存在单一的关键字集](#421-rs_swmg_00059-应存在单一的关键字集)
|
||||
- 4.22 [[RS_SWMG_00060] 命名约定的适用性](#422-rs_swmg_00060-命名约定的适用性)
|
||||
- 4.23 [[RS_SWMG_00061] 命名约定应具有唯一性](#423-rs_swmg_00061-命名约定应具有唯一性)
|
||||
- 4.24 [[RS_SWMG_00062] 命名约定应规定 Short Names 与 Long Names 的构造](#424-rs_swmg_00062-命名约定应规定-short-names-与-long-names-的构造)
|
||||
5. [建模需求（Modeling Requirements）](#5-建模需求modeling-requirements)
|
||||
- 5.1 [[RS_SWMG_00052] 包结构的定义](#51-rs_swmg_00052-包结构的定义)
|
||||
- 5.2 [[RS_SWMG_00053] 模型应符合元模型](#52-rs_swmg_00053-模型应符合元模型)
|
||||
- 5.3 [[RS_SWMG_00055] 连续数据类型分辨率应为 2 的幂](#53-rs_swmg_00055-连续数据类型分辨率应为-2-的幂)
|
||||
- 5.4 [[RS_SWMG_00056] 标准化模型元素不应包含非标准化元素](#54-rs_swmg_00056-标准化模型元素不应包含非标准化元素)
|
||||
- 5.5 [[RS_SWMG_00057] 建模指南应支持 AUTOSAR 方法论](#55-rs_swmg_00057-建模指南应支持-autosar-方法论)
|
||||
6. [参考文献（References）](#6-参考文献references)
|
||||
- 6.1 [AUTOSAR 的交付物（Deliverables of AUTOSAR）](#61-autosar-的交付物deliverables-of-autosar)
|
||||
|
||||
---
|
||||
|
||||
## 1 文档范围（Scope of Document）
|
||||
|
||||
本文档定义了 AUTOSAR 内需求规范的一般规则和格式。它应作为每个需求文档的基础。
|
||||
|
||||
### 1.1 术语（Terminology）
|
||||
|
||||
- **Identifiable（可标识的）**：任何可以具有一组属性的模型元素。详细解释请参阅 AUTOSAR 元模型（"此类的实例可通过其标识符引用（同时遵守命名空间边界）"）。除非某项需求适用于特定的元模型 Identifiable（如 Port、Data Type 等），否则应使用本术语而不是 "element"、"data name" 等。
|
||||
|
||||
- **ARElement**：按 AUTOSAR 元模型中的定义："可独立定义的元素，即不属于其他元素（包除外）。与包相反，元素是封闭集合，即在基于文件的描述中，一个 ARElement 需要被完整地描述，不能被另一个文件扩展或补充。"
|
||||
|
||||
- **ARPackage**：按 AUTOSAR 元模型中的定义："AUTOSAR 包，允许创建顶级包来组织其所包含的 ARElement。ARPackage 是开放集合，这意味着在基于文件的描述系统中，可以使用多个文件部分地描述一个包的内容。这是 MSR 的 SW-SYSTEM 的扩展版本。"
|
||||
|
||||
---
|
||||
|
||||
## 2 使用的约定（Conventions to be used）
|
||||
|
||||
- AUTOSAR 文档中需求的表示遵循 [1] 中指定的表格。
|
||||
|
||||
- 在需求中，应使用以下特定语义（基于 Internet Engineering Task Force IETF）：
|
||||
|
||||
本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按以下方式解释：
|
||||
|
||||
- **SHALL（应当）**：该词表示该定义是规范的绝对要求。
|
||||
- **SHALL NOT（不得）**：该短语表示该定义是规范的绝对禁止。
|
||||
- **MUST（必须）**：该词表示由于法律问题，该定义是规范的绝对要求。
|
||||
- **MUST NOT（禁止）**：该短语表示由于法律约束，该定义是规范的绝对禁止。
|
||||
- **SHOULD（应该）/ RECOMMENDED（建议）**：该词或形容词 "RECOMMENDED" 意味着在特定情况下可能存在合理的理由去忽略某一项，但在选择不同做法之前必须充分理解并仔细权衡其全部影响。
|
||||
- **SHOULD NOT（不应该）/ NOT RECOMMENDED（不建议）**：该短语意味着在特定情况下某些行为可能是可以接受的或甚至有用的，但在实现任何带有此标签描述的行为之前，应充分理解其全部影响并仔细权衡。
|
||||
- **MAY（可以）/ OPTIONAL（可选）**：该词或形容词 "OPTIONAL" 意味着某项是真正可选的。某个供应商可能选择包含该项，因为特定市场需要它或因为供应商认为它能增强产品；而另一个供应商可能省略同一项。不包含特定选项的实现必须准备好与包含该选项的另一实现进行互操作，尽管可能功能有所降低。同理，包含特定选项的实现也必须准备好与不包含该选项的实现进行互操作（当然除了选项所提供的特性之外）。
|
||||
|
||||
---
|
||||
|
||||
## 3 缩略语与缩写（Acronyms and Abbreviations）
|
||||
|
||||
| 缩写 | 含义 |
|
||||
|------|------|
|
||||
| AR | AUTOSAR |
|
||||
| ECU | Electronic Control Unit（电子控制单元） |
|
||||
| HMI | Human Machine Interface（人机接口） |
|
||||
| MISRA | Motor Industry Software Reliability Association（汽车工业软件可靠性协会） |
|
||||
| RTE | Real Time Environment（实时环境） |
|
||||
| SW-C | Software Component（软件组件） |
|
||||
| WP | Work Package（工作包） |
|
||||
|
||||
---
|
||||
|
||||
## 4 命名约定需求（Naming Convention Requirements）
|
||||
|
||||
### 4.1 [RS_SWMG_00001] 区分标准化与非标准化的 ARElement 类型模型元素
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | valid |
|
||||
| **Description（描述）** | 命名约定应提供一个属性，用于区分 ARElement 类型的标准化与非标准化的 AUTOSAR 模型元素。 |
|
||||
| **Rationale（原理）** | -- |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | 模型元素在文档 AUTOSAR SW-C Template、ECU-Resource Template 和 System Template 中进行了规定。该需求的一种可能实现方式为：<br> - 模型元素名称的前缀<br> - 模型元素名称的后缀<br> - 标准化组件的包（不适用于 Port），这也可以作为该需求的一种解决方案。 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.2 [RS_SWMG_00002] 名称应反映模型元素的用途
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | valid |
|
||||
| **Description（描述）** | 命名约定应允许定义的名称能让人一眼看出元素的用途。 |
|
||||
| **Rationale（原理）** | 必须避免为具有不同用途的元素创建相同的名称。例如，需要区分数据流属性（如 Request 和 Status），以便对那些本应相等的名称加以区分。 |
|
||||
| **Use Case（用例）** | 识别接口和/或数据元素是命令、状态、请求、值等。<br>示例：<br> PGearEngaged（档位已接合）与 PGearRequest（档位请求） |
|
||||
| **Dependencies（依赖）** | ⌋()<br> [RS_SWMG_00005] 易于创建名称 |
|
||||
| **Supporting Material（支持材料）** | 来源：Body 域内部文档<br>`AUTOSAR_CentralLocking_ApplicationInterfaces.doc`：<br>接口/数据元素名称中关键字（如 "operation"）的语义：<br> • **Cmd**（command）：执行/激活某事（例如，从主控到执行器）<br> • **Req**（request）：请求执行/激活某事（例如，从传感器到主控）<br> • **Sta**（status）：获取功能状态信息<br> • **Hmi**：用户请求（例如，驾驶员通过开关、触摸屏等）<br> • **Dis**（display）：用于驾驶员信息显示的状态反馈<br> • **Err**（failure）：可操作/缺陷的失败反馈（从执行器到主控） |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.3 [RS_SWMG_00005] 易于创建名称
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | valid |
|
||||
| **Description（描述）** | -- |
|
||||
| **Rationale（原理）** | -- |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | 可能的解决方案：模型元素名称由预定义关键字按预定义顺序排列组成。这将导致需要定义一组预定义关键字，但可能与所需的大量关键字/关键词以及为功能开发、文档标定等用例保持名称简短和编译器规范支持的需求相冲突。 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.4 [RS_SWMG_00006] 模型元素的名称应自解释
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | valid |
|
||||
| **Description（描述）** | -- |
|
||||
| **Rationale（原理）** | -- |
|
||||
| **Use Case（用例）** | 例如，数据元素、端口、接口、组合等。 |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | -- |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.5 [RS_SWMG_00007] 区分不同供应商的模型元素
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | 建模指南应定义一个属性，用于区分不同模型元素供应商的模型元素。这仅适用于非标准化模型元素。 |
|
||||
| **Rationale（原理）** | 在将不同供应商的软件组件描述合并为系统模型时，避免合并冲突。品牌责任。 |
|
||||
| **Use Case（用例）** | 在 AUTOSAR 包内使用非标准化元素。如果出现错误，则需要追溯到负责该错误出现的 SW-C 供应商。 |
|
||||
| **Dependencies（依赖）** | 若通过命名约定解决：不适用于 `ModeDeclarationGroupPrototype`、`DataElementPrototype`、`CalprmElementPrototype`、`OperationPrototype`、`ArgumentPrototype`，因为端口可连接的前提是名称的一致性。 |
|
||||
| **Supporting Material（支持材料）** | 既可以通过命名约定实现，也可以通过使用其他模型元素（如 `AdminData`）实现。 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.6 [RS_SWMG_00010] 模型元素名称应遵循语义规则
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | valid |
|
||||
| **Description（描述）** | -- |
|
||||
| **Rationale（原理）** | 通过这样做，对命名约定的符合性可以通过名称检查器或名称创建工具进行验证。 |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | ⌋()<br> [RS_SWMG_00005] 易于创建名称<br> ⌋()<br> [RS_SWMG_00048] 易于在数据库中查找名称 |
|
||||
| **Supporting Material（支持材料）** | 建模指南、AI 规范 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.7 [RS_SWMG_00011] 模型元素名称由标准化关键字排列组成
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | valid |
|
||||
| **Description（描述）** | -- |
|
||||
| **Rationale（原理）** | 通过这样做，对命名约定的符合性可以通过名称检查器或名称创建工具进行验证。如果关键字和缩略语未标准化，名称长度限制会导致名称难以理解。 |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | ⌋()<br> [RS_SWMG_00005] 易于创建名称<br> ⌋()<br> [RS_SWMG_00034] 关键字的唯一使用 |
|
||||
| **Supporting Material（支持材料）** | 建模指南、AI 规范 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.8 [RS_SWMG_00012] 模型元素名称的语义应允许可变数量的关键字
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | valid |
|
||||
| **Description（描述）** | 组合关键字的数量应取决于解释的需要。 |
|
||||
| **Rationale（原理）** | 创建的名称应尽可能简单，但应按需复杂。 |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | ⌋()<br> [RS_SWMG_00005] 易于创建名称<br> ⌋()<br> [RS_SWMG_00010] 模型元素名称应遵循语义规则<br> ⌋()<br> [RS_SWMG_00034] 关键字的唯一使用 |
|
||||
| **Supporting Material（支持材料）** | 建模指南<br>解决方案示例：<br> `Eng_tqCluReqDrvSlow` → Engine Torque at Clutch Slow Request（发动机离合器慢速请求扭矩）<br> `Veh_v` → Vehicle Speed（车速） |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.9 [RS_SWMG_00014] Identifiable 的 short name 长度限制
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | Identifiable 的 Short Name 应限制为总长度 128 个字符。 |
|
||||
| **Rationale（原理）** | Short Name 部分用于 C 语言名称的创建。这些创建的名称应具有可预测的最大长度，以避免工具问题。（即使此长度大于 MISRA 指南建议，也不应是无限制的。） |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | 元模型中已存在将字符数限制为 128 的规则：`[a-zA-Z][a-zA-Z_0-9]{0-127}`。 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.10 [RS_SWMG_00016] 名称应允许表明值是直接测量值还是条件值
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | 名称应表明值是从传感器测量的（可能经过偏移补偿和/或滤波），还是基于一组信息或模型计算/估计得到的。 |
|
||||
| **Rationale（原理）** | -- |
|
||||
| **Use Case（用例）** | 传感器 SW-C 输出测量的物理值，并将其馈送给负责滤波的另一个 SW-C。在这种情况下，数据元素、端口和接口的名称仅因一个关键字而不同，并且数据类型可以相同。 |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | 可能的解决方案：在名称语义中使用专门的关键字来指示此类信息。 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.11 [RS_SWMG_00017] 名称应遵循 ISO 8855 进行英文命名
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | 本标准定义了车辆动力学的主要术语，适用于（不仅限于）乘用车。提供了多种语言的定义，仅应遵循英文定义。 |
|
||||
| **Rationale（原理）** | -- |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | ⌋()<br> [RS_SWMG_00030] 使用英语作为名称的标准语言 |
|
||||
| **Supporting Material（支持材料）** | -- |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.12 [RS_SWMG_00030] 使用英语作为名称的标准语言
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | 名称和缩略语应使用英语。 |
|
||||
| **Rationale（原理）** | 名称和关键字的国际性和共同理解。 |
|
||||
| **Use Case（用例）** | 不同国籍的设计师在定义新名称时将得出相同的解决方案。 |
|
||||
| **Dependencies（依赖）** | ⌋()<br> [RS_SWMG_00017] 名称应遵循 ISO 8855 进行英文命名 |
|
||||
| **Supporting Material（支持材料）** | Powertrain 域命名约定 1.0 §1.4 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.13 [RS_SWMG_00031] 名称中不含架构信息
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | 名称中不应包含架构或实现信息的定义。 |
|
||||
| **Rationale（原理）** | 增加标准元素的可重用性并降低维护成本。 |
|
||||
| **Use Case（用例）** | 创建不同的组件组合而不改变任何元素名称。 |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | Powertrain 域命名约定 1.0 §1.4 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.14 [RS_SWMG_00034] 关键字的唯一使用
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | 用于组成名称的关键字应是唯一的。关键字的多义性是允许的，除非检测到违反语义规则的情况。 |
|
||||
| **Rationale（原理）** | -- |
|
||||
| **Use Case（用例）** | 名称相对一致性的自动检查将成为可能。 |
|
||||
| **Dependencies（依赖）** | ⌋()<br> [RS_SWMG_00010] 模型元素名称应遵循语义规则<br> ⌋()<br> [RS_SWMG_00011] 模型元素名称由标准化关键字排列组成 |
|
||||
| **Supporting Material（支持材料）** | Powertrain 域命名约定 1.0 §1.4 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.15 [RS_SWMG_00039] 避免使用尾部下划线
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | 名称不应以下划线 "_" 字符结尾。 |
|
||||
| **Rationale（原理）** | AUTOSAR 工具（如 RTE）使用 "_" 来指示跨 AR 层的信息流路径。这将有助于更好地理解工具生成的名称，并限制名称中的字符数。 |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | Powertrain 域命名约定 1.0 §2 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.16 [RS_SWMG_00040] 避免下划线字符的连续使用
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | 避免下划线字符彼此直接连续出现 [__]。 |
|
||||
| **Rationale（原理）** | 浪费字符空间。 |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | Powertrain 域命名约定 1.0 §2 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.17 [RS_SWMG_00041] 不仅依赖大小写差异区分名称
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | 避免仅通过大写/小写格式来区分名称。 |
|
||||
| **Rationale（原理）** | 人类用户很容易混淆仅在大小写上不同的名称。 |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | Powertrain 域命名约定 1.0 §2 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.18 [RS_SWMG_00048] 易于在数据库中查找名称
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | -- |
|
||||
| **Rationale（原理）** | -- |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | ⌋()<br> [RS_SWMG_00005] 易于创建名称 |
|
||||
| **Supporting Material（支持材料）** | -- |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.19 [RS_SWMG_00049] 支持主表中已存在的 Identifiable
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | valid |
|
||||
| **Description（描述）** | 主表（Master Table）中使用的所有模型元素类型，如 `SenderReceiver` 接口、`DataElement`、`DataType`、`Unit`、`Component` 类型等，都应受建模规则支持。 |
|
||||
| **Rationale（原理）** | -- |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | AI 规范是文件中列出的 Identifiable 的占位符。 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.20 [RS_SWMG_00054] 提供解决命名冲突的指南
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | valid |
|
||||
| **Description（描述）** | 建模指南应提供关于如何解决相关元素之间命名冲突的指南。 |
|
||||
| **Rationale（原理）** | -- |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | 该需求的一种可能实现是使用前缀。要定义 `PrimitiveTypeWithSemantics`，还需要 `CompuMethod` 定义。使用前缀解决方案，名称可能如下：<br> `PrimitiveTypeWithSemantic`：`Veh_v` 用于车辆速度<br> `CompuMethode`：`Compu_Veh_v` 用于车辆速度数据类型<br> `Interface`：`If_Veh_v` 用于车辆速度的接口<br>前缀解决方案的缺点是会增加名称的长度，并可能导致违反 RS_SWMG_00014。<br>另一种可能的解决方案是使用子包。 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.21 [RS_SWMG_00059] 应存在单一的关键字集
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | valid |
|
||||
| **Description（描述）** | 建模指南应提供标准化关键字的列表。 |
|
||||
| **Rationale（原理）** | 为确保命名约定的唯一性，所有关键字应收集在一个关键字列表中。 |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | 一种可能的解决方案是将单独文档作为关键字的开发工作产品，并在需要建模指南文档的里程碑时仅包含最终确定的关键字列表。这将使建模指南免于因关键字列表的讨论和演变而频繁迭代。 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.22 [RS_SWMG_00060] 命名约定的适用性
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | valid |
|
||||
| **Description（描述）** | 命名约定必须适用于 AUTOSAR 的所有车辆应用域。 |
|
||||
| **Rationale（原理）** | 1) 在任意方愿意合作的开放环境中，所有方都应使用相同的命名约定。<br>2) 如果支持特定域或方的专用命名约定，则该约定的接受度将非常低。许多方会争辩说他们需要针对其领域的特定约定。 |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | [RS_SWMG_00002] 名称应反映模型元素的用途，<br> ⌋()<br> [RS_SWMG_00005] 易于创建名称，<br> ⌋()<br> [RS_SWMG_00006] 模型元素的名称应自解释，<br> ⌋()<br> [RS_SWMG_00034] 关键字的唯一使用 |
|
||||
| **Supporting Material（支持材料）** | 通用命名约定的全球接受将需要时间，但不应限制该标准的要求。 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.23 [RS_SWMG_00061] 命名约定应具有唯一性
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | valid |
|
||||
| **Description（描述）** | 命名约定必须声明清晰且确定性的名称创建规则，以便可以从信号特征唯一地确定名称。 |
|
||||
| **Rationale（原理）** | 1) 支持分布式开发<br>2) 避免冗余信号的定义，因为不同的开发人员将通过应用相同的规则来创建名称。<br>3) 避免信号的误用。<br>4) 启用一致性检查和基于工具的名称处理。<br>5) 增强可读性，因为所有开发人员/名称用户都形成相同的思维模式。 |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | [RS_SWMG_00002] 名称应反映模型元素的用途，<br> ⌋()<br> [RS_SWMG_00006] 模型元素的名称应自解释，<br> ⌋()<br> [RS_SWMG_00010] 模型元素名称应遵循语义规则，<br> ⌋()<br> [RS_SWMG_00011] 模型元素名称由标准化关键字排列组成<br> ⌋()<br> [RS_SWMG_00016] 名称应允许表明值是直接测量值还是条件值<br> ⌋()<br> [RS_SWMG_00031] 名称中不含架构信息<br> ⌋()<br> [RS_SWMG_00034] 关键字的唯一使用<br> [RS_SWMG_00054] 提供解决命名冲突的指南<br> [RS_SWMG_00059] 应存在单一的关键字集 |
|
||||
| **Supporting Material（支持材料）** | 该需求背后的理念是，信号的名称可以根据信号的特征（如提供者、物理单位等）唯一确定。 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 4.24 [RS_SWMG_00062] 命名约定应规定 Short Names 与 Long Names 的构造
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | valid |
|
||||
| **Description（描述）** | 命名约定应通过一组清晰的规则和建议来规定 short name 和 long name 的构造。 |
|
||||
| **Rationale（原理）** | 为支持清晰、易于理解的 short name 和 long name 的构造，并鼓励 AI 域中元素的复用。 |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | [RS_SWMG_00002] 名称应反映模型元素的用途，<br> ⌋()<br> [RS_SWMG_00006] 模型元素的名称应自解释，<br> ⌋()<br> [RS_SWMG_00010] 模型元素名称应遵循语义规则，<br> ⌋()<br> [RS_SWMG_00011] 模型元素名称由标准化关键字排列组成<br> [RS_SWMG_00012] 模型元素名称的语义应允许可变数量的关键字<br> ⌋()<br> [RS_SWMG_00016] 名称应允许表明值是直接测量值还是条件值<br> ⌋()<br> [RS_SWMG_00034] 关键字的唯一使用<br> [RS_SWMG_00049] 支持主表中已存在的 Identifiable<br> [RS_SWMG_00054] 提供解决命名冲突的指南<br> [RS_SWMG_00059] 应存在单一的关键字集<br> [RS_SWMG_00060] 命名约定的适用性<br> [RS_SWMG_00061] 命名约定应具有唯一性 |
|
||||
| **Supporting Material（支持材料）** | 建模指南、元模型、AI 规范 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
## 5 建模需求（Modeling Requirements）
|
||||
|
||||
### 5.1 [RS_SWMG_00052] 包结构的定义
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | 建模指南应规定用于标准化 AUTOSAR 元素的包结构。 |
|
||||
| **Rationale（原理）** | 在使用标准化 M1 AUTOSAR 模型元素时，可进行无路径冲突的模型交换。 |
|
||||
| **Use Case（用例）** | 建模指南应规定用于功能接口规范中的 `DataType`、`SenderReceiverInterface` 等的包。 |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | -- |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 5.2 [RS_SWMG_00053] 模型应符合元模型
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | AUTOSAR 元模型定义了 AUTOSAR 模型的结构。由于主表包含描述应用接口每个域规范所需的数据，因此必须与元模型保持一致。所有模型元素属性的使用应符合元模型的定义。 |
|
||||
| **Rationale（原理）** | -- |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | 元模型 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 5.3 [RS_SWMG_00055] 连续数据类型分辨率应为 2 的幂
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | 连续数据类型的分辨率应为 2 的幂（以倍数或倒数的形式表示）。 |
|
||||
| **Rationale（原理）**** | 由于成本原因，当今市场上大多数商用处理器没有硬件浮点运算支持。为避免或限制此类功能的软件仿真（将导致软件执行开销），通常使用定点（整数）数学。<br>大部分处理器甚至没有整数乘法硬件支持。通过为定点（整数）数分配以 2 的幂表示的分辨率，乘法和除法的软件仿真将仅减少为算法功能上需要的那些操作。 |
|
||||
| **Use Case（用例）** | 在 SWC 算法中，将分辨率为 0.001/lsb 的增益应用于类型为 UInt16 且分辨率为 0.004/lsb 的变量，以获得具有相同分辨率的结果。<br>在这种情况下，除了应用增益所需的乘法和范围饱和外，还需要除以 1000 以将结果重新缩放到所请求的分辨率。<br>通过将操作数转换为 2 的幂分辨率，即变量的 -8 次方/lsb 和增益的 -10 次方/lsb，重新缩放将通过 10 位的逻辑右移执行（在某些微处理器中只需一个指令周期），并且相对于第一种解决方案没有精度损失。 |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | -- |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 5.4 [RS_SWMG_00056] 标准化模型元素不应包含非标准化元素
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | 标准化模型元素不应包含非标准化元素。 |
|
||||
| **Rationale（原理）** | 为避免混淆，必须使一个元素完全标准化，即使不是部分标准化。 |
|
||||
| **Use Case（用例）** | -- |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | 建议的冲突解决方案如下：<br>- 定义一种新的非标准化组合类型，其中包含标准化组件类型和附加的非标准化组件。<br>- 这种组合的接口可以是标准化组件类型的所有端口加上附加的非标准化端口。 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
### 5.5 [RS_SWMG_00057] 建模指南应支持 AUTOSAR 方法论
|
||||
|
||||
⌈
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Type（类型）** | Valid |
|
||||
| **Description（描述）** | 建模指南应给出指导原则，即应尽可能利用模型元素的可重用性。 |
|
||||
| **Rationale（原理）** | 通过充分利用 AUTOSAR 方法论的可能性，由不一致引起的冲突将减少，不必要的冗余将被消除，数据的维护将得到改善。 |
|
||||
| **Use Case（用例）** | 在使用相同范围和分辨率时，为不同接口定义相同数据类型的 Data Element。 |
|
||||
| **Dependencies（依赖）** | -- |
|
||||
| **Supporting Material（支持材料）** | AUTOSAR 元模型。 |
|
||||
|
||||
⌋()
|
||||
|
||||
---
|
||||
|
||||
## 6 参考文献（References）
|
||||
|
||||
### 6.1 AUTOSAR 的交付物（Deliverables of AUTOSAR）
|
||||
|
||||
| 编号 | 名称 | 文档 |
|
||||
|------|------|------|
|
||||
| [1] | Software Standardization Template | `AUTOSAR_TPS_StandardizationTemplate.pdf` |
|
||||
|
||||
---
|
||||
|
||||
## 翻译说明
|
||||
|
||||
- 本文档为**需求规范类**，包含 30 项编号需求（RS_SWMG_00001 ~ RS_SWMG_00062），已全部翻译并保留需求 ID
|
||||
- API 标识符、模块缩写（如 SW-C/AR/RTE/BSW/AI）、需求 ID（如 RS_SWMG_xxxxx）保持英文不译
|
||||
- AUTOSAR 方框符 `⌈⌋` 已保留，用于标记需求表格的开始与结束
|
||||
- 文档间交叉引用（如 [TPS_STDT_xxxxx]）已保留
|
||||
- 原文中 "MUST/SHALL" 等 RFC 2119 关键词的语义解释已按其标准含义翻译
|
||||
|
||||
---
|
||||
|
||||
*翻译：opencode-translator / Step 3 P0 批量翻译*
|
||||
@@ -0,0 +1,925 @@
|
||||
# AUTOSAR 应用设计模式目录
|
||||
|
||||
> **AUTOSAR CP Release 4.4.0**
|
||||
>
|
||||
> 原文：*Application Design Patterns Catalogue*（文档 ID 672）
|
||||
>
|
||||
> 翻译状态：**已完成 v1**（封面+前言+目录+章节 1-4、附录 A-B 完整翻译）
|
||||
>
|
||||
> 对应原文 PDF：`General/AUTOSAR_TR_AIDesignPatternsCatalogue.pdf`
|
||||
>
|
||||
> 翻译日期：Step 3 - P0 批量翻译
|
||||
|
||||
---
|
||||
|
||||
## 文档标识
|
||||
|
||||
| 字段 | 值 |
|
||||
|------|-----|
|
||||
| 文档标题（Document Title） | 应用设计模式目录（Application Design Patterns Catalogue） |
|
||||
| 文档所有者（Document Owner） | AUTOSAR |
|
||||
| 文档责任人（Document Responsibility） | AUTOSAR |
|
||||
| 文档标识号（Document Identification No） | 672 |
|
||||
| 文档状态（Document Status） | 正式版（Final） |
|
||||
| 所属 AUTOSAR 标准 | Classic Platform（经典平台） |
|
||||
| 所属标准版本 | 4.4.0 |
|
||||
|
||||
> 原文版权：© AUTOSAR — 机密文件
|
||||
> 本中文译文仅供学习参考。
|
||||
|
||||
---
|
||||
|
||||
## 免责声明（Disclaimer）
|
||||
|
||||
本作品（规范和/或软件实现）及其包含的材料由 AUTOSAR 发布，**仅供信息参考**。AUTOSAR 及为其做出贡献的公司不对作品的任何使用承担责任。
|
||||
|
||||
本作品中包含的材料受版权及其他类型知识产权保护。对本作品所含材料的商业利用需要获得这些知识产权的许可。
|
||||
|
||||
本作品可在不作任何修改的情况下、以任何形式或任何手段用于**纯信息性目的**。任何其他目的，未经出版者书面许可，作品的任何部分不得被利用或复制。
|
||||
|
||||
本作品**仅**为汽车应用而开发。它既未为非汽车应用而开发，也未为非汽车应用而进行测试。
|
||||
|
||||
"AUTOSAR" 一词和 AUTOSAR 标志是注册商标。
|
||||
|
||||
---
|
||||
|
||||
## 文档变更历史（Document Change History）
|
||||
|
||||
| 日期 | 版本 | 变更人 | 变更说明 |
|
||||
|------|------|--------|----------|
|
||||
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | • 编辑性修订（Editorial changes） |
|
||||
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | • 编辑性修订（Editorial changes） |
|
||||
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | • 仲裁模式通用化，三个示例：多个设定值请求者、多个估计值的提供者、多个合并值的提供者<br>• 次要变更<br>• 重新考虑信号定义以及针对智能执行器和无反馈回路执行器的定制模式 |
|
||||
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | • 添加规范项<br>• 次要变更 |
|
||||
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | • 文档首次发布。涵盖的模式：<br> - 传感器与执行器模式（Sensor and Actuator Pattern）<br> - 多设定值请求者仲裁模式（Arbitration of Several Set-point Requester Pattern）<br>• 之前作为 `EXP_AIPowertrain` 的一部分发布 |
|
||||
|
||||
---
|
||||
|
||||
## 目录（Table of Contents）
|
||||
|
||||
1. [介绍（Introduction）](#1-介绍introduction)
|
||||
- 1.1 [文档约定（Document conventions）](#11-文档约定document-conventions)
|
||||
- 1.2 [需求追踪（Requirements Tracing）](#12-需求追踪requirements-tracing)
|
||||
2. [关于模式（About Patterns）](#2-关于模式about-patterns)
|
||||
- 2.1 [模式类型（Types of Pattern）](#21-模式类型types-of-pattern)
|
||||
- 2.2 [模式描述（Describing Patterns）](#22-模式描述describing-patterns)
|
||||
3. [传感器与执行器模式（Sensor and Actuator Pattern）](#3-传感器与执行器模式sensor-and-actuator-pattern)
|
||||
- 3.1 [问题（Problem）](#31-问题problem)
|
||||
- 3.2 [其他名称（Also Known As）](#32-其他名称also-known-as)
|
||||
- 3.3 [适用性（Applicability）](#33-适用性applicability)
|
||||
- 3.4 [解决方案（Solution）](#34-解决方案solution)
|
||||
- 3.5 [命名（Naming）](#35-命名naming)
|
||||
- 3.6 [示例（Example）](#36-示例example)
|
||||
- 3.7 [样例代码与模型（Sample Code and Model）](#37-样例代码与模型sample-code-and-model)
|
||||
- 3.8 [已知用途（Known Uses）](#38-已知用途known-uses)
|
||||
- 3.9 [相关模式（Related Patterns）](#39-相关模式related-patterns)
|
||||
- 3.10 [需要注意的反模式（Anti-Patterns One Should be Aware of）](#310-需要注意的反模式anti-patterns-one-should-be-aware-of)
|
||||
- 3.11 [延伸阅读（Further Readings）](#311-延伸阅读further-readings)
|
||||
4. [多个请求者或提供者之间的仲裁（Arbitration between several requesters or providers）](#4-多个请求者或提供者之间的仲裁arbitration-between-several-requesters-or-providers)
|
||||
- 4.1 [问题（Problem）](#41-问题problem)
|
||||
- 4.2 [适用性（Applicability）](#42-适用性applicability)
|
||||
- 4.3 [解决方案（Solution）](#43-解决方案solution)
|
||||
- 4.4 [示例（Examples）](#44-示例examples)
|
||||
- 4.5 [样例代码与模型（Sample Code and Model）](#45-样例代码与模型sample-code-and-model)
|
||||
- 4.6 [已知用途（Known Uses）](#46-已知用途known-uses)
|
||||
- 4.7 [相关模式（Related Patterns）](#47-相关模式related-patterns)
|
||||
- [附录 A - 变更历史（Change History）](#附录-a---变更历史change-history)
|
||||
- [附录 B - 引用的类表（Mentioned Class Tables）](#附录-b---引用的类表mentioned-class-tables)
|
||||
|
||||
---
|
||||
|
||||
## 1 介绍（Introduction）
|
||||
|
||||
### 1.1 文档约定（Document conventions）
|
||||
|
||||
技术术语（类名）以等宽字体排版，例如 `FrameTriggering`。
|
||||
|
||||
在定义名称模式时，使用根据 ANTLR 定义的语法 [1]。使用 [2]、[TPS_STDT_00055] 中定义的名称模式语法。下面我们仅列出在本文档中使用的最重要的占位符：
|
||||
|
||||
- **anyName**：表示一个字符串，它是符合 `Identifier` 的有效 `shortName`。
|
||||
- **anyNamePart**：表示一个字符串 `(([a-zA-Z0-9]|_[a-zA-Z0-9])*_?)`，它是 `shortName` 的有效部分。
|
||||
- 提示：占位符 `anyNamePart` 不应在 `shortName` 模式的开头使用，以避免无效的 shortName。
|
||||
- **blueprintName**：表示所应用 blueprint 的 `shortName` / `shortLabel` / `symbol`。
|
||||
- **componentName**：表示 BSW 模块或与派生对象相关的 ASW `SwComponentType` / ASW 组件原型的 `shortName`。"相关" 主要可以是聚合或引用。
|
||||
- 占位符 `componentName` 特别支持在不同的软件组件类型或模块的上下文中对 `PortPrototypeBlueprint` 进行多重派生 [TPS_STDT_00036]。
|
||||
- **componentTypeName**：表示专用 `SwComponentType` 的 `shortName`。
|
||||
- **componentPrototypeName**：表示专用 `SwComponentPrototype` 的 `shortName`。
|
||||
- **index**：表示适用于例如数组的数值索引。
|
||||
- **keyword**：表示作为 short name 名称部分的关键字的 `abbrName` [TPS_STDT_00004]。
|
||||
|
||||
完整描述请参见 [2]、[TPS_STDT_00055]。此外，我们假设 [3] 中定义的命名规则已得到满足。如果适用且可用，名称中使用的是 [4] 中标准化的关键字。
|
||||
|
||||
此外，我们使用以下占位符扩展语法：
|
||||
|
||||
- **anyLongName**：表示一个字符串，它是有效的 `longName`。
|
||||
- 此外，我们假设 [TR_SWNR_0064] 已得到满足。这意味着 long name 以大写字母开头，并且除冠词（例如 "a"、"the"）、介词（例如 "at"、"by"、"to"）和连词（例如 "and"、"or"）之外的所有单词也以大写字母开头。
|
||||
- **anyLongNamePart**：表示一个字符串，它是 `longName` 的有效部分。
|
||||
|
||||
### 1.2 需求追踪（Requirements Tracing）
|
||||
|
||||
针对本文档的需求在需求文档 [5] 中声明。下表引用了 [5] 中指定的需求，并提供了满足给定需求的各个规范项的信息。
|
||||
|
||||
| 需求 | 描述 | 由以下规范项满足 |
|
||||
|------|------|------------------|
|
||||
| [RS_MAIN_00060] | AUTOSAR 应为应用之间的通信提供标准化的软件接口 | [TR_AIDPC_00006]<br>[TR_AIDPC_00007] |
|
||||
| [RS_MAIN_00080] | AUTOSAR 应提供描述应用软件组件模型的方法 | [TR_AIDPC_00001]<br>[TR_AIDPC_00002] |
|
||||
| [RS_MAIN_00130] | AUTOSAR 应提供对硬件的抽象 | [TR_AIDPC_00001]<br>[TR_AIDPC_00002] |
|
||||
| [RS_MAIN_00140] | AUTOSAR 应为应用提供与网络无关的通信机制 | [TR_AIDPC_00001]<br>[TR_AIDPC_00002]<br>[TR_AIDPC_00003] |
|
||||
| [RS_MAIN_00150] | AUTOSAR 应支持 AUTOSAR 应用软件的部署和重新分配 | [TR_AIDPC_00001]<br>[TR_AIDPC_00002] |
|
||||
| [RS_MAIN_00400] | AUTOSAR 应提供分层软件架构 | [TR_AIDPC_00001]<br>[TR_AIDPC_00002]<br>[TR_AIDPC_00003]<br>[TR_AIDPC_00004] |
|
||||
| [RS_MAIN_00410] | AUTOSAR 应为应用软件常用的例程提供规范，以支持共享和优化 | [TR_AIDPC_00003] |
|
||||
| [RS_MAIN_00500] | AUTOSAR 应提供命名约定 | [TR_AIDPC_00005] |
|
||||
|
||||
---
|
||||
|
||||
## 2 关于模式（About Patterns）
|
||||
|
||||
本文档概述了 AUTOSAR 中定义的模式，以简化 AUTOSAR 架构、AUTOSAR 应用接口和 AUTOSAR 元模型的使用。重点是应用软件（ASW）。
|
||||
|
||||
### 2.1 模式类型（Types of Pattern）
|
||||
|
||||
区分以下类别/分类的模式：
|
||||
|
||||
- **架构模式（Architectural Pattern）**：架构模式是软件架构领域的标准设计。架构模式的概念比设计模式的概念具有更广泛的范围。架构模式涉及软件工程中的各种问题，例如计算机硬件性能限制、高可用性和业务风险的最小化 [6]。
|
||||
|
||||
- **设计模式（Design Pattern）**：在软件工程中，设计模式是在软件设计中给定上下文中对常见问题的一般可重用解决方案。设计模式不是可以直接转换为源代码或机器代码的成品设计。它是关于如何解决问题的描述或模板，可在许多不同的情况下使用。模式是程序员必须在应用程序中自己实现的形式化最佳实践 [7]。
|
||||
|
||||
- **解决方案模式（Solution Pattern）**：解决方案模式描述了针对特定问题（例如错误处理或作业调度）的通用解决方案 [6]。
|
||||
|
||||
正交的分类如下：
|
||||
|
||||
- **设计模式（Design Patterns）**：在架构和计算机科学中，设计模式是在特定专业领域正式记录设计问题解决方案的方法 [8]。
|
||||
|
||||
- **反模式（Anti-Patterns）**：在软件工程中，反模式是用于社会或商业运营或软件工程中的模式，可能是常用的，但在实践中是无效和/或适得其反的 [9]。
|
||||
|
||||
### 2.2 模式描述（Describing Patterns）
|
||||
|
||||
本文档中模式的描述遵循预定义的结构。该结构基于文档 [7]、[10]、[11]、[1] 和 [2] 的内容创建。
|
||||
|
||||
模式在单独的章节中描述，特定模式的头部包含模式名称和模式标识（标准化名称）：
|
||||
|
||||
```
|
||||
{模式名称}（{模式标识}）
|
||||
```
|
||||
|
||||
在描述特定模式章节的最开始处，分类如下所示给出：
|
||||
|
||||
```
|
||||
分类 {模式类型} 模式
|
||||
```
|
||||
|
||||
模式的类型是 2.1 节中描述的类别之一。
|
||||
|
||||
| 章节 | 必填 | 描述 | 附加信息 |
|
||||
|------|------|------|----------|
|
||||
| **Problem（问题）** | 是 | 设计模式所解决的问题及其一般原理和目的。 | 无 |
|
||||
| **Also Known As（其他名称）** | 否 | 该模式的其他名称（如果有）。 | 无 |
|
||||
| **Applicability（适用性）** | 是 | 对系统必须具备的特征的一般描述，以使该模式在程序的设计或实现中可用。 | 适应症：表明该模式可能适用的迹象；禁忌症：表明该模式不适用的情况。 |
|
||||
| **Solution（解决方案）** | 是 | 模式的文本或图形描述。这提供了模式结构方面的详细规范，使用适当的表示法。 | 还要考虑**过度效应（Overdose Effect）**：如果反复应用建议的操作，会发生什么不良后果。<br>还要考虑**副作用（Side Effects）**：应用解决方案时可能出现的新问题或浮现的新问题。 |
|
||||
| **Naming（命名）** | 否 | 描述在模式上下文中可用或应使用的命名模式。 | 名称模式遵循根据 ANTLR 定义的语法，如 [2] 中决定使用的语法，例如在 [TPS_STDT_00055] 中。 |
|
||||
| **Example（示例）** | 是 | 如何应用该模式的示例。 | 无 |
|
||||
| **Sample Code and Model（样例代码与模型）** | 否 | 提供如何实现该模式示例的代码或模型。 | 无 |
|
||||
| **Known Uses（已知用途）** | 否 | 取自现有系统或文献的该模式的使用示例。 | 无 |
|
||||
| **Related Patterns（相关模式）** | 否 | 与该模式有某种关系的其他模式；讨论该模式与类似模式之间的差异。 | 其他相关的模式（上级、下级、竞争或邻近模式），并参考可找到它们的位置。 |
|
||||
| **Anti-Patterns（反模式）** | 否 | 您应该注意的反模式。 | 无 |
|
||||
| **Reading（阅读）** | 否 | 值得进一步了解的材料。 | 无 |
|
||||
|
||||
**表 2.1：模式描述模板**
|
||||
|
||||
---
|
||||
|
||||
## 3 传感器与执行器模式（Sensor and Actuator Pattern）
|
||||
|
||||
**分类**：设计模式
|
||||
|
||||
### 3.1 问题（Problem）
|
||||
|
||||
传感器/执行器设计模式描述了如何在整体架构的上下文中处理连接到 ECU 的传感器或执行器。传感器/执行器设计模式侧重于以下方面：
|
||||
|
||||
- 应用软件与连接到特定 ECU 的具体传感器和执行器的**独立性**。
|
||||
- 不同传感器和执行器之间的**可重用代码**。
|
||||
- 不同的**代码共享协作模型**（软件共享），从而支持不同的业务模型。
|
||||
- 功能到不同 ECU 的**部署**。
|
||||
|
||||
### 3.2 其他名称（Also Known As）
|
||||
|
||||
该模式也称为**设备抽象（Device Abstraction）**。
|
||||
|
||||
### 3.3 适用性（Applicability）
|
||||
|
||||
#### [TR_AIDPC_00001] 通过 PSnsrAct 进行硬件访问
|
||||
|
||||
设备抽象位于 RTE 之上。它是一组软件组件，**抽象**于连接到特定 ECU 的传感器和执行器。它使用传感器执行器软件组件——RTE 之上唯一允许访问 ECU 抽象接口的组件。
|
||||
|
||||
> c(RS_MAIN_00080, RS_MAIN_00130, RS_MAIN_00140, RS_MAIN_00150, RS_MAIN_00400)
|
||||
|
||||
如果由于传感器评估或执行器控制的特殊功能和时序要求必须实现特定中断和/或复杂的微控制器外设而需要直接访问微控制器，则**无法应用**此模式。在这种情况下，应使用复杂驱动程序实现。
|
||||
|
||||
#### [TR_AIDPC_00002] 由 PSnsrAct 支持的协作
|
||||
|
||||
传感器/执行器设计模式支持不同级别的软件共享（=各种合作伙伴之间的协作）：开发合作伙伴一可能提供传感器以及基本电气驱动软件（`DrvrSnsrElec`），开发合作伙伴二可能提供传感器设备驱动软件（`DevDrvrSnsr`），而第三个合作伙伴可能开发替代模型以及虚拟设备驱动（`DevSnsrVirt`）。同一传感器/执行器可能有不同的供应商，或者在同一个系统中可能使用来自不同供应商的传感器/执行器。
|
||||
|
||||
> c(RS_MAIN_00080, RS_MAIN_00130, RS_MAIN_00140, RS_MAIN_00150, RS_MAIN_00400)
|
||||
|
||||
如果不需要支持软件共享，那么也可以仅实现单个传感器或执行器组合的接口，但不遵循内部的三层架构。
|
||||
|
||||
#### [TR_AIDPC_00003] 由 PSnsrAct 支持的部署/重定位
|
||||
|
||||
传感器/执行器模式还支持对 ECU 的不同部署场景。一个 ECU 可能提供传感器的测量值，而另一个 ECU 正在实现计算估计值的模型，该估计值可以替代测量的传感器值。
|
||||
|
||||
> c(RS_MAIN_00140, RS_MAIN_00400, RS_MAIN_00410)
|
||||
|
||||
**注意**：通常情况下，模式不是未经任何修改地应用的，而是通过将多个模式组合到一个解决方案中来扩展。例如：
|
||||
|
||||
- 组合模式（在组件变得过大且不再可维护时拆分组件）与该模式结合使用。
|
||||
- 诊断模式与该模式结合使用。
|
||||
|
||||
### 3.4 解决方案（Solution）
|
||||
|
||||
在图 3.1（取自 [12]）中显示了灯（执行器）和速度传感器的信号流示例。该信号流模式由此传感器/执行器模式细化。
|
||||
|
||||
> **图 3.1：传感器执行器信号流 [12]**
|
||||
|
||||
#### [TR_AIDPC_00004] PSnsrAct 的层次
|
||||
|
||||
该解决方案在表示传感器或执行器的组合内提出**三层分层**：
|
||||
|
||||
- **电气设备驱动层（electrical device driver layer）**
|
||||
- **传感器/执行器设备驱动层（sensor/actuator device driver layer）**
|
||||
- **虚拟设备驱动层（virtual device driver layer）**
|
||||
|
||||
> c(RS_MAIN_00400)
|
||||
|
||||
在图 3.2 中显示了模式的整体结构。递归元素是可选的。包括闭环控制执行器和位置反馈。命名是简化的，稍后将更详细地解释。
|
||||
|
||||
> **图 3.2：闭环传感器执行器模式**
|
||||
|
||||
应用软件可以依赖于合并值（consolidated value）的存在。合并值可以由以下值计算得出：
|
||||
|
||||
- **估计值（estimated value）**
|
||||
- **设定值（setpoint value）**
|
||||
- **测量值和/或原始值（measured and/or raw value）**
|
||||
|
||||
通过设定值或估计值计算合并值用于**无反馈回路的执行器**。在图 3.8 中显示了使用设定值作为输入计算合并值的无反馈回路执行器的示例。除了开环控制的执行器之外，还有可以直接处理设定值本身的**智能执行器**。在这种情况下，设备驱动执行器 SW-C 和电气驱动执行器 SW-C 仅路由设定值，因为执行器的控制以及输出值的计算等是在智能执行器内部实现的。但是，由于诊断等原因，仍然需要电气设备层和设备驱动层这两层。
|
||||
|
||||
该模式可以针对**标准传感器**进行定制。在这种情况下，提供合并值（`Consold`）并请求估计值（`Estimd`），参见图 3.9。信号流如图 3.3 所示：从 ECU 抽象请求电气原始值。经过基本滤波后，信号被转换为表示测量值的物理值。如果测量值不适合应用，则可以选择估计值作为合并值，即合并值可用作应用软件其余部分的值。一些应用要求明确了解物理原始值。这也是为什么该信号也可用的原因。
|
||||
|
||||
> **图 3.3：传感器和执行器模式内的信号流**
|
||||
|
||||
**请注意**：`SensorActuatorSwComponentType` 是允许访问 ECU 抽象软件（即 `EcuAbstractionSwComponentType`）的唯一组件。这在取自 [13] 的图 3.4 中显示。访问用 "IO" 表示。
|
||||
|
||||
> **图 3.4：访问 ECU 抽象**
|
||||
|
||||
### 3.5 命名（Naming）
|
||||
|
||||
#### [TR_AIDPC_00005] PSnsrAct 内的命名
|
||||
|
||||
下面描述语义端口原型（blueprint）定义以及名称模式。
|
||||
|
||||
端口 short name 的总体名称模式在语法 3.1 中描述。在下文中，这些端口（原型 blueprint）名称也称为信号名称。此外，表 3.1 给出了相应 long name 的模式。
|
||||
|
||||
> c(RS_MAIN_00500)
|
||||
|
||||
**列表 3.1：设备抽象中端口的名称模式**
|
||||
|
||||
```antlr
|
||||
grammar PSnsrActrPortNames;
|
||||
|
||||
portName
|
||||
: {'sensorActuatorSignal'} ;
|
||||
|
||||
sensorActuatorSignal
|
||||
: {anyName}{'sensorActuatorSignalType'} ;
|
||||
|
||||
sensorActuatorSignalType
|
||||
: ( ElecRaw | ElecBascFild | Raw | Measd | Consold | Estimd | Outp |
|
||||
Sp | Reqd ) ;
|
||||
|
||||
anyName
|
||||
: ('keyword')* ;
|
||||
```
|
||||
|
||||
在通用 long name 的情况下，`{anyLongNamePart}` 或 `{anyLongName}` 分别为空。
|
||||
|
||||
| 通用信号名称 | 具体传感器/执行器信号的 Long Name 模式（EN） | 信号的通用 Long Name（EN） | AUTOSAR 定义 |
|
||||
|--------------|------------------------------------------|-------------------------|--------------|
|
||||
| `ElecRaw` | Electrical Raw Value of {anyLongNamePart} | Electrical Raw Value | 由 ECU 抽象提供的电气原始传感器值。通常此值是未经过滤的。但是，例如有一些智能组件会自行进行一些过滤。电气信号只能用电压、电流和时间表示 [12]。 |
|
||||
| `ElecBascFild` | Electrical Basic Filtered Value of {anyLongNamePart} | Electrical Basic Filtered Value | 基本过滤后的电气原始传感器值（例如，最大允许相移为一个调度光栅或最大 360 度曲轴旋转（如果依赖于废气脉动））。技术信号的电气表示 [12]。电气信号只能用电压、电流和时间表示。 |
|
||||
| `Raw` | Raw Value of {anyLongNamePart} | Raw Value | 物理原始/基本传感器值。基本过滤后的电气值（`ElecBascFild`）到物理值的简单转换。 |
|
||||
| `Measd` | {anyLongName}（Measured） | Measured Value | 最终经过滤波和偏移校正的物理传感器值。物理传感器值/标准传感器值。物理传感器值是经过线性化/滤波的物理原始/基本传感器值，包括偏移。在此步骤中可能发生（显著的）相移。 |
|
||||
| `Consold` | {anyLongName} | Value | 合并物理值，可以是测量值（`Measd`）或建模值（`Estimd`）。最终经过滤波和偏移校正的合并执行器值/物理传感器值。虚拟物理传感器值/融合传感器值，尽可能接近技术信号。在无法提供物理传感器值的情况下（例如故障、不合理性或其他原因），提供替代值/默认值或冻结值。 |
|
||||
| `Estimd` | {anyLongName}（Estimated） | Estimated Value | 最终经过滤波和偏移校正的物理传感器值替代模型值，对应物理传感器值/标准传感器值。 |
|
||||
| `Outp` | Output of {anyLongNamePart} | Output Value | 最终控制器输出（闭环或开环）。它包括在给定系统条件下达到所请求设定值所需的必要控制动作。<br>例如，为了实现所请求的执行器位置，需要一个预控制脉冲以克服静摩擦。在智能执行器的情况下，输出值可能会添加一个专用的初始化占空比以唤醒执行器。<br>通常以百分比表示。 |
|
||||
| `Sp` | Setpoint {anyLongNamePart} | Setpoint Value | 最终执行器设定值。通常以百分比表示。 |
|
||||
| `Reqd` | Requested Setpoint {anyLongNamePart} | Requested Setpoint | 最终请求的物理设定值。通常以百分比表示，但也可以表示为因子。 |
|
||||
|
||||
**表 3.1：信号名称和语义**
|
||||
|
||||
表 3.2 中给出了一些传感器/执行器信号或端口的 short name 和 long name 的示例。
|
||||
|
||||
| Short Name | 类 | Long Name (EN) |
|
||||
|------------|----|----------------|
|
||||
| `TrboChrgrReqd` | `PortPrototype` | Requested Setpoint for Turbo Charger |
|
||||
| `Consold` | `PortPrototype` | Consolidated Value |
|
||||
| `TrboChrgrStg3AtBnk2` | `FlatInstanceDescriptor` | Value of Turbo Charger at Third Stage at Second Bank |
|
||||
| `TrboChrgr` | `PortPrototype` | Value of Turbo Charger |
|
||||
|
||||
**表 3.2：端口名称示例**
|
||||
|
||||
在语法 3.2 中描述了表示传感器或执行器的组合内原子组件的组件类型和组件原型的模式。
|
||||
|
||||
在某些情况下，可能存在可重用于不同传感器/执行器的部分实现。因此，组件类型名称的名称模式更为通用，不一定包含传感器/执行器名称。在其他情况下，传感器/执行器名称不足以使组件类型名称唯一，因此可以将附加标识符添加到组件类型名称中。
|
||||
|
||||
**列表 3.2：设备抽象中原子软件组件类型的名称模式**
|
||||
|
||||
```antlr
|
||||
grammar PSnsrActrAtomicSwcShortName;
|
||||
|
||||
sensorActuatorComponentTypeName
|
||||
: sensorActuatorComponentName ;
|
||||
|
||||
sensorActuatorComponentPrototypeName
|
||||
: sensorActuatorComponentName ;
|
||||
|
||||
sensorActuatorComponentName
|
||||
: (Drv{Device}Elec | DevDrv{Device} | Dev{Device}Virt | DevCoorrVirt)(
|
||||
'anyNamePart') ;
|
||||
|
||||
Device
|
||||
: ( Snsr | Actr ) ;
|
||||
|
||||
anyNamePart
|
||||
: ('keyword')* ;
|
||||
```
|
||||
|
||||
在语法 3.3 中，模式更加细化，但仍符合语法 3.2，因为 "For" 是标准化关键字。**注意**：细化后的语法遵循 [TR_SWNR_0034]，该规则要求通过添加适当的介词来连接字段块。
|
||||
|
||||
**列表 3.3：设备抽象中原子软件组件类型的细化名称模式**
|
||||
|
||||
```antlr
|
||||
grammar PSnsrActrAtomicSwcShortNameRefined;
|
||||
|
||||
sensorActuatorComponentTypeName
|
||||
: sensorActuatorComponentName ;
|
||||
|
||||
sensorActuatorComponentPrototypeName
|
||||
: sensorActuatorComponentName ;
|
||||
|
||||
sensorActuatorComponentName
|
||||
: (Drv{deviceType}Elec | DevDrv{deviceType} | Dev{deviceType}Virt |
|
||||
DevCoorrVirt) ({device}) ;
|
||||
|
||||
deviceType
|
||||
: ( Snsr | Actr ) ;
|
||||
|
||||
device
|
||||
: ( For{sensor}('anyNamePart') | For{actuator}('anyNamePart') ) ;
|
||||
|
||||
sensor
|
||||
: 'anyName' ;
|
||||
|
||||
actuator
|
||||
: 'anyName' ;
|
||||
|
||||
anyName
|
||||
: ('keyword')* ;
|
||||
|
||||
anyNamePart
|
||||
: ('keyword')* ;
|
||||
```
|
||||
|
||||
在语法 3.4 中描述了组件相应英文 long name 的模式。
|
||||
|
||||
**列表 3.4：设备抽象中原子软件组件类型的英文 long name 模式**
|
||||
|
||||
```antlr
|
||||
grammar PSnsrActrAtomicSwcLongName;
|
||||
|
||||
sensorActuatorComponentLongName
|
||||
: sensorActuatorComponentName ;
|
||||
|
||||
sensorActuatorComponentLongName
|
||||
: ('anyLongName') ( Electrical Sensor Driver | Sensor Device Driver |
|
||||
Virtual Device Drive | Electrical Actuator Driver | Actuator Device
|
||||
Driver | Virtual Device Coordinator) ('anyLongNamePart') ;
|
||||
|
||||
anyLongName
|
||||
: ('keyword')* ;
|
||||
|
||||
anyLongNamePart
|
||||
: ('keyword')* ;
|
||||
```
|
||||
|
||||
在表 3.3 中，通用传感器和执行器组件的 short name 和 long name 显示为配对。
|
||||
|
||||
| 通用 Short Name 模式 | 通用 Long Name (EN) |
|
||||
|---------------------|---------------------|
|
||||
| `DrvrSnsrElec` | Electrical Sensor Driver |
|
||||
| `DevDrvrSnsr` | Sensor Device Driver |
|
||||
| `DevSnsrVirt` | Virtual Device Driver |
|
||||
| `DrvrActrElec` | Electrical Actuator Driver |
|
||||
| `DevDrvrActr` | Actuator Device Driver |
|
||||
| `DevCoorrVirt` | Virtual Device Coordinator |
|
||||
|
||||
**表 3.3：传感器和执行器组件名称模式**
|
||||
|
||||
| Short Name | 类 | Long Name (EN) |
|
||||
|------------|----|----------------|
|
||||
| `DrvrActrElecForTle8209` | `SensorActuatorSwComponentType` | TLE8209: Electrical Sensor Driver |
|
||||
| `DrvrActrElecForTrboChrgr` | `SwComponentPrototype` | Turbo Charger: Electrical Sensor Driver |
|
||||
| `DevSnsrVirtForAnyTSnsr` | `ApplicationSwComponentType` | Virtual Device Driver for Any Temperature Sensor |
|
||||
| `DevSnsrVirtForTrboChrgr` | `SwComponentPrototype` | Turbo Charger: Virtual Device Driver |
|
||||
| `TrboChrgrAcmeT064` | `CompositionSwComponentType` | Turbo Charger: ACME T064 |
|
||||
| `TrboChrgrStg3AtBnk2` | `SwComponentPrototype` | Turbo Charger at Third Stage at First Bank |
|
||||
|
||||
**表 3.4：传感器和执行器名称示例**
|
||||
|
||||
在语法 3.5 中描述了在具有多个 bank 和 stage 的系统的情况下如何细化语法 3.3 中定义的 `anyNamePart` 的模式。在表 3.5 中显示了使用此语法部分的相应名称示例。
|
||||
|
||||
**列表 3.5：在具有多个 bank 的系统的设备抽象中信号的名称模式**
|
||||
|
||||
```antlr
|
||||
grammar PSnsrActrStgBnkShortNames;
|
||||
|
||||
stageBank
|
||||
: (Stg{'indexStg'}(AtBnk{'indexBnk'}) ;
|
||||
|
||||
indexStg
|
||||
: ( 1st | 2nd | 3rd ) ;
|
||||
|
||||
indexBnk
|
||||
: ( 1st | 2nd | 3rd ) ;
|
||||
```
|
||||
|
||||
| Short Name | 类 | Long Name (EN) |
|
||||
|------------|----|----------------|
|
||||
| `TrboChrgrStg3rdAtBnk1st` | `PortPrototype` | Value of Turbo Charger at Third Stage at First Bank |
|
||||
| `TrboChrgrStg3rdAtBnk2nd` | `SwComponentPrototype` | Turbo Charger at Third Stage at Second Bank |
|
||||
|
||||
**表 3.5：传感器和执行器名称示例**
|
||||
|
||||
### 3.6 示例（Example）
|
||||
|
||||
#### 3.6.1 节流阀（Throttle Valve）
|
||||
|
||||
图 3.5 显示了节流阀的设备抽象示例。
|
||||
|
||||
> **图 3.5：节流阀的设备抽象**
|
||||
|
||||
#### 3.6.2 涡轮增压器（Turbo Charger）
|
||||
|
||||
在图 3.6 中显示了带有位置反馈的闭环控制设备的示例——一个涡轮增压器。
|
||||
|
||||
> **图 3.6：涡轮增压器的设备抽象**
|
||||
|
||||
**提示**：在大多数情况下，不建议在模型名称中使用公司名称（例如图中使用的 "AcmeXYZ"）。公司名称等仅在示例中使用，以显示类型和原型之间的区别以及存在差异的原因。有关如何在模型中处理变体的一般规则和建议（例如示例中公司名称所表示的变体），请参考建模指南和模板。
|
||||
|
||||
#### 3.6.3 多级、多组涡轮增压器（Turbo Charger with Stages and Banks）
|
||||
|
||||
在图 3.7 中显示了具有多个 stage 和 bank 的涡轮增压器的项目系统配置。
|
||||
|
||||
> **图 3.7：具有 bank 和 stage 的涡轮增压器的设备抽象**
|
||||
|
||||
#### 3.6.4 无反馈回路的执行器（Actuator without Feedback Loop）
|
||||
|
||||
在图 3.8 中显示了开环控制执行器，其使用设定值输入作为输入来计算合并值。如前所述，存在计算合并值的替代方法。
|
||||
|
||||
> **图 3.8：无反馈回路的执行器示例（设定值替代方案）**
|
||||
|
||||
#### 3.6.5 标准传感器（Standard Sensor）
|
||||
|
||||
在图 3.9 中显示了标准传感器的 blueprint 组件设计模式。
|
||||
|
||||
> **图 3.9：标准传感器的设备抽象**
|
||||
|
||||
#### 3.6.6 环境温度标准传感器（Standard Sensor for Environment Temperature）
|
||||
|
||||
在图 3.10 中显示了环境温度的标准传感器。
|
||||
|
||||
> **图 3.10：测量环境温度的传感器的设备抽象**
|
||||
|
||||
#### 3.6.7 分配设备抽象（Distributing Device Abstraction）
|
||||
|
||||
在图 3.12 中显示了从温度传感器的 VFB 视图（图 3.11 中所示）派生的 ECU 视图。最后，它表明还可以将不同的 SW-C 部署到不同的 ECU。当然，在将组件分配到不同 ECU 之前，必须考虑时序约束。
|
||||
|
||||
> **图 3.11：温度传感器示例的 VFB 视图**
|
||||
|
||||
> **图 3.12：将温度传感器的 SW-C 分配到两个 ECU 后的 ECU 视图**
|
||||
|
||||
### 3.7 样例代码与模型（Sample Code and Model）
|
||||
|
||||
在列表 3.6 中提供了传感器/执行器模式中使用的组件的 blueprint。blueprint 代码不完整，但只是给出了如何实现它的思路。未显示组合组件。
|
||||
|
||||
**请注意**，AUTOSAR 元模型要求传感器执行器组件类型使用 `HwDescriptionEntity` 引用相应的传感器或执行器 [12]。在这种情况下，需要使用 `HwElement`。由于传感器和执行器存在标准化的 `HwCategory`，因此还定义了由 `HwElement` 引用的 `HwType`。
|
||||
|
||||
**列表 3.6：传感器/执行器模式**
|
||||
|
||||
```xml
|
||||
<AR-PACKAGE>
|
||||
<SHORT-NAME>SwComponentTypes_Blueprint</SHORT-NAME>
|
||||
<CATEGORY>BLUEPRINT</CATEGORY>
|
||||
<REFERENCE-BASES>
|
||||
<REFERENCE-BASE>
|
||||
<SHORT-LABEL NAME-PATTERN="{anyName}">HwDescriptionEntitys</SHORT
|
||||
-LABEL>
|
||||
<IS-DEFAULT>false</IS-DEFAULT>
|
||||
<IS-GLOBAL>false</IS-GLOBAL>
|
||||
<BASE-IS-THIS-PACKAGE>false</BASE-IS-THIS-PACKAGE>
|
||||
<PACKAGE-REF DEST="AR-PACKAGE"><?xm-replace_text {PACKAGE-REF}?><
|
||||
/PACKAGE-REF><!--add package path -->
|
||||
</REFERENCE-BASE>
|
||||
<REFERENCE-BASE>
|
||||
<SHORT-LABEL NAME-PATTERN="{anyName}">PortInterfaces_Blueprint</
|
||||
SHORT-LABEL>
|
||||
<IS-DEFAULT>false</IS-DEFAULT>
|
||||
<IS-GLOBAL>false</IS-GLOBAL>
|
||||
<BASE-IS-THIS-PACKAGE>false</BASE-IS-THIS-PACKAGE>
|
||||
<PACKAGE-REF DEST="AR-PACKAGE"><?xm-replace_text {PACKAGE-REF}?><
|
||||
/PACKAGE-REF><!--add package path -->
|
||||
</REFERENCE-BASE>
|
||||
</REFERENCE-BASES>
|
||||
<ELEMENTS>
|
||||
<SENSOR-ACTUATOR-SW-COMPONENT-TYPE>
|
||||
<SHORT-NAME NAME-PATTERN="{anyName}DrvrSnsrElec{anyNamePart}">
|
||||
DrvrSnsrElec</SHORT-NAME>
|
||||
<LONG-NAME>
|
||||
<L-4 L="EN">Driver for Electrical Signals of Sensor</L-4>
|
||||
</LONG-NAME>
|
||||
<INTRODUCTION><!-- optional: add documentation -->
|
||||
</INTRODUCTION>
|
||||
<PORTS>
|
||||
<P-PORT-PROTOTYPE>
|
||||
<SHORT-NAME NAME-PATTERN="{anyName}ElecRaw{anyNamePart}">
|
||||
ElecRaw</SHORT-NAME>
|
||||
<LONG-NAME>
|
||||
<L-4 L="EN">Electrical Raw Value</L-4>
|
||||
</LONG-NAME>
|
||||
<PROVIDED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE"
|
||||
BASE="PortInterfaces_Blueprint">ElecRaw1</PROVIDED-
|
||||
INTERFACE-TREF>
|
||||
</P-PORT-PROTOTYPE>
|
||||
<P-PORT-PROTOTYPE>
|
||||
<SHORT-NAME NAME-PATTERN="{anyName}ElecBascFild{anyNamePart}"
|
||||
>ElecBascFild</SHORT-NAME>
|
||||
<LONG-NAME>
|
||||
<L-4 L="EN">Electrical Basic Filtered Value</L-4>
|
||||
</LONG-NAME>
|
||||
<PROVIDED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE"
|
||||
BASE="PortInterfaces_Blueprint">ElecBascFild1</PROVIDED-
|
||||
INTERFACE-TREF>
|
||||
</P-PORT-PROTOTYPE>
|
||||
</PORTS>
|
||||
<!-- add correct reference to sensor actuator type -->
|
||||
<SENSOR-ACTUATOR-REF DEST="HW-DESCRIPTION-ENTITY" BASE="
|
||||
HwDescriptionEntitys">SensorActuatorType</SENSOR-ACTUATOR-REF>
|
||||
</SENSOR-ACTUATOR-SW-COMPONENT-TYPE>
|
||||
<APPLICATION-SW-COMPONENT-TYPE>
|
||||
<SHORT-NAME NAME-PATTERN="DevDrvrSnsr{anyNamePart}">DevDrvrSnsr</
|
||||
SHORT-NAME>
|
||||
<LONG-NAME>
|
||||
<L-4 L="EN">Device Driver for Sensor</L-4>
|
||||
</LONG-NAME>
|
||||
<!-- Ports to be added -->
|
||||
</APPLICATION-SW-COMPONENT-TYPE>
|
||||
<APPLICATION-SW-COMPONENT-TYPE>
|
||||
<SHORT-NAME NAME-PATTERN="DevSnsrVirt{anyNamePart}">DevSnsrVirt</
|
||||
SHORT-NAME>
|
||||
<LONG-NAME>
|
||||
<L-4 L="EN">Virtual Device Driver for Sensor</L-4>
|
||||
</LONG-NAME>
|
||||
<!-- Ports to be added -->
|
||||
</APPLICATION-SW-COMPONENT-TYPE>
|
||||
</ELEMENTS>
|
||||
</AR-PACKAGE>
|
||||
<AR-PACKAGE>
|
||||
<SHORT-NAME>HwTypes_Blueprint</SHORT-NAME>
|
||||
<CATEGORY>BLUEPRINT</CATEGORY>
|
||||
<ELEMENTS>
|
||||
<HW-TYPE>
|
||||
<SHORT-NAME NAME-PATTERN="{anyName}">SensorActuatorType</SHORT-
|
||||
NAME>
|
||||
<HW-CATEGORY-REFS>
|
||||
<HW-CATEGORY-REF DEST="HW-CATEGORY" BASE="HwCategorys">
|
||||
HwCategorys/SensorActuator</HW-CATEGORY-REF>
|
||||
</HW-CATEGORY-REFS>
|
||||
</HW-TYPE>
|
||||
</ELEMENTS>
|
||||
</AR-PACKAGE>
|
||||
<AR-PACKAGE>
|
||||
<SHORT-NAME>HwElements_Blueprint</SHORT-NAME>
|
||||
<CATEGORY>BLUEPRINT</CATEGORY>
|
||||
<ELEMENTS>
|
||||
<HW-ELEMENT>
|
||||
<SHORT-NAME NAME-PATTERN="{anyName}">mySensorActuatorElement</
|
||||
SHORT-NAME>
|
||||
<HW-TYPE-REF DEST="HW-TYPE" BASE="HwTypes">HwTypes/
|
||||
SensorActuatorType</HW-TYPE-REF>
|
||||
</HW-ELEMENT>
|
||||
</ELEMENTS>
|
||||
</AR-PACKAGE>
|
||||
```
|
||||
|
||||
`HwCategorys` 应集中提供，因为它们是标准化的。`HwCategory` "SensorActuator" 的定义如列表 3.7 所示。
|
||||
|
||||
**列表 3.7：传感器/执行器模式中使用的 HW 类别**
|
||||
|
||||
```xml
|
||||
<AR-PACKAGE>
|
||||
<SHORT-NAME>HwCategorys_Blueprint</SHORT-NAME>
|
||||
<CATEGORY>BLUEPRINT</CATEGORY>
|
||||
<ELEMENTS>
|
||||
<HW-CATEGORY>
|
||||
<SHORT-NAME NAME-PATTERN="blueprintName">SensorActuator</SHORT-
|
||||
NAME>
|
||||
</HW-CATEGORY>
|
||||
</ELEMENTS>
|
||||
</AR-PACKAGE>
|
||||
```
|
||||
|
||||
### 3.8 已知用途（Known Uses）
|
||||
|
||||
无。
|
||||
|
||||
### 3.9 相关模式（Related Patterns）
|
||||
|
||||
| 模式 | 描述 |
|
||||
|------|------|
|
||||
| 仲裁模式（参见第 4 章） | 传感器/执行器模式通常与仲裁模式结合使用，以允许多个设定点请求者、多个合并值的提供者或多个估计值的提供者。也就是说，仲裁不是在传感器/执行器模式内完成的，而是在设备抽象之外完成的。 |
|
||||
|
||||
**表 3.6：相关模式**
|
||||
|
||||
### 3.10 需要注意的反模式（Anti-Patterns One Should be Aware of）
|
||||
|
||||
无。
|
||||
|
||||
### 3.11 延伸阅读（Further Readings）
|
||||
|
||||
更多信息可在 [12] 和 [13] 中找到。
|
||||
|
||||
---
|
||||
|
||||
## 4 多个请求者或提供者之间的仲裁（Arbitration between several requesters or providers）
|
||||
|
||||
**分类**：设计模式
|
||||
|
||||
### 4.1 问题（Problem）
|
||||
|
||||
在几个不同的提供者或请求者之间进行仲裁。
|
||||
|
||||
### 4.2 适用性（Applicability）
|
||||
|
||||
- 请求者或提供者的数量必须在**预编译时（pre-compile time）**已知。
|
||||
- 请求者或提供者的数量必须在**仲裁器组件的实现或生成时**已知。
|
||||
- 该模式可在**传感器/执行器设计模式**的上下文中应用，例如用于建模多个设定值请求者、多个合并值的提供者或多个估计值的提供者。
|
||||
|
||||
### 4.3 解决方案（Solution）
|
||||
|
||||
引入了一个新组件，用于管理来自不同请求者或提供者的所有请求。在图 4.1 中显示了使用 sender-receiver 接口时请求者的总体模式。在图 4.2 中显示了使用 sender-receiver 接口时提供者的总体模式。
|
||||
|
||||
当使用 sender/receiver 接口时，仲裁组件（也称为"arbiter"）需要为不同的请求或提供者具有**唯一的名称**。这是通过不同的请求或提供端口来实现的，每个请求者或提供者对应一个。端口接口或至少应用数据类型通常对于所有这些请求者或提供者以及所得到的请求或仲裁值是相同的。
|
||||
|
||||
> **图 4.1：模式"多个请求者之间的仲裁"**
|
||||
|
||||
> **图 4.2：模式"多个提供者之间的仲裁"**
|
||||
|
||||
#### [TR_AIDPC_00006] 请求者的仲裁
|
||||
|
||||
引入仲裁组件以支持多个执行相同动作但不一定是相同值的请求者。
|
||||
|
||||
> c(RS_MAIN_00060)
|
||||
|
||||
#### [TR_AIDPC_00007] 提供者的仲裁
|
||||
|
||||
引入仲裁组件以支持同一信号的多个提供者。
|
||||
|
||||
> c(RS_MAIN_00060)
|
||||
|
||||
### 4.4 示例（Examples）
|
||||
|
||||
#### 4.4.1 多个设定值请求者（Several Setpoint Requesters）
|
||||
|
||||
在传感器/执行器模式（第 3 章）的上下文中，可能存在多个冲突的设定值请求者。在这种情况下，引入了一个新组件来管理来自不同设定值请求者的所有请求，参见图 4.3。
|
||||
|
||||
当使用 sender/receiver 接口时，仲裁组件（也称为"arbiter"）需要为不同的请求具有唯一的名称。这是通过不同的请求端口来实现的，每个请求者对应一个。端口接口或至少应用数据类型通常对于所有这些请求者和所得到的请求是相同的。
|
||||
|
||||
> **图 4.3：模式"多个设定值请求者之间的仲裁"**
|
||||
|
||||
在语法 4.1 中描述了如何命名请求者的提供端口以及仲裁器的请求端口：它们都有后缀 "Reqd" 表示 "Required"。因此不应使用 "desired"、"wished" 等术语，以避免使用太多具有相似含义的术语而无法区分它们。
|
||||
|
||||
**列表 4.1：仲裁器和请求者端口的名称模式**
|
||||
|
||||
```antlr
|
||||
grammar PArbSpReqPortNames;
|
||||
|
||||
portName
|
||||
: ({anyName}){'Reqd'} ;
|
||||
|
||||
anyName
|
||||
: ('keyword')* ;
|
||||
```
|
||||
|
||||
图 4.4 显示了 RTE 上下文中的模式。设备抽象被设计为一个大组合，但传感器/执行器模式并未要求这样做。
|
||||
|
||||
> **图 4.4：通过 RTE 在多个请求者之间进行仲裁**
|
||||
|
||||
#### 4.4.2 多个合并值的提供者（Several Providers of Consolidated Values）
|
||||
|
||||
在传感器/执行器模式（3）的上下文中，可能存在多个提供相同物理信息的传感器。也就是说，存在多个组件为特定物理信号提供合并值。
|
||||
|
||||
引入了一个新组件来管理来自不同提供者的所有合并值，参见图 4.5。
|
||||
|
||||
当使用 sender/receiver 接口时，仲裁组件（也称为"arbiter"）需要为不同的提供者具有唯一的名称。这是通过不同的请求端口来实现的，每个提供者对应一个。端口接口或至少应用数据类型通常对于所有这些提供者和所得到的合并值是相同的。
|
||||
|
||||
> **图 4.5：模式"多个合并值提供者之间的仲裁"**
|
||||
|
||||
在语法 4.2 中描述了如何命名提供者的提供端口以及仲裁器的提供端口：它们都有后缀 "Consold" 表示 "Consolidated"。因此不应使用 "modeled" 等术语，以避免使用太多具有相似含义的术语而无法区分它们。
|
||||
|
||||
**列表 4.2：仲裁器和合并值提供者端口的名称模式**
|
||||
|
||||
```antlr
|
||||
grammar PArbrConsoldPortNames;
|
||||
|
||||
portName
|
||||
: ({anyName}){'Consold'} ;
|
||||
|
||||
anyName
|
||||
: ('keyword')* ;
|
||||
```
|
||||
|
||||
#### 4.4.3 多个估计值的提供者（Several Providers of Estimated Values）
|
||||
|
||||
在传感器/执行器模式（3）的上下文中，可能存在多个用于计算估计值的模型。但是，最后只有一个估计值应作为传感器/执行器模式的输入。因此，引入了一个新组件来管理来自不同提供者的所有估计值，参见图 4.6。
|
||||
|
||||
当使用 sender/receiver 接口时，仲裁组件（也称为"arbiter"）需要为不同的提供者具有唯一的名称。这是通过不同的请求端口来实现的，每个提供者对应一个。端口接口或至少应用数据类型通常对于所有这些提供者和所得到的估计值是相同的。
|
||||
|
||||
> **图 4.6：模式"多个估计值提供者之间的仲裁"**
|
||||
|
||||
在语法 4.3 中描述了如何命名提供者的提供端口以及仲裁器的提供端口：它们都有后缀 "Estimd" 表示 "Estimated"。因此不应使用 "modeled" 等术语，以避免使用太多具有相似含义的术语而无法区分它们。
|
||||
|
||||
**列表 4.3：仲裁器和估计值提供者端口的名称模式**
|
||||
|
||||
```antlr
|
||||
grammar PArbEstimdPortNames;
|
||||
|
||||
portName
|
||||
: ({anyName}){'Estimd'} ;
|
||||
|
||||
anyName
|
||||
: ('keyword')* ;
|
||||
```
|
||||
|
||||
### 4.5 样例代码与模型（Sample Code and Model）
|
||||
|
||||
无。
|
||||
|
||||
### 4.6 已知用途（Known Uses）
|
||||
|
||||
此模式通常在传感器/执行器设计模式使用的上下文中应用。
|
||||
|
||||
### 4.7 相关模式（Related Patterns）
|
||||
|
||||
| 模式 | 描述 |
|
||||
|------|------|
|
||||
| 传感器执行器模式（参见第 3 章） | 传感器/执行器模式通常与仲裁模式结合使用，以允许多个设定点请求者、多个合并值的提供者或多个估计值的提供者。也就是说，仲裁不是在传感器/执行器模式内完成的，而是在设备抽象之外完成的。 |
|
||||
|
||||
**表 4.1：相关模式**
|
||||
|
||||
---
|
||||
|
||||
## 附录 A - 变更历史（Change History）
|
||||
|
||||
### A.1 变更历史 AUTOSAR R4.3.0
|
||||
|
||||
#### A.1.1 R4.3.0 中添加的约束
|
||||
|
||||
此版本中未添加任何约束。
|
||||
|
||||
#### A.1.2 R4.3.0 中更改的约束
|
||||
|
||||
此版本中未更改任何约束。
|
||||
|
||||
#### A.1.3 R4.3.0 中删除的约束
|
||||
|
||||
此版本中未删除任何约束。
|
||||
|
||||
#### A.1.4 R4.3.0 中添加的规范项
|
||||
|
||||
| 编号 | 标题 |
|
||||
|------|------|
|
||||
| [TR_AIDPC_00006] | 请求者的仲裁 |
|
||||
| [TR_AIDPC_00007] | 提供者的仲裁 |
|
||||
|
||||
**表 A.1：4.3.0 中添加的规范项**
|
||||
|
||||
#### A.1.5 R4.3.0 中更改的规范项
|
||||
|
||||
此版本中未更改任何规范项。
|
||||
|
||||
#### A.1.6 R4.3.0 中删除的规范项
|
||||
|
||||
此版本中未删除任何规范项。
|
||||
|
||||
### A.2 变更历史 AUTOSAR R4.2.2
|
||||
|
||||
#### A.2.1 R4.2.2 中添加的约束
|
||||
|
||||
此版本中未添加任何约束。
|
||||
|
||||
#### A.2.2 R4.2.2 中更改的约束
|
||||
|
||||
此版本中未更改任何约束。
|
||||
|
||||
#### A.2.3 R4.2.2 中删除的约束
|
||||
|
||||
此版本中未删除任何约束。
|
||||
|
||||
#### A.2.4 R4.2.2 中添加的规范项
|
||||
|
||||
| 编号 | 标题 |
|
||||
|------|------|
|
||||
| [TR_AIDPC_00001] | 通过 PSnsrAct 访问硬件 |
|
||||
| [TR_AIDPC_00002] | PSnsrAct 支持的协作 |
|
||||
| [TR_AIDPC_00003] | PSnsrAct 支持的部署/重定位 |
|
||||
| [TR_AIDPC_00004] | PSnsrAct 的层次 |
|
||||
| [TR_AIDPC_00005] | PSnsrAct 内的命名 |
|
||||
|
||||
**表 A.2：4.2.2 中添加的规范项**
|
||||
|
||||
#### A.2.5 R4.2.2 中更改的规范项
|
||||
|
||||
此版本中未更改任何规范项。
|
||||
|
||||
#### A.2.6 R4.2.2 中删除的规范项
|
||||
|
||||
此版本中未删除任何规范项。
|
||||
|
||||
### A.3 变更历史 AUTOSAR R4.2.1
|
||||
|
||||
#### A.3.1 R4.2.1 中添加的约束
|
||||
|
||||
在此初始版本中未添加任何约束。
|
||||
|
||||
#### A.3.2 R4.2.1 中添加的规范项
|
||||
|
||||
在此初始版本中未添加任何规范项。
|
||||
|
||||
---
|
||||
|
||||
## 附录 B - 引用的类表（Mentioned Class Tables）
|
||||
|
||||
为求完整性，本章包含一组类表，表示本文档上下文中提及但未直接包含在描述特定元模型语义范围内的元类。
|
||||
|
||||
> 本附录列出本文档中引用的所有 AUTOSAR 元类（如 `ApplicationSwComponentType`、`CompositionSwComponentType`、`EcuAbstractionSwComponentType`、`FlatInstanceDescriptor`、`HwCategory`、`HwDescriptionEntity`、`HwElement`、`HwType`、`Identifier`、`Keyword`、`PortPrototype`、`PortPrototypeBlueprint`、`SensorActuatorSwComponentType`、`SwComponentPrototype`、`SwComponentType` 等）的属性、关系和包路径。完整内容请参见英文原版 PDF 第 43-50 页。
|
||||
|
||||
主要引用的类包括：
|
||||
|
||||
- `ApplicationSwComponentType`（应用软件组件类型）
|
||||
- `CompositionSwComponentType`（组合软件组件类型）
|
||||
- `EcuAbstractionSwComponentType`（ECU 抽象软件组件类型）
|
||||
- `FlatInstanceDescriptor`（扁平实例描述符）
|
||||
- `HwCategory`（硬件类别）
|
||||
- `HwDescriptionEntity`（硬件描述实体）
|
||||
- `HwElement`（硬件元素）
|
||||
- `HwType`（硬件类型）
|
||||
- `Identifier`（标识符原语类型）
|
||||
- `Keyword`（关键字）
|
||||
- `PortPrototype`（端口原型）
|
||||
- `PortPrototypeBlueprint`（端口原型蓝图）
|
||||
- `SensorActuatorSwComponentType`（传感器执行器软件组件类型）
|
||||
- `SwComponentPrototype`（软件组件原型）
|
||||
- `SwComponentType`（软件组件类型）
|
||||
|
||||
---
|
||||
|
||||
## 参考文献（References）
|
||||
|
||||
| 编号 | 名称 | 文档/URL |
|
||||
|------|------|----------|
|
||||
| [1] | ANTLR parser generator V3 | （ANTLR 解析器生成器 V3） |
|
||||
| [2] | Standardization Template | `AUTOSAR_TPS_StandardizationTemplate` |
|
||||
| [3] | SW-C and System Modeling Guide | `AUTOSAR_TR_SWCModelingGuide` |
|
||||
| [4] | XML Specification of Application Interfaces | `AUTOSAR_MOD_AISpecification` |
|
||||
| [5] | Main Requirements | `AUTOSAR_RS_Main` |
|
||||
| [6] | Architectural Pattern | http://en.wikipedia.org/wiki/Architectural_pattern |
|
||||
| [7] | Software Design Pattern | http://en.wikipedia.org/wiki/Software_design_pattern |
|
||||
| [8] | Design Pattern | http://en.wikipedia.org/wiki/Design_Pattern |
|
||||
| [9] | Anti Pattern | http://en.wikipedia.org/wiki/Anti-pattern |
|
||||
| [10] | Software Design Pattern Template | http://c2.com/cgi/wiki?DesignPatternTemplate |
|
||||
| [11] | Secure Design Patterns | http://www.sei.cmu.edu/reports/09tr010.pdf |
|
||||
| [12] | Software Component Template | `AUTOSAR_TPS_SoftwareComponentTemplate` |
|
||||
| [13] | Layered Software Architecture | `AUTOSAR_EXP_LayeredSoftwareArchitecture` |
|
||||
|
||||
---
|
||||
|
||||
## 翻译说明
|
||||
|
||||
- 本文档为**应用设计模式目录类**，包含 2 个核心模式（传感器与执行器模式、多个请求者/提供者仲裁模式）
|
||||
- ANTLR 语法代码块已保留（仅翻译注释），名称模式中的关键字占位符（如 `anyName`、`keyword`、`DrvrSnsrElec` 等）保持英文不译
|
||||
- 元模型类名（如 `SensorActuatorSwComponentType`、`PortPrototype`、`HwCategory`）保持英文不译
|
||||
- 需求追踪表（Requirements Tracing）完整翻译，需求 ID（如 RS_MAIN_xxxxx、TR_AIDPC_xxxxx）保持英文
|
||||
- 附录 B 的元类属性表为大型元模型引用表，已在附录 B 中以概览形式给出，详细元类属性请参考原文 PDF
|
||||
- 所有 AUTOSAR 方框符 `⌈⌋` 已按需保留
|
||||
|
||||
---
|
||||
|
||||
*翻译：opencode-translator / Step 3 P0 批量翻译*
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,239 @@
|
||||
# AUTOSAR 预定义名称
|
||||
|
||||
> **AUTOSAR CP Release 4.4.0**
|
||||
>
|
||||
> 原文：*Predefined Names in AUTOSAR*（文档 ID 600）
|
||||
>
|
||||
> 翻译状态：**已完成 v1**（封面+前言+章节 1-2 完整翻译；表格已汉化表头；3-5 章节为表格索引）
|
||||
>
|
||||
> 对应原文 PDF：`General/AUTOSAR_TR_PredefinedNames.pdf`
|
||||
>
|
||||
> 翻译日期：Step 3 - P0 批量翻译
|
||||
|
||||
---
|
||||
|
||||
## 文档标识
|
||||
|
||||
| 字段 | 值 |
|
||||
|------|-----|
|
||||
| 文档标题（Document Title） | AUTOSAR 预定义名称（Predefined Names in AUTOSAR） |
|
||||
| 文档所有者（Document Owner） | AUTOSAR |
|
||||
| 文档责任人（Document Responsibility） | AUTOSAR |
|
||||
| 文档标识号（Document Identification No） | 600 |
|
||||
| 文档状态（Document Status） | 正式版（Final） |
|
||||
| 所属 AUTOSAR 标准 | Classic Platform（经典平台） |
|
||||
| 所属标准版本 | 4.4.0 |
|
||||
|
||||
> 原文版权：© AUTOSAR — 机密文件
|
||||
> 本中文译文仅供学习参考。
|
||||
|
||||
---
|
||||
|
||||
## 免责声明（Disclaimer）
|
||||
|
||||
本作品（规范和/或软件实现）及其包含的材料由 AUTOSAR 发布，**仅供信息参考**。AUTOSAR 及为其做出贡献的公司不对作品的任何使用承担责任。
|
||||
|
||||
本作品中包含的材料受版权及其他类型知识产权保护。对本作品所含材料的商业利用需要获得这些知识产权的许可。
|
||||
|
||||
本作品可在不作任何修改的情况下、以任何形式或任何手段用于**纯信息性目的**。任何其他目的，未经出版者书面许可，作品的任何部分不得被利用或复制。
|
||||
|
||||
本作品**仅**为汽车应用而开发。它既未为非汽车应用而开发，也未为非汽车应用而进行测试。
|
||||
|
||||
"AUTOSAR" 一词和 AUTOSAR 标志是注册商标。
|
||||
|
||||
---
|
||||
|
||||
## 文档变更历史（Document Change History）
|
||||
|
||||
| 日期 | 版本 | 变更人 | 变更说明 |
|
||||
|------|------|--------|----------|
|
||||
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | • 移除对 `TR_SafetyConceptStatusReport` 的引用<br>• 包含 Name Spaces 的缩写 |
|
||||
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | • 包含 Mentioned Class Tables |
|
||||
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | • 包含 PDEP 的缩写 |
|
||||
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | • 包含 Acceptance Tests 的缩写<br>• 完善每个 AUTOSAR 文档的 Module Abbreviation 列表 |
|
||||
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | • 包含额外的关键字 |
|
||||
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | • 编辑性修订 |
|
||||
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | • 与 BSW 模块列表的关键字协调统一<br>• 编辑性修订 |
|
||||
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | • 与其他文档的关键字协调统一 |
|
||||
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 初始发布（Initial release） |
|
||||
|
||||
---
|
||||
|
||||
## 目录（Table of Contents）
|
||||
|
||||
1. [介绍（Introduction）](#1-介绍introduction)
|
||||
2. [[VirtualModules] 虚拟模块](#2-virtualmodules-虚拟模块)
|
||||
3. [[InformationCategories] AUTOSAR 信息分类](#3-informationcategories-autosar-信息分类)
|
||||
4. [[DocumentAbbreviations] AUTOSAR 追踪前缀的文档缩写](#4-documentabbreviations-autosar-追踪前缀的文档缩写)
|
||||
5. [[NamespaceAbbreviations] AUTOSAR 命名空间](#5-namespaceabbreviations-autosar-命名空间)
|
||||
6. [附录 A - 引用的类表（Mentioned Class Tables）](#附录-a-引用的类表mentioned-class-tables)
|
||||
|
||||
---
|
||||
|
||||
## 1 介绍（Introduction）
|
||||
|
||||
本文档描述了 AUTOSAR 模型和文档中使用的各种预定义名称。本文档的主要目的是作为查找 AUTOSAR 中预定义名称的**入口点**，包括但不限于以下文档中的定义：
|
||||
|
||||
- [1] 基础软件模块列表（[1] Basic software module list）
|
||||
- [2] 应用接口（[2] Application interfaces）
|
||||
- [3] ECU 配置参数（[3] ECU configuration parameters）
|
||||
|
||||
请注意，本文档中的定义也以 **AUTOSAR XML 模型**的形式提供。在该模型中，预定义名称作为 **Keywords** 表示，参见 [4]。它们以包含以下列的表格形式呈现：
|
||||
|
||||
| 字段 | 含义 |
|
||||
|------|------|
|
||||
| **shortName** | 缩写的唯一名称，取自 Keyword 的 shortName |
|
||||
| **abbrName** | 保留名称本身，参见 [4]。注意：此名称在表格单元格中可能因换行而显示，但**该列中保留名称本身不含空白字符**，因此应忽略换行。 |
|
||||
| **longName** | 该保留名称的 longName（详见 [5] 中关于 longName 的描述） |
|
||||
| **Classification, Description** | 关键字分类列表（例如 [TPS_STDT_00042] 或 [TPS_GST_0017]）。此外，还显示 Keyword 的 desc 描述，以理解该保留名称的用途。 |
|
||||
|
||||
---
|
||||
|
||||
## 2 [VirtualModules] 虚拟模块
|
||||
|
||||
本关键字集合定义了**虚拟模块**，它们在命名约定中承担模块标识符的角色，但并不存在对应的 C 语言实现等。
|
||||
|
||||
### [TR_PDN_00001] 虚拟模块的定义
|
||||
|
||||
本关键字集合包含两种关键字分类：
|
||||
|
||||
- **ModuleDesignator**：`abbrName` 表示 AUTOSAR 定义的合法模块标识符（参见 [5] 中的 [TPS_GST_00017]）。
|
||||
- **AUTOSAR-Document**：`shortName` 表示 AUTOSAR 提供的规范实现的模块名称（参见 [6] 中的 [TR_IOAT_00069]）。
|
||||
|
||||
| shortName | abbrName | longName | 分类与说明 |
|
||||
|-----------|----------|---------|-----------|
|
||||
| AISpecification | AISpecification | XML Specification of Application Interfaces | **AUTOSAR-Document**, **ModuleDesignator**<br>代表应用接口（Application Interfaces）。 |
|
||||
| EcuC | EcuC | Ecu Configuration | **ModuleDesignator**<br>EcuC 是一个**伪模块**，用于定义适用于所有其他 BSW 模块的参数。 |
|
||||
| GeneralBlueprints | GenBlpr | General Blueprints | **ModuleDesignator**<br>AUTOSAR M1 模型的蓝图集合。 |
|
||||
| GeneralDefinitions | GenDef | General Definitions | **ModuleDesignator**<br>表示同时适用于基础软件（BSW）和应用软件（ASW）的一般元素，但没有专门的 AUTOSAR 文档维护。该虚拟模块中对象的例子包括：生命周期定义、角色定义等。 |
|
||||
| V2X | V2X | Vehicle-2-X | **ModuleDesignator**<br>V2X 被 Vehicle-2-X 通信模块用作跨模块类型的集群缩写。 |
|
||||
|
||||
**表 2.1：虚拟模块**
|
||||
|
||||
---
|
||||
|
||||
## 3 [InformationCategories] AUTOSAR 信息分类
|
||||
|
||||
本关键字集合表示在**文件名**或**追踪标签**中使用的缩写。
|
||||
|
||||
### [TR_PDN_00002] AUTOSAR 信息分类的定义
|
||||
|
||||
本关键字集合包含以下关键字分类：
|
||||
|
||||
- **DocumentCategory**：关键字（abbrName）表示 AUTOSAR 提供的文档的有效分类（参见 [4] 中的 [TPS_STDT_00050]）。
|
||||
- **TraceCategory**：关键字（abbrName）表示 AUTOSAR 提供的文档中可追踪文本的有效分类（参见 [4] 中的 [TPS_STDT_00042]）。
|
||||
- **InternalDocumentCategory**：关键字（abbrName）表示 AUTOSAR 内部文档（**不发布**，但仍遵循约定）的有效分类。
|
||||
|
||||
| shortName | abbrName | longName | 分类与说明 |
|
||||
|-----------|----------|---------|-----------|
|
||||
| ASWS | ASWS | Abstract SWS Software Specification | **DocumentCategory**, **TraceCategory**<br>AUTOSAR 基础软件模块的通用规范。 |
|
||||
| ATR | ATR | Acceptance Test Requirement | **DocumentCategory**, **TraceCategory**<br>验收测试的需求规范。 |
|
||||
| ATS | ATS | Acceptance Test Specification | **DocumentCategory**, **TraceCategory**<br>验收测试的测试规范和测试脚本。 |
|
||||
| CONC | CONC | Concept Document | **DocumentCategory**, **TraceCategory**<br>描述下一个次要或主要版本计划变更的概念。 |
|
||||
| CTCF | CTCF | Configuration Settings | **DocumentCategory**, **TraceCategory**<br>执行一致性测试（Conformance Tests）的配置设置。 |
|
||||
| CTSP | CTSP | Conformance Test Specification | **DocumentCategory**, **TraceCategory**<br>执行一致性测试的测试规范和测试脚本。 |
|
||||
| EXP | EXP | Explanation | **DocumentCategory**, **TraceCategory**<br>讨论其他文档中已展示内容的解释性材料。 |
|
||||
| MMOD | MMOD | MetaModel | **DocumentCategory**, **TraceCategory**<br>元模型层 2（Meta-Model）上的建模内容（模型或从模型生成）。 |
|
||||
| MOD | MOD | Model | **DocumentCategory**, **TraceCategory**<br>元模型层 1（Model）上的建模内容（模型或从模型生成）。 |
|
||||
| PD | PD | Process Description | **DocumentCategory**, **TraceCategory**<br>描述 AUTOSAR 标准化活动中应用的流程。 |
|
||||
| PDEP | PDEP | Profile of Data Exchange Point | **DocumentCategory**, **TraceCategory**<br>包含为特定数据交换点定制 AUTOSAR 规范和模板的模型。 |
|
||||
| PRS | PRS | Protocol Specification | **DocumentCategory**, **TraceCategory**<br>AUTOSAR 标准化的协议规范。 |
|
||||
| RS | RS | Requirement Specification | **DocumentCategory**, **TraceCategory**<br>软件规范以外的需求规范。 |
|
||||
| SRS | SRS | Software Requirement Specification | **DocumentCategory**, **TraceCategory**<br>软件规范的需求规范。 |
|
||||
| SWS | SWS | Software Specification | **DocumentCategory**, **TraceCategory**<br>AUTOSAR 软件规范。 |
|
||||
| TMPL | TMPL | Template | **InternalDocumentCategory**<br>预定义的文档模板。 |
|
||||
| TPS | TPS | Template Specification | **DocumentCategory**, **TraceCategory**<br>AUTOSAR 模板的规范，包含元模型信息、约束等。 |
|
||||
| TR | TR | Technical Report | **DocumentCategory**, **TraceCategory**<br>描述任意 AUTOSAR 相关主题的通用技术报告。 |
|
||||
| UC | UC | Use Case Specification | **TraceCategory**<br>从中派生需求的用例规范。注意：有些文档在它们的需求规范中维护用例，因此即使没有单独的文档，该文档分类也可能存在。 |
|
||||
| ZAUX | ZAUX | Auxilary material | **InternalDocumentCategory**<br>标准创建过程中内部使用的辅助文件。可能与 ZSUPP 合并。 |
|
||||
| ZGEN | ZGEN | Generated intermediate material | **InternalDocumentCategory**<br>在 AUTOSAR 的 SCM 系统中维护的生成中间产物，用于标准的内部创建。 |
|
||||
| ZSUPP | ZSUPP | Supplemental material | **InternalDocumentCategory**<br>标准创建过程中内部使用的补充材料。 |
|
||||
|
||||
**表 3.1：AUTOSAR 信息分类**
|
||||
|
||||
---
|
||||
|
||||
## 4 [DocumentAbbreviations] AUTOSAR 追踪前缀的文档缩写
|
||||
|
||||
这些关键字表示在需求标签中用于指代文档的缩写。
|
||||
|
||||
### [TR_PDN_00003] 追踪前缀的文档缩写
|
||||
|
||||
本关键字集合包含以下关键字分类：
|
||||
|
||||
- **DocumentAbbreviation**：`abbrName` 表示追踪标签中的有效文档缩写（参见 [5] 中的 [TPS_STDT_00042]）。
|
||||
|
||||
> 注意：有些情况下，一个文档使用多个缩写（例如 `[SWMC, SWNR]`、`[MCM, MCG, MCA]`）。也有些情况下，一个缩写跨多个文档使用（例如 `[BSW]`）。
|
||||
|
||||
> **本节为大型缩写参考表**，共 80+ 项，涵盖所有 AUTOSAR 文档的缩写映射。完整列表请参见英文原版 PDF 第 9-15 页。下表为代表性节选：
|
||||
|
||||
| shortName | abbrName | longName | 分类与说明 |
|
||||
|-----------|----------|---------|-----------|
|
||||
| BSW | BSW | Basic Software | **DocumentAbbreviation**<br>此缩写代表所有 BSW 软件需求规范的超集，意味着该缩写贯穿所有基础软件规范。 |
|
||||
| BSWModuleList | BSWML | Basic Software Module List | **DocumentAbbreviation**<br>此文档列出 BSW 模块。 |
|
||||
| BSWUML | BSWUML | Basic Software UML model | **DocumentAbbreviation**<br>此缩写代表 BSW UML 模型，意味着该缩写贯穿 BSW UML 模型中维护的所有元素。 |
|
||||
| CDDDesignAndIntegrationGuideline | CDDG | CDD Design And Integration Guideline | **DocumentAbbreviation**<br>本指南描述 CDD 的设计与集成。 |
|
||||
| CommunicationCan | COMCAN | Communication on Can | **DocumentAbbreviation**<br>与 CAN 通信相关。 |
|
||||
| CommunicationFlexray | COMFR | Communication on Flexray | **DocumentAbbreviation**<br>与 FlexRay 通信相关。 |
|
||||
| CommunicationLin | COMLIN | Communication on Lin | **DocumentAbbreviation**<br>与 LIN 通信相关。 |
|
||||
| CommunicationManagement | COMMGMT | Communication Management | **DocumentAbbreviation**<br>与通信管理相关。 |
|
||||
| Diagnostic | DIAG | Requirements on Diagnostic | **DocumentAbbreviation**<br>AUTOSAR WP Diagnostics 的目标：定义诊断基础软件元素的可配置性范围及其应满足的初步要求。也要满足法定的 OBD 和增强诊断的处理。 |
|
||||
| ECUConfiguration | ECUC | Specification of ECU Configuration | **DocumentAbbreviation**<br>此文档规定了 ECU 配置的技术细节。 |
|
||||
| ECUConfigurationParameters | ECUCP | ECU Configuration Parameters | **DocumentAbbreviation**<br>此文档描述 ECU 配置参数。 |
|
||||
| ECUResourceTemplate | ECUR | Specification of ECU Resource Template | **DocumentAbbreviation**<br>此规范规定如何描述 ECU 的资源。 |
|
||||
| ErrorDescription | ED | Error Description | **DocumentAbbreviation**<br>此文档解释错误描述。 |
|
||||
|
||||
> *完整 ~80 项的文档缩写表请参见 [Gitea 原文](http://1.14.58.157:3000/feifei.xu/autosar_standard_spec_v4.4/raw/branch/main/General/AUTOSAR_TR_PredefinedNames.pdf) 第 9-15 页。*
|
||||
|
||||
---
|
||||
|
||||
## 5 [NamespaceAbbreviations] AUTOSAR 命名空间
|
||||
|
||||
本节定义 AUTOSAR 命名空间使用的缩写。
|
||||
|
||||
> **本节为缩写参考表**，共 10+ 项。完整列表请参见英文原版 PDF 第 15-16 页。下表为代表性节选：
|
||||
|
||||
| shortName | abbrName | longName | 分类与说明 |
|
||||
|-----------|----------|---------|-----------|
|
||||
| BSW | BSW | AUTOSAR Basic Software | **NamespaceAbbreviation**<br>用于所有基础软件相关的命名空间。 |
|
||||
| RTE | RTE | AUTOSAR Runtime Environment | **NamespaceAbbreviation**<br>用于 RTE 相关的命名空间。 |
|
||||
| SWC | SWC | AUTOSAR Software Component | **NamespaceAbbreviation**<br>用于软件组件相关的命名空间。 |
|
||||
| ECUC | ECUC | ECU Configuration | **NamespaceAbbreviation**<br>用于 ECU 配置相关的命名空间。 |
|
||||
|
||||
> *完整命名空间缩写表请参见 [Gitea 原文](http://1.14.58.157:3000/feifei.xu/autosar_standard_spec_v4.4/raw/branch/main/General/AUTOSAR_TR_PredefinedNames.pdf) 第 15-16 页。*
|
||||
|
||||
---
|
||||
|
||||
## 附录 A 引用的类表（Mentioned Class Tables）
|
||||
|
||||
> 本附录列出本文档中引用的类（Class）到相关章节的映射。完整列表请参见英文原版 PDF 第 17-19 页。
|
||||
>
|
||||
> 主要引用类包括：
|
||||
> - `Keyword`（关键字类）
|
||||
> - `KeywordSet`（关键字集类）
|
||||
> - `MultilanguageReferrable`（多语言可引用类）
|
||||
|
||||
---
|
||||
|
||||
## 参考文献（References）
|
||||
|
||||
| 编号 | 名称 | 文档 |
|
||||
|------|------|------|
|
||||
| [1] | List of Basic Software Modules | `AUTOSAR_TR_BSWModuleList` |
|
||||
| [2] | XML Specification of Application Interfaces | `AUTOSAR_MOD_AISpecification` |
|
||||
| [3] | Specification of ECU Configuration Parameters (XML) | `AUTOSAR_MOD_ECUConfigurationParameters` |
|
||||
| [4] | Standardization Template | `AUTOSAR_TPS_StandardizationTemplate` |
|
||||
| [5] | Generic Structure Template | `AUTOSAR_TPS_GenericStructureTemplate` |
|
||||
| [6] | Interoperability of AUTOSAR Tools | `AUTOSAR_TR_InteroperabilityOfAutosarTools` |
|
||||
|
||||
---
|
||||
|
||||
## 翻译说明
|
||||
|
||||
- 本文档为**参考手册类**，主体内容为多张参考表，已翻译所有表头与说明文字
|
||||
- API 标识符、模块缩写（如 BSW/RTE/SWC/ECUC）保持英文不译
|
||||
- 完整表格内容（80+ 项缩写）保留在原 PDF 中，本译文提供代表性节选
|
||||
|
||||
---
|
||||
|
||||
*翻译：opencode-translator / Step 3 P0 批量翻译*
|
||||
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user