1811 lines
88 KiB
Markdown
1811 lines
88 KiB
Markdown
# AUTOSAR 软件组件与系统建模指南
|
||
|
||
> **AUTOSAR CP Release 4.4.0**
|
||
>
|
||
> 原文：*SW-C and System Modeling Guide*（文档 ID 207）
|
||
>
|
||
> 翻译状态：**已完成 v1**（封面+前言+目录+章节 1-6 完整翻译；XML 示例已翻译注释并保留代码结构）
|
||
>
|
||
> 对应原文 PDF：`General/AUTOSAR_TR_SWCModelingGuide.pdf`
|
||
>
|
||
> 翻译日期：Step 3 - P0 批量翻译
|
||
|
||
---
|
||
|
||
## 文档标识
|
||
|
||
| 字段 | 值 |
|
||
|------|-----|
|
||
| 文档标题（Document Title） | 软件组件与系统建模指南（SW-C and System Modeling Guide） |
|
||
| 文档所有者（Document Owner） | AUTOSAR |
|
||
| 文档责任人（Document Responsibility） | AUTOSAR |
|
||
| 文档标识号（Document Identification No） | 207 |
|
||
| 文档状态（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 | • Units 和 Physical Dimensions 元素的新建模规则<br>• Display names 中 Units 的扩展公式表达式 |
|
||
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | • 在 CompositionSWComponents 域中引入系统级描述<br>• IDENTICAL CompuMethods 建模规则与 ASAM 表示对齐<br>• 完整可追溯到建模需求文档 |
|
||
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | • 通过新建模规则增强通用 CompuMethods 复用机制<br>• 扩展 Long Names 标准化的命名规则和建议<br>• 扩展应用接口域中 blueprint 机制的描述 |
|
||
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | • 文档范围扩展以支持 Long Names 规则<br>• 为 Long Names 标准化定义规则和建议<br>• 定义支持关键字缩略语多义的规则<br>• 支持特定分辨率的 CompuMethods 复用<br>• 扩展 blueprintable 包子包的结构 |
|
||
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | • 描述"蓝图（Blueprint）"机制及其对应用接口域中 Blueprintable 元素的影响<br>• 新的 Autosar 应用接口包结构<br>• 根据标准化模板规范和新的应用接口包结构重新制定关键字处理<br>• 增强"Units"部分并引入新的"Physical Dimensions"部分 |
|
||
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | • 针对多实例的建模规则优化<br>• 标准化 Autosar 包结构的新描述<br>• 引入新的 RTE 规范和需求引用 |
|
||
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | • 更改建模规则集以允许关于聚类和未来可扩展性的不同建模风格<br>• 更改命名约定规则集以允许在创建自解释名称时具有更大的灵活性<br>• 标准化 AR-Package 的名称和数量已更改。相应地扩展了命名约定的范围<br>• 蓝图概念作为 Ports 的专用 AR-Package 得到支持<br>• Long Names 不在范围内<br>• 修订法律免责声明 |
|
||
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | • 修订法律免责声明 |
|
||
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | • 初始发布（Initial Release） |
|
||
|
||
---
|
||
|
||
## 目录（Table of Contents）
|
||
|
||
1. [参考文献（References）](#1-参考文献references)
|
||
2. [范围（Scope）](#2-范围scope)
|
||
3. [如何阅读本文档（How to read this document）](#3-如何阅读本文档how-to-read-this-document)
|
||
- 3.1 [使用的约定（Conventions used）](#31-使用的约定conventions-used)
|
||
- 3.2 [缩略语与缩写（Acronyms and Abbreviations）](#32-缩略语与缩写acronyms-and-abbreviations)
|
||
4. [需求可追溯性（Requirements traceability）](#4-需求可追溯性requirements-traceability)
|
||
5. [建模规则（Modeling Rules）](#5-建模规则modeling-rules)
|
||
- 5.1 [模型元素的复用（Reuse of model element）](#51-模型元素的复用reuse-of-model-element)
|
||
- 5.2 [使用多个 ComponentPrototypes（Use of multiple ComponentPrototypes）](#52-使用多个-componentprototypesuse-of-multiple-componentprototypes)
|
||
- 5.3 [聚类（Clustering）](#53-聚类clustering)
|
||
- 5.4 [未来可扩展性（Future extensibility）](#54-未来可扩展性future-extensibility)
|
||
6. [AUTOSAR 模型元素的命名约定（Naming Convention for AUTOSAR Model Elements）](#6-autosar-模型元素的命名约定naming-convention-for-autosar-model-elements)
|
||
- 6.1 [Long Names 的一般规则（General Rules for Long Names）](#61-long-names-的一般规则general-rules-for-long-names)
|
||
- 6.2 [Short Names 的一般规则（General Rules for Short Names）](#62-short-names-的一般规则general-rules-for-short-names)
|
||
- 6.3 [模型层与实现层之间的关系（Relation between Model Level and the Implementation Level）](#63-模型层与实现层之间的关系relation-between-model-level-and-the-implementation-level)
|
||
- 6.4 [关键字的使用（Usage of Keywords）](#64-关键字的使用usage-of-keywords)
|
||
- 6.5 [模型元素（Model Elements）](#65-模型元素model-elements)
|
||
|
||
---
|
||
|
||
## 1 参考文献（References）
|
||
|
||
| 编号 | 名称 | 文档 |
|
||
|------|------|------|
|
||
| [1] | Template UML Profile and Modeling Guide | `AUTOSAR_TemplateModelingGuide.pdf` |
|
||
| [2] | Specification of RTE Software | `AUTOSAR_SWS_RTE.pdf` |
|
||
| [3] | Software Component Template | `AUTOSAR_TPS_SoftwareComponentTemplate.pdf` |
|
||
| [4] | AUTOSAR Model Persistence Rules for XML | `AUTOSAR_TR_XMLPersistenceRules.pdf` |
|
||
| [5] | MISRA-C: 2004. Guidelines for the use of the C language in critical systems. | — |
|
||
| [6] | Autosar Methodology | `AUTOSAR_TR_Methodology.pdf` |
|
||
| [7] | Generic Structure Template | `AUTOSAR_TPS_GenericStructureTemplate.pdf` |
|
||
| [8] | Requirements on Runtime Environment | `AUTOSAR_SRS_RTE.pdf` |
|
||
| [9] | Standardization Template | `AUTOSAR_TPS_StandardizationTemplate.pdf` |
|
||
| [10] | Requirements for Software Component Modeling | `AUTOSAR_RS_SWCModeling.pdf` |
|
||
| [11] | AUTOSAR System Template | `AUTOSAR_TPS_SystemTemplate.pdf` |
|
||
|
||
---
|
||
|
||
## 2 范围（Scope）
|
||
|
||
> "我的语言界限即我的世界界限。" —— 路德维希·维特根斯坦
|
||
|
||
本文档提供有关使用 AUTOSAR 模型元素以构建 AUTOSAR 系统的**指南和约定**。它不包含 AUTOSAR 元模型的指南。相关内容已由 [1] 涵盖。
|
||
|
||
---
|
||
|
||
## 3 如何阅读本文档（How to read this document）
|
||
|
||
所有规则都由一个 ID 标识。
|
||
|
||
- 该 ID 以 "TR_SWMG_" 开头用于**建模规则**，后跟四位数字（`TR_SWMG_xxxx`）。
|
||
- 该 ID 以 "TR_SWNR_" 开头用于**命名规则**，后跟四位数字（`TR_SWNR_xxxx`）。
|
||
|
||
所提供的 XML 示例符合 AUTOSAR 元模型。
|
||
|
||
### 3.1 使用的约定（Conventions used）
|
||
|
||
在需求中，使用以下特定语义（取自 Internet Engineering Task Force IETF 的请求评论 RFC 2119）：
|
||
|
||
本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照 RFC 2119 中的描述进行解释。请注意，使用这些词的文档的需求级别会修改这些词的强制力。
|
||
|
||
- **MUST / REQUIRED / SHALL**：该词或术语意味着该定义是规范的绝对要求。
|
||
- **MUST NOT / SHALL NOT**：该短语意味着该定义是规范的绝对禁止。
|
||
- **SHOULD / RECOMMENDED**：该词或形容词 "RECOMMENDED" 意味着在特定情况下可能存在合理的理由去忽略某一项，但在选择不同做法之前必须充分理解并仔细权衡其全部影响。
|
||
- **SHOULD NOT / NOT RECOMMENDED**：该短语意味着在特定情况下某些行为可能是可以接受的或甚至有用的，但在实现任何带有此标签描述的行为之前，应充分理解其全部影响并仔细权衡。
|
||
- **MAY / OPTIONAL**：该词或形容词 "OPTIONAL" 意味着某项是真正可选的。
|
||
|
||
### 3.2 缩略语与缩写（Acronyms and Abbreviations）
|
||
|
||
| 缩写 | 含义 |
|
||
|------|------|
|
||
| API | Application Programming Interface（应用编程接口） |
|
||
| AR | AUTOSAR |
|
||
| CAN | Controller Area Network（控制器局域网） |
|
||
| 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（工作包） |
|
||
| XML | eXtensible Markup Language（可扩展标记语言） |
|
||
|
||
---
|
||
|
||
## 4 需求可追溯性（Requirements traceability）
|
||
|
||
针对本文档的需求仅在相应的需求文档 [10] 中声明。
|
||
|
||
下表引用了 [10] 中指定的需求，并提供了满足给定需求的各个规范项的信息。
|
||
|
||
| 需求 | 描述 | 由以下规范项满足 |
|
||
|------|------|------------------|
|
||
| `RS_SWMG_00001` | 区分标准化与非标准化的 ARElement 类型模型元素 | `TR_SWMG_00003`、`TR_SWMG_00004`、`TR_SWMG_00017`、`TR_SWMG_00018`、`TR_SWNR_00022`、`TR_SWNR_00023` |
|
||
| `RS_SWMG_00002` | 名称应反映模型元素的用途 | `TR_SWMG_00009`、`TR_SWMG_00011`、`TR_SWNR_00004`、`TR_SWNR_00006` |
|
||
| `RS_SWMG_00005` | 易于创建名称 | `TR_SWNR_00010` |
|
||
| `RS_SWMG_00006` | 模型元素的名称应自解释 | `TR_SWMG_00009`、`TR_SWMG_00011`、`TR_SWNR_00004`、`TR_SWNR_00006`、`TR_SWNR_00037` |
|
||
| `RS_SWMG_00007` | 区分不同模型元素供应商的模型元素 | `TR_SWMG_00003`、`TR_SWMG_00004`、`TR_SWMG_00017`、`TR_SWNR_00059` |
|
||
| `RS_SWMG_00010` | 模型元素名称应遵循语义规则 | `TR_SWMG_00010`、`TR_SWMG_00011`、`TR_SWMG_00012`、`TR_SWMG_00013`、`TR_SWMG_00014`、`TR_SWMG_00015`、`TR_SWMG_00016`、`TR_SWMG_00019`、`TR_SWNR_00005`、`TR_SWNR_00008`、`TR_SWNR_00026`、`TR_SWNR_00027`、`TR_SWNR_00029`、`TR_SWNR_00040`、`TR_SWNR_00041`、`TR_SWNR_00042`、`TR_SWNR_00043`、`TR_SWNR_00044`、`TR_SWNR_00051`、`TR_SWNR_00055`、`TR_SWNR_00056`、`TR_SWNR_00057`、`TR_SWNR_00062`、`TR_SWNR_00069`、`TR_SWNR_00070`、`TR_SWNR_00071`、`TR_SWNR_00072` |
|
||
| `RS_SWMG_00011` | 模型元素名称由标准化关键字排列组成 | `TR_SWNR_00009`、`TR_SWNR_00010`、`TR_SWNR_00011`、`TR_SWNR_00013`、`TR_SWNR_00018`、`TR_SWNR_00066` |
|
||
| `RS_SWMG_00012` | 模型元素名称的语义应允许可变数量的关键字 | `TR_SWNR_00019`、`TR_SWNR_00020`、`TR_SWNR_00034`、`TR_SWNR_00050`、`TR_SWNR_00058` |
|
||
| `RS_SWMG_00014` | Identifiable 的 short name 长度限制 | `TR_SWNR_00002` |
|
||
| `RS_SWMG_00016` | 名称应允许表明值是直接测量值还是条件值 | `TR_SWNR_00019`、`TR_SWNR_00058` |
|
||
| `RS_SWMG_00017` | 名称应遵循 ISO 8855 进行英文命名 | `TR_SWNR_00001` |
|
||
| `RS_SWMG_00030` | 使用英语作为名称的标准语言 | `TR_SWNR_00001`、`TR_SWNR_00013` |
|
||
| `RS_SWMG_00031` | 名称中不含架构信息 | `TR_SWNR_00007`、`TR_SWNR_00035`、`TR_SWNR_00036`、`TR_SWNR_00048` |
|
||
| `RS_SWMG_00034` | 关键字的唯一使用 | `TR_SWNR_00066`、`TR_SWNR_00067`、`TR_SWNR_00068` |
|
||
| `RS_SWMG_00039` | 避免使用尾部下划线 | `TR_SWNR_00003` |
|
||
| `RS_SWMG_00040` | 避免下划线字符的连续使用 | `TR_SWNR_00003`、`TR_SWNR_00009` |
|
||
| `RS_SWMG_00041` | 不仅依赖大小写差异区分名称 | `TR_SWNR_00004`、`TR_SWNR_00011` |
|
||
| `RS_SWMG_00048` | 易于在数据库中查找名称 | `TR_SWMG_00008` |
|
||
| `RS_SWMG_00049` | 支持主表中已存在的 Identifiable | `TR_SWMG_00018` |
|
||
| `RS_SWMG_00052` | 包结构的定义 | `TR_SWMG_00008` |
|
||
| `RS_SWMG_00053` | 模型应符合元模型 | `TR_SWMG_00001` |
|
||
| `RS_SWMG_00054` | 提供解决命名冲突的指南 | `TR_SWNR_00001` ~ `TR_SWNR_00072`（共 50+ 项） |
|
||
| `RS_SWMG_00055` | 连续数据类型分辨率应为 2 的幂 | `TR_SWMG_00004` |
|
||
| `RS_SWMG_00056` | 标准化模型元素不应包含非标准化元素 | `TR_SWMG_00003`、`TR_SWMG_00004`、`TR_SWMG_00017`、`TR_SWNR_00022` |
|
||
| `RS_SWMG_00057` | 建模指南应支持 AUTOSAR 方法论 | `TR_SWMG_00001` |
|
||
| `RS_SWMG_00059` | 应存在单一的关键字集 | `TR_SWNR_00010` |
|
||
| `RS_SWMG_00060` | 命名约定的适用性 | `TR_SWNR_00059` |
|
||
| `RS_SWMG_00061` | 命名约定应具有唯一性 | `TR_SWNR_00001`、`TR_SWNR_00002`、`TR_SWNR_00003`、`TR_SWNR_00004`、`TR_SWNR_00005`、`TR_SWNR_00006`、`TR_SWNR_00007`、`TR_SWNR_00063`、`TR_SWNR_00064`、`TR_SWNR_00065` |
|
||
| `RS_SWMG_00062` | 命名约定应规定 Short Names 与 Long Names 的构造 | `TR_SWNR_00001`、`TR_SWNR_00002`、`TR_SWNR_00050`、`TR_SWNR_00063`、`TR_SWNR_00064`、`TR_SWNR_00065` |
|
||
|
||
---
|
||
|
||
## 5 建模规则（Modeling Rules）
|
||
|
||
#### [TR_SWMG_00001] 符合 Autosar 元模型
|
||
|
||
⌈ 模型应符合元模型。 ⌋ (`RS_SWMG_00053`、`RS_SWMG_00057`)
|
||
|
||
#### [TR_SWMG_00003] 为 SW-C 使用 AR Package 概念
|
||
|
||
⌈ 为 SW-C 使用 AR Package 概念以区分不同的 SW-C 提供者。 ⌋ (`RS_SWMG_00001`、`RS_SWMG_00007`、`RS_SWMG_00056`)
|
||
|
||
示例：`Autosar_AISpecification`、`Supplier1`、`Supplier2`、`OEM1`
|
||
|
||
#### [TR_SWMG_00017] 使用 AR Package 类别
|
||
|
||
⌈ 使用 AR Package 类别以根据 ARPackage 的提供者将标准化的内容与非标准化的内容区分开来。 ⌋ (`RS_SWMG_00001`、`RS_SWMG_00007`、`RS_SWMG_00056`)
|
||
|
||
有关 AR Package 类别的分类，请参见文档 [7]。
|
||
|
||
#### [TR_SWMG_00004] 非 AUTOSAR 合作伙伴定义的元素的单独包
|
||
|
||
⌈ AUTOSAR 合作伙伴未定义的每个元素都应包含在不同于 AUTOSAR 正式发布的 AR Package 中，即 AR Package ShortName 应更改（例如 SUPPLIER1），并且可以根据 AR Package 类别分类和利益相关者特定标准元素处理更改或不更改类别。 ⌋ (`RS_SWMG_00001`、`RS_SWMG_00007`、`RS_SWMG_00055`、`RS_SWMG_00056`)
|
||
|
||
**建议**：
|
||
|
||
- 连续数据类型分辨率应为 2 的幂。
|
||
|
||
### 5.1 模型元素的复用（Reuse of model element）
|
||
|
||
#### 5.1.1 一个接口复用于多个端口
|
||
|
||
鼓励复用接口。
|
||
|
||
**示例**：
|
||
|
||
Temperature 接口用于组件类型的 `InsideTemperature` 端口和 `OutsideTemperature` 端口。
|
||
|
||
#### [TR_SWMG_00011] 接口定义与变体的独立性
|
||
|
||
⌈ 不要定义不同的接口来实现变体。定义一个独立于变体的接口，并定义使用此接口的几个端口，这些端口依赖于变体。 ⌋ (`RS_SWMG_00002`、`RS_SWMG_00006`、`RS_SWMG_00010`)
|
||
|
||
对多个端口使用一个接口使变体处理更易于理解，因为接口不受变体影响。端口可以根据所选变体启用或禁用。
|
||
|
||
**示例**：
|
||
|
||
汽油火花点火发动机管理系统知道用于扭矩干预的慢路径和快路径的概念。当前的柴油系统不知道这种区别。
|
||
|
||
**不推荐**以下建模：
|
||
|
||
- 定义接口 `TorqueInterventionSlow` 和接口 `TorqueInterventionFast`。
|
||
- 定义端口 `TorqueInterventionSlow`（使用接口 `TorqueInterventionSlow`）和端口 `TorqueInterventionFast`（使用接口 `TorqueInterventionFast`）。
|
||
- 在柴油变体中，忽略 `TorqueInterventionSlow` 端口和接口。
|
||
|
||
**推荐**以下建模：
|
||
|
||
- 定义接口 `TorqueIntervention1`。
|
||
- 定义端口 `TorqueInterventionSlow` 和端口 `TorqueInterventionFast`，它们都使用接口 `TorqueIntervention1`。
|
||
- 在柴油变体中，禁用 `TorqueInterventionSlow` 端口。
|
||
|
||
> **图 1：变体情况下 PortInterfaces 在端口中的复用**
|
||
|
||
请注意，在示例中，作为变体处理方法的结果，两个 `ComponentPrototypes` 属于同一个 `ComponentType`。
|
||
|
||
#### 5.1.2 一个数据类型复用于多个接口
|
||
|
||
鼓励复用数据类型。
|
||
|
||
**示例**：
|
||
|
||
Torque 数据类型用于接口 `MinimumTorqueAtClutch` 和 `MaximumTorqueAtClutch` 的 Data Elements 中。
|
||
|
||
### 5.2 使用多个 ComponentPrototypes（Use of multiple ComponentPrototypes）
|
||
|
||
如果同一端口 P（RPort 或 PPort）的多个 ComponentPrototypes A 1..n 属于同一 ComponentType，并连接到另一个 ComponentPrototype B，则端口的名称应通过连接所连接的 ComponentPrototype Ai 的名称和所连接的端口 P 的名称来构造。
|
||
|
||
建议通过介词（参见第 6 章）按以下顺序进行连接：
|
||
|
||
```
|
||
<Port name> + <Preposition> + [<ComponentPrototype name>]
|
||
```
|
||
|
||
**示例**："Washer" ComponentType 有一个 RPort "Activation"。此类型有三个 ComponentPrototypes："WasherFront"、"WasherRear" 和 "WasherHeadlamp"。`WiperWasherManager` ComponentType 应具有单独的 PPorts，它们连接到三个 ComponentPrototypes 的 RPorts。这些 PPorts 应具有名称 "ActivationOfWasherFront"、"ActivationOfWasherRear" 和 "ActivationOfWasherHeadlamp"。
|
||
|
||
> **图 2：多个 ComponentPrototypes 的端口**
|
||
|
||
### 5.3 聚类（Clustering）
|
||
|
||
#### [TR_SWMG_00008] 聚类
|
||
|
||
⌈ 在功能上属于一起的元素也应在模型中一起表示。 ⌋ (`RS_SWMG_00048`、`RS_SWMG_00052`)
|
||
|
||
AUTOSAR 元模型提供了几个特征来支持模型元素的聚类。例如，接口可以包含多个数据元素，记录数据类型和数组数据类型可以包含多个元素。使用结构化特征可以改善模型的结构和可理解性。
|
||
|
||
#### 5.3.1 通过 Sender Receiver 接口聚类
|
||
|
||
如果通过 Sender Receiver 接口对元素进行聚类，则可以在三种具有不同行为且通常适用于不同应用场景的替代方案之间进行选择：
|
||
|
||
- **A) 记录数据类型**：
|
||
- 记录的元素以原子方式（在一个块中）传输。
|
||
- 记录数据类型的元素可以具有不同的数据类型。
|
||
- **B) 数组数据类型**：
|
||
- 数组的元素以原子方式（在一个块中）传输，
|
||
- 数组的所有元素必须使用相同的数据类型。
|
||
- **C) 具有多个数据元素的接口**：
|
||
- 接口的数据元素是单独传输的。
|
||
- 接口的数据元素可以具有不同的数据类型。
|
||
|
||
这三种替代方案的使用示例包括：
|
||
|
||
- **对 A）**：使用包含以下内容的记录数据类型：
|
||
- 属于一起的状态及其值，例如用于执行器
|
||
- 属于一起的轮相关的信息
|
||
- 属于一起的车桥相关信息
|
||
- 值及其推导。
|
||
- **对 B）**：使用数组数据类型：
|
||
- 发送动态配置数据，例如发动机全负荷曲线，或在车辆行驶时可能变化的缓速器制动扭矩曲线，具体取决于温度或高度。此用例在商用车辆 J1939 总线协议（CAN 上）中很常见。
|
||
- **对 C）**：具有独立更新时间的属于一起的数据：
|
||
- 默认用于大多数信号，允许系统配置器在调度通信时具有最大的灵活性。
|
||
|
||
使用记录而不是数组数据类型的优点是为每个元素使用单独的名称。
|
||
|
||
### 5.4 未来可扩展性（Future extensibility）
|
||
|
||
通常需要调整和扩展模型元素以适应新的需求。定义或标准化的名为 "Reserved"（或其他名称表示项目相关解决方案）的元素作为未来扩展的占位符而具有未定义的含义，将在项目级别执行定制时导致非标准化元素。
|
||
|
||
#### [TR_SWMG_00009] 不允许具有未定义含义的占位符模型元素
|
||
|
||
⌈ 不允许具有未定义含义的占位符模型元素。 ⌋ (`RS_SWMG_00002`、`RS_SWMG_00006`)
|
||
|
||
以下规则确保相关模型元素对新 AUTOSAR 版本的**向前兼容性**。
|
||
|
||
#### [TR_SWMG_00010] 标准化枚举数据类型名称的区分
|
||
|
||
⌈ 如果新应用需要修改标准化枚举数据类型的任何属性（枚举值、枚举值名称），则**不应更改**现有数据类型，而应创建新的枚举数据类型。新数据类型的名称应仅在序列号上与原始数据类型的名称不同。 ⌋ (`RS_SWMG_00010`)
|
||
|
||
#### [TR_SWMG_00012] 标准化连续数据类型名称的区分
|
||
|
||
⌈ 如果新应用需要修改标准化连续数据类型的任何属性（分辨率、物理限制、偏移量、单元），则**不应更改**现有数据类型，而应创建新的连续数据类型。新数据类型的名称应仅在序列号上与原始数据类型的名称不同。 ⌋ (`RS_SWMG_00010`)
|
||
|
||
#### [TR_SWMG_00013] 标准化数组数据类型名称的区分
|
||
|
||
⌈ 如果新应用需要修改标准化数组数据类型的任何属性（元素数量、元素类型），则**不应更改**现有数据类型，而应创建新的数组数据类型。新数据类型的名称应仅在序列号上与原始数据类型的名称不同。 ⌋ (`RS_SWMG_00010`)
|
||
|
||
#### [TR_SWMG_00014] 标准化记录数据类型名称的区分
|
||
|
||
⌈ 如果新应用需要修改标准化记录数据类型的任何属性（元素数量、元素名称、元素类型），则**不应更改**现有数据类型，而应创建新的记录数据类型。新数据类型的名称应仅在序列号上与原始数据类型的名称不同。 ⌋ (`RS_SWMG_00010`)
|
||
|
||
#### [TR_SWMG_00015] 标准化发送方-接收方接口名称的区分
|
||
|
||
⌈ 如果新应用需要修改标准化发送方-接收方接口的任何属性（数据元素数量、数据元素名称、数据元素类型），则**不应更改**现有接口，而应创建新的发送方-接收方接口。新接口的名称应仅在序列号上与原始接口的名称不同。 ⌋ (`RS_SWMG_00010`)
|
||
|
||
#### [TR_SWMG_00016] 标准化客户端-服务器接口名称的区分
|
||
|
||
⌈ 如果新应用需要修改标准化客户端-服务器接口的任何属性（操作名称、参数数量、参数名称、参数数据类型、参数 in/out 属性），则**不应更改**现有接口，而应创建新的接口。新接口的名称应仅在序列号上与原始接口的名称不同。 ⌋ (`RS_SWMG_00010`)
|
||
|
||
#### [TR_SWMG_00019] 标准化 PortPrototypeBlueprints 名称的区分
|
||
|
||
⌈ 如果新应用需要修改标准化 `PortPrototypeBlueprint` 的名称（shortname），或对引用元素（端口接口、应用数据类型、单元）进行任何更改，则**不应更改**现有的 `PortPrototypeBlueprint`，而应创建新的 `PortPrototypeBlueprint`。新的 `PortPrototypeBlueprint` 的名称（shortname）应仅在序列号上与原始 `PortPrototypeBlueprint` 的名称不同。`PortPrototypeBlueprint` 的描述元素（description、longname、introduction）的更改不一定导致 `PortPrototypeBlueprint` 的新版本，除非原始元素的含义被修改。 ⌋ (`RS_SWMG_00010`)
|
||
|
||
---
|
||
|
||
## 6 AUTOSAR 模型元素的命名约定（Naming Convention for AUTOSAR Model Elements）
|
||
|
||
本节包含 AUTOSAR 模型元素的命名约定。此命名约定适用于 AUTOSAR 的任何车辆应用域。
|
||
|
||
#### [TR_SWNR_00059] 命名约定的范围
|
||
|
||
⌈ 命名约定适用于以下模型元素：
|
||
|
||
- `SwComponentTypes`
|
||
- `SwComponentPrototypes`
|
||
- `ApplicationDataTypes`
|
||
- `Units`
|
||
- `PhysicalDimensions`
|
||
- `PortInterfaces`
|
||
- `PortPrototypeBlueprints`
|
||
- `PortPrototypes`
|
||
- `DataPrototypes`
|
||
- `CompuMethods`
|
||
- `DataConstrs`
|
||
- `Keywords`
|
||
|
||
⌋ (`RS_SWMG_00007`、`RS_SWMG_00054`、`RS_SWMG_00060`)
|
||
|
||
文档中显示的 XML 代码符合 AUTOSAR 模式 xsd。
|
||
|
||
本文档中定义的命名约定侧重于为构建三个主要 Autosar 元模型元素的内容定义规则：
|
||
|
||
1. 属性 `longName`，派生自抽象类 `MultilanguageReferrable`
|
||
2. 属性 `shortName`，派生自抽象类 `Referrable`
|
||
3. 关键字和关键字缩略语
|
||
|
||
属性 `longName` 和 `shortName` 是 TR_SWNR_00059 中列出的所有 Autosar 元素所共有的。关键字缩略语的概念与 [9] 中的关键字类定义密切相关，将在 6.4 节中讨论。
|
||
|
||
### 6.1 Long Names 的一般规则（General Rules for Long Names）
|
||
|
||
根据 [7]，Long Names（属性 `longName`）针对人类读者，可以用不同的语言表示。它们包含对象的标题作为单行文本。
|
||
|
||
#### [TR_SWNR_00063] 应用接口上下文中 Long Names 的强制性
|
||
|
||
⌈ 在应用接口域的上下文中，即使 `longName` 在 Autosar 元模型中的多重性是 0..1，`longName` 也是**强制属性**。 ⌋ (`RS_SWMG_00054`、`RS_SWMG_00061`、`RS_SWMG_00062`)
|
||
|
||
#### [TR_SWNR_00064] 英文 Long Name 构造中的大写和小写字母
|
||
|
||
⌈ 为了提高可读性：
|
||
|
||
- long name 的每个首词应以大写字母开头。
|
||
- 冠词（例如 "a"、"the"）、介词（例如 "at"、"by"、"to"）和连词（例如 "and"、"or"）应以小写字母表示。
|
||
- 文本行中的所有其他单词应以大写字母开头。
|
||
|
||
⌋ (`RS_SWMG_00054`、`RS_SWMG_00061`、`RS_SWMG_00062`)
|
||
|
||
#### [TR_SWNR_00065] Long Name 构造中空格的使用
|
||
|
||
⌈ 单词之间的空格使用应是**强制性的**。 ⌋ (`RS_SWMG_00054`、`RS_SWMG_00061`、`RS_SWMG_00062`)
|
||
|
||
此外，在处理 long name 构造时，强烈建议采用以下一些具体建议：
|
||
|
||
**缩略语的使用**：
|
||
|
||
- 应尽可能避免使用缩略语。如果需要，在 long names 中应仅使用众所周知的缩略语。
|
||
- 如果存在，所有缩略语都需要在描述中进行解释。
|
||
- 功能和系统的缩略语应使用关键字的 long name（例如 "ABS"）。如果缩略语不是非常知名，请将其放在括号中，例如 "Application Interfaces, (AI)"。
|
||
|
||
**Long Names 构造**：
|
||
|
||
- long names 不应包含尾随数字/序列号，以避免多个条目具有相同的 long names。
|
||
- long name 的基础应该是 short name 的扩展形式。
|
||
- 单词的顺序可以更改，可以添加其他术语。可以交换单个术语以提高可理解性。
|
||
- long name 的最大长度应限制为 80 个字符，根据 [7]。例外：关键字的 long names 遵循不同的规则，请参见 6.4.1 节。
|
||
|
||
### 6.2 Short Names 的一般规则（General Rules for Short Names）
|
||
|
||
在本章和本文档的其余部分中，术语"名称（name）"仅指"short name"。
|
||
|
||
#### [TR_SWNR_00001] 名称的语言应为英语
|
||
|
||
⌈ 名称的语言应为英语。 ⌋ (`RS_SWMG_00017`、`RS_SWMG_00030`、`RS_SWMG_00054`、`RS_SWMG_00061`、`RS_SWMG_00062`)
|
||
|
||
模型元素名称在 XML 中显示为 `SHORT-NAME`，例如：
|
||
|
||
```xml
|
||
<SHORT-NAME>MyName</SHORT-NAME>
|
||
```
|
||
|
||
根据 AUTOSAR XML 文件的规则，short name 的类型为 `AR:IDENTIFIER`（参见文档 [4]），并受以下正则表达式限制：`[a-zA-Z][a-zA-Z0-9_]{0,127}`
|
||
|
||
#### [TR_SWNR_00002] Short Names 的长度
|
||
|
||
⌈ short name 应为 1 到 128 个字符长，应以字母开头，并应由字母和数字组成。 ⌋ (`RS_SWMG_00014`、`RS_SWMG_00054`、`RS_SWMG_00061`、`RS_SWMG_00062`)
|
||
|
||
#### [TR_SWNR_00003] Short Names 中禁止使用下划线
|
||
|
||
⌈ 作为对元模型的附加要求，short names 中**不允许**使用下划线。 ⌋ (`RS_SWMG_00039`、`RS_SWMG_00040`、`RS_SWMG_00054`、`RS_SWMG_00061`)
|
||
|
||
规则 TR_SWNR_00002 和 TR_SWNR_00003 得出 short names 的以下正则表达式：`[a-zA-Z][a-zA-Z0-9]{0,127}`
|
||
|
||
#### [TR_SWNR_00004] 不允许仅基于大小写的区分
|
||
|
||
⌈ 在一个命名空间中，ShortNames **不应仅在大小写上不同**。 ⌋ (`RS_SWMG_00002`、`RS_SWMG_00006`、`RS_SWMG_00041`、`RS_SWMG_00054`、`RS_SWMG_00061`)
|
||
|
||
不要仅从大写/小写格式区分名称，因为用户很容易混淆仅在大小写上不同的名称。以下示例列出了**不允许**的名称区分：
|
||
|
||
- Short name 1: `DoorLocked`
|
||
- Short name 2: `doorLocked`
|
||
|
||
#### [TR_SWNR_00005] C、C++ 和 C 预处理器源代码中的有效标识符
|
||
|
||
⌈ 名称必须可用作 C、C++ 和 C 预处理器源代码中的有效标识符。 ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`、`RS_SWMG_00061`)
|
||
|
||
此规则背后的原理是，某些名称由代码生成器（特别是 RTE 生成器）用于生成源代码符号。由于难以说明每个单独的名称是否以及在什么上下文中被生成器使用，因此制定了此一般限制。
|
||
|
||
#### [TR_SWNR_00006] Short Names 含义
|
||
|
||
⌈ 元素的名称应**记录其含义或用途**。 ⌋ (`RS_SWMG_00002`、`RS_SWMG_00006`、`RS_SWMG_00054`、`RS_SWMG_00061`)
|
||
|
||
#### [TR_SWNR_00007] 不允许使用前缀来标识元素的种类
|
||
|
||
⌈ 在本命名约定涵盖的模型元素（在 TR_SWNR_00059 中列出）的名称中，**不应使用与元素种类相关的前缀**。 ⌋ (`RS_SWMG_00031`、`RS_SWMG_00054`、`RS_SWMG_00061`)
|
||
|
||
不使用前缀的原因：
|
||
|
||
- 名称更短，例如如果它在 RTE API 中显示为 `RTE_...`
|
||
- 如果我们对例如接口有任何前缀，则必须为所有元素（端口、SWC、数据类型...）定义前缀。
|
||
- 代码生成器可以为编程语言 API 的标识符引入前缀。
|
||
- 关于某个元素是 Component、DataType、Interface 等的信息已经包含在 XML 文件的结构中。
|
||
|
||
### 6.3 模型层与实现层之间的关系（Relation between Model Level and the Implementation Level）
|
||
|
||
本节描述了 AUTOSAR 的模型层和实现层之间的关系。本章中的"模型"是指 AUTOSAR 模型，即 AUTOSAR 元模型的一个实例。"实现"是指用编程语言（如 C）实现模型。有关更详细的解释，请参阅 AUTOSAR 方法论文档 [6]。
|
||
|
||
#### 6.3.1 长度限制
|
||
|
||
RTE 规范 [2] 包含有关如何将模型级名称映射到实现级生成名称的规则。
|
||
|
||
例如，sender/receiver 隐式写入的实现级名称创建如下：
|
||
|
||
```
|
||
Rte_IWrite_<runnable-entity-name>_<port-name>_<data-element-name>
|
||
```
|
||
|
||
此名称作为外部标识符对链接器可见。MISRA [5] 规则 1.4 要求此类名称的有效部分不得超过 31 个字符。由于 AUTOSAR 决定允许偏离此规则，因此生成名称的大小可以超过 31。考虑到模型中的每个单独名称不能超过 128 个字符，上述名称最多可以包含 `10 + 1 + 128 + 1 + 128 + 1 + 128 = 397` 个字符。
|
||
|
||
#### 6.3.2 数据类型
|
||
|
||
#### [TR_SWNR_00008] 数据类型名称应符合 C/C++ typedefs 名称
|
||
|
||
⌈ AUTOSAR 模型中的数据类型名称应符合 C/C++ typedefs 名称（例如，它们不应是 C 关键字）。 ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
|
||
#### 6.3.3 RTE 名称映射规则
|
||
|
||
以下 RTE 需求描述了从建模层到实现层的映射：
|
||
|
||
- `SWS_Rte_1153`
|
||
- `SWS_Rte_3837`
|
||
|
||
此类 `SWS_Rte` 规则定义了模型元素 ShortNames 连接的顺序，以在 RTE C 代码中获得生成的函数名称。
|
||
|
||
**示例 1**：
|
||
|
||
- 组件类型的 ShortName：`Wshr`
|
||
- 组件原型的 ShortName：`WshrFrnt`
|
||
- 可运行实体的 ShortName：`Monr`
|
||
- 提供端口的 ShortName：`OutdT`
|
||
- 此端口的 sender-receiver 接口的 ShortName：`T1`
|
||
- 数据元素的 ShortName：`Val`
|
||
|
||
规则 `SWS_Rte_3837` 的生成函数名称示例：
|
||
|
||
```
|
||
Rte_IRead_Monr_OutdT_Val
|
||
Rte_IRead_Wshr_Monr_OutdT_Val
|
||
```
|
||
|
||
> *本示例中使用的关键字和关键字缩略语可能与关键字列表不一致。*
|
||
|
||
#### 6.3.4 组件和端口
|
||
|
||
> **图 3：组件和端口**
|
||
|
||
抽象的 `SwComponentType` 无法实例化，只能是 `CompositionSwComponentType`、`ParameterSwComponentType` 或 `AtomicSwComponentType` 类的特化继承类。请参见 [3] 了解更多详情。此类 `AtomicSwComponentTypes` 封装了其功能和行为的实现，并仅向外部公开定义明确的连接点（称为 `PortPrototypes`）。
|
||
|
||
`CompositionSwComponentType`（也是 `SwComponentTypes`）可以聚合到进一步的 `CompositionSwComponentTypes` 中，其目的是允许聚合现有软件组件。
|
||
|
||
在 `CompositionSwComponentType` 中，`SwComponentTypes` 以特定角色（称为 `SwComponetPrototypes`）出现。
|
||
|
||
上图显示了 Components 和 Ports 名称的范围。`SwComponentTypes` 名称对于 AR-Package 是本地的，因此在一个 AR-Package 中不能有两个具有相同名称的 `SwComponentTypes`，即 short-names 应是唯一的。这由 RTE 实现明确要求，因为 RTE 生成器拒绝多个 `SwComponentTypes` 具有相同 short name 的配置（有关更多详细信息，请参见 [2] 中的 [SWS_Rte_7190]）。
|
||
|
||
同样的情况也适用于：
|
||
|
||
- `CompositionSwComponentType` 中的 `SwComponentPrototypes`
|
||
- `SwComponentType` 中的 `PortPrototypes`
|
||
|
||
有关软件组件提供的命名空间的详细信息，请参见文档 [3]。
|
||
|
||
端口名称将出现在 RTE API 中，请参见 RTE 规范 [2]。
|
||
|
||
上图还显示，所连接端口的名称可以不同（例如：Component3 的 `pp2` 连接到 Component2 的 `rp3`）。
|
||
|
||
#### 6.3.5 Sender Receiver 接口和数据元素
|
||
|
||
> **图 4：SenderReceiverInterfaces 和 Data Elements**
|
||
|
||
上图显示了 `SenderReceiverInterfaces` 和 Data Elements 名称的范围。接口名称对于 AR-Package 是本地的，因此在一个 AR-Package 中不能有两个具有相同名称的接口，即 short-names 应是唯一的。
|
||
|
||
同样的情况也适用于 Data Elements，即在一个接口内，Data Element 名称应是唯一的。有关 Sender Receiver 接口提供的命名空间的详细信息，请参见文档 [3]。
|
||
|
||
Data Element 名称将出现在 RTE API 中，请参见 RTE 规范 [2]。
|
||
|
||
#### 6.3.6 Client Server 接口、操作和参数
|
||
|
||
> **图 5：ClientServerInterfaces 和 Operations**
|
||
|
||
上图显示了 `ClientServerInterfaces`、Operations 和 Argument 名称的范围。接口名称对于 AR-Package 是本地的，因此在一个 AR-Package 中不能有两个具有相同名称的接口，即 short-names 应是唯一的。
|
||
|
||
同样的情况也适用于：
|
||
|
||
- `ClientServerInterface` 中的 Operations。
|
||
- Operation 中的 Arguments。
|
||
|
||
有关 Client Server 接口提供的命名空间的详细信息，请参见文档 [3]。
|
||
|
||
Data Element 名称将出现在 RTE API 中，请参见 RTE 规范 [2]。
|
||
|
||
### 6.4 关键字的使用（Usage of Keywords）
|
||
|
||
根据其在组件设计中的角色，组件类型、端口、端口接口或数据元素的 short names 可以使用预定义的关键字及其缩略语（6.4.1 节中详细描述）。其优点是这将产生具有既定含义的相对短小的名称。
|
||
|
||
#### 6.4.1 关键字组合语义规则
|
||
|
||
根据 [9]，每个关键字由以下属性描述：
|
||
|
||
- **shortName**：表示关键字的唯一名称，不参与名称构造
|
||
- **longName**：表示关键字的长格式
|
||
- **desc**：表示关键字的定义
|
||
- **introduction**：用例的口头描述（目前未使用）
|
||
- **abbrName**：指定关键字的缩写名称，用于构建 shortNames
|
||
- **classification**：描述关键字的语义字段（Mean-Environment-Device、Action-PhysicalType、Condition-Qualifier、Index、Preposition）
|
||
|
||
如果本文档的其余部分未另行指定，术语 **keyword** 将指关键字的 `longName`，而缩写名称也可以称为"abbrName 属性"或"关键字缩略语"。
|
||
|
||
**示例**：
|
||
|
||
描述车辆驾驶员的关键字的定义：
|
||
|
||
- `longName`: Driver
|
||
- `abbrName`: Drvr
|
||
|
||
用例（使用 abbrName 属性的端口 shortName）：`DrvrProf`、`DrvrDoorLockSt`
|
||
|
||
#### [TR_SWNR_00009] 关键字分离中下划线的无效使用
|
||
|
||
⌈ short names 中**不应使用下划线**来分隔关键字缩略语（abbrName 属性），因为 RTE 使用它们来分隔端口名称和数据元素名称。**应使用大写字母**来分隔关键字缩略语，而不是下划线。 ⌋ (`RS_SWMG_00011`、`RS_SWMG_00040`、`RS_SWMG_00054`)
|
||
|
||
#### [TR_SWNR_00010] 使用关键字构建 Short Names
|
||
|
||
⌈ Short names 是通过连接预定义的关键字缩略语（abbrName 属性）组成的。 ⌋ (`RS_SWMG_00005`、`RS_SWMG_00011`、`RS_SWMG_00054`、`RS_SWMG_00059`)
|
||
|
||
#### [TR_SWNR_00011] 每个关键字应以大写字母或数字开头，后跟小写字母或 "-"
|
||
|
||
⌈ 每个关键字应以大写字母或数字开头，后跟小写字母或 "-" ⌋ (`RS_SWMG_00011`、`RS_SWMG_00041`、`RS_SWMG_00054`)
|
||
|
||
**示例**：
|
||
|
||
- 关键字缩略语（abbrName）："Apil"
|
||
- 关键字的 Long Name："A-Pillar"
|
||
|
||
#### [TR_SWNR_00013] 关键字定义的英语语言
|
||
|
||
⌈ 关键字应为单个英文单词或乘数前缀，例如 "kilo"、"giga" 或 "milli"。为了在最大允许字符数内缩短名称，提供了关键字缩略语（abbrName 属性）。 ⌋ (`RS_SWMG_00011`、`RS_SWMG_00030`、`RS_SWMG_00054`)
|
||
|
||
#### [TR_SWNR_00018] 关键字缩略语定义规则
|
||
|
||
⌈ 关键字缩略语（abbrName 属性）**不应**是有效的单个英文单词，除非关键字和英文单词的含义相同。这避免了读取 short names 时潜在的误解。 ⌋ (`RS_SWMG_00011`、`RS_SWMG_00054`)
|
||
|
||
以下示例**不是**有效的 short name，因为使用了非缩写的关键字：`EngineSpd`。正确的 short name 应是：`EngSpd`。
|
||
|
||
可能发生的情况是，某些关键字在其 longName 形式上有所不同，但由于不同的科学或技术界通常在其领域采用众所周知的、广泛接受的缩略语或缩写，因此需要以相同的方式缩写。这些缩略语和缩写可以是完全相同的，即使它们表示不同的内容。根据 [9] 中关键字类的定义，关键字缩略语的多种含义可以通过以下三个规则（TR_SWNR_00066、TR_SWNR_00067 和 TR_SWNR_00068）处理。
|
||
|
||
#### [TR_SWNR_00066] 应用接口上下文中关键字的定义属性
|
||
|
||
⌈ 每个关键字应**恰好有一个 shortName、恰好一个 longName、恰好一个 desc、恰好一个 abbrName 和恰好一个 classification**。 ⌋ (`RS_SWMG_00011`、`RS_SWMG_00034`、`RS_SWMG_00054`)
|
||
|
||
#### [TR_SWNR_00067] 通过 abbrName 属性实现多义
|
||
|
||
⌈ 两个或多个不同的关键字**可以共享相同的 abbrName**。 ⌋ (`RS_SWMG_00034`、`RS_SWMG_00054`)
|
||
|
||
根据 [7] 和 [9]，如果一个 Identifiable 元素包含在另一个 Identifiable 元素中，则所包含的 Identifiable 元素的 shortName 在包含它的 Identifiable 元素的上下文中应是唯一的（在这种情况下，关键字是属于 Identifiable 元素的关键字集（KeywordSet））。因此，每个 shortName 在 KeywordSet 中应是唯一的。
|
||
|
||
如果关键字共享相同的 abbrName，建议使用 abbrName 加上索引作为 shortName。
|
||
|
||
#### [TR_SWNR_00068] 多义情况下关键字 shortNames 定义规则
|
||
|
||
⌈ 如果关键字缩略语（属性 abbrName）旨在具有 N 种不同的含义，则应存在 N 个关键字（属于 Keyword 类的元素），它们共享 abbrName 属性的相同值，并且每种不同的含义应在相应的关键字 desc 属性中描述。 ⌋ (`RS_SWMG_00034`、`RS_SWMG_00054`)
|
||
|
||
**示例**：
|
||
|
||
| shortName | longName | abbrName | desc | classification |
|
||
|-----------|----------|----------|------|----------------|
|
||
| Ch (*) | Charge | Ch | …… | Condition/qualifier |
|
||
| Ch1 (*) | Channel | Ch | …… | Condition/qualifier |
|
||
|
||
(*) 此示例不代表当前实现，只是保持关键字包中 shortNames 唯一性的一种可能实现。
|
||
|
||
#### [TR_SWNR_00017] 作为众所周知的缩略语的特殊关键字
|
||
|
||
⌈ 汽车环境中常用的一些术语无法用单个英文单词表示。在这种情况下，缩略语（abbrName）和关键字（longName）应**完全相同**，除了驼峰命名法和添加 "-" 之外。 ⌋ (`RS_SWMG_00054`)
|
||
|
||
**示例**：
|
||
|
||
- 关键字缩略语："Abs"，关键字的 Long Name："ABS"
|
||
- 关键字缩略语："Nox"，关键字的 Long Name："NOx"
|
||
|
||
作为 long name 定义的例外，对于常用术语和众所周知的缩略语（主要是受 TR_SWNR_00017 约束的关键字集），关键字的 long name 可以完全用大写字母表示。
|
||
|
||
| 关键字 | 关键字缩写 | 定义（英文） |
|
||
|--------|-----------|--------------|
|
||
| Engine | Eng | Engine |
|
||
| ABS | Abs | Antilock Braking System |
|
||
|
||
**表 1：常用关键字缩略语示例**
|
||
|
||
#### [TR_SWNR_00058] 可读和可理解名称的语义规则
|
||
|
||
⌈ 为了构建可读和可理解的名称，关键字应根据语义规则进行排列。此类规则定义了**必须按定义顺序使用**的**语义字段**：
|
||
|
||
| 序列 | 语义字段名 | 描述 | 规则和示例 |
|
||
|------|-----------|------|------------|
|
||
| 1 | Mean-Environment-Device | 物理环境。定义 Action-PhysicalType 的主体元素。 | 应是名词。也可以是复合定义。缩写或首字母缩略词不能以数字结尾。<br>Mean 的示例：Fuel<br>Environment 的示例：Air、Ambient<br>Device 的示例：Accelerator、AcceleratorPedal、Engine |
|
||
| 2 | Action-PhysicalType | 动作或物理类型，调节或修改 Mean-Environment-Device。 | Action 应是动词。Physical Type 应是名词。也可以是复合。缩写或首字母缩略词不能以数字结尾。<br>Action 的示例：Move、Pull、Release、Lock、OpenClose、ShiftUp<br>Physical Type 的示例：Temperature、Speed |
|
||
| 3 | Condition-Qualifier | 在数据流、事件发出或表达信号在数值处理、时间有效性、精度、质量、位置方面的特定条件方面限定 Mean-Environment-Device 或 Action-PhysicalType。 | 应是名词或形容词。也可以是复合定义。缩写或首字母缩略词不能以数字结尾。<br>Condition 的示例：Absolute、Old、New、AbsoluteEstimated<br>Qualifier 的示例：Request、Command、Status |
|
||
| 4 | Index | 将信号标识为逻辑结构化信息的一部分。可用于标识元素的多个实例（索引）或信息的部分。 | 应是数字、单个字符或描述部分的形容词。使用时，它始终是序列中的最后一个关键字：<br>Index 的示例：`BrakeSwitch1` |
|
||
| 5 | Preposition | 用于连接/分隔由多个语义字段组成的复杂命名模式 | 示例：<br>`EngSpdAndPosn`<br>`CoolgReqFromSteer`<br>`TqActAtClu` |
|
||
|
||
**表 2：字段**
|
||
|
||
所有预定义的关键字及其相应的关键字缩略语都根据语义字段进行分类。这是使用 classification 属性指定的。 ⌋ (`RS_SWMG_00012`、`RS_SWMG_00016`、`RS_SWMG_00054`)
|
||
|
||
语义字段按 Sequence 列编号连接：
|
||
|
||
```
|
||
Mean-Environment-DeviceAction-PhysicalTypeCondition-QualifierIndex
|
||
```
|
||
|
||
此序列称为 **FieldBlock**。
|
||
|
||
#### [TR_SWNR_00019] 语义字段不是强制性的
|
||
|
||
⌈ **没有任何语义字段是强制性的**，并且语义字段可以重复，即名称可以使用任意数量的语义字段构建。 ⌋ (`RS_SWMG_00012`、`RS_SWMG_00016`、`RS_SWMG_00054`)
|
||
|
||
#### [TR_SWNR_00020] 索引以数字开头
|
||
|
||
⌈ **只有归类为 Index 的关键字应以数字开头**。使用时，Index 字段始终是字段块中的最后一个。 ⌋ (`RS_SWMG_00012`、`RS_SWMG_00054`)
|
||
|
||
以下是有效的 short names 示例：
|
||
|
||
- `GearAct`
|
||
- `MirrMoveCmd`
|
||
- `EngSpd`
|
||
- `EngSpdMax`
|
||
|
||
**建议**：如果一个语义字段包含多个关键字，则它们必须以自然英语顺序排列或最重要的关键字放在最前面。
|
||
|
||
**示例**：
|
||
|
||
- `BrakePedalStatus`（推荐）
|
||
- `PedalBrake`（不推荐，因为 "brake pedal" 是一个非常知名的英语术语）
|
||
|
||
其他不是所有语义字段都存在的复合定义示例：
|
||
|
||
- `BrkPedlSwt1`
|
||
- `VehBodyAVertBasMeasd`
|
||
- `OpenClsReq`
|
||
- `AcvDamprSt`
|
||
|
||
为了提高名称的可读性，标准化的关键字列表中提供了一系列预定义的介词。
|
||
|
||
#### [TR_SWNR_00034] 任意数量的字段块
|
||
|
||
⌈ **可以连接任意数量的字段块**。 ⌋ (`RS_SWMG_00012`、`RS_SWMG_00054`)
|
||
|
||
但是，字段块的数量应受到限制。**鼓励通过添加适当的介词来分隔每个字段块**。这导致以下命名模式：
|
||
|
||
```
|
||
Mean-Environment-DeviceAction-PhysicalTypeCondition-QualifierIndex
|
||
Preposition Mean-Environment-DeviceAction-PhysicalTypeCondition-QualifierIndex
|
||
Preposition …
|
||
```
|
||
|
||
由介词分隔的名称部分称为 **FieldBlocks**：
|
||
|
||
```
|
||
FieldBlock1 Preposition1 FieldBlock2 Preposition2 … FieldBlockN
|
||
```
|
||
|
||
以下示例显示了介词的用法：
|
||
|
||
- `EngSpdAtGearTar`
|
||
|
||
**强烈建议每个 FieldBlock 具有独立于其他 FieldBlocks 的含义**。
|
||
|
||
**示例**：
|
||
|
||
描述为 "Generic interface for total powertrain torque at wheels" 的接口不能表示为 "PtTqAtWhlsTot"。FieldBlock "WhlsTot" 没有预期的含义，因为 "Tot" 与 "Tq" 相关。因此，合规的解决方案之一是名称为 "PtTqTotAtWhls"。
|
||
|
||
#### [TR_SWNR_00050] 使用介词时 FieldBlocks 的顺序
|
||
|
||
⌈ 如果使用一个或多个介词来构建 short name，则**最重要的元素必须位于 FieldBlock1 中**。后面的 FieldBlocks 是对前面提到的 FieldBlock 的细化。 ⌋ (`RS_SWMG_00012`、`RS_SWMG_00054`、`RS_SWMG_00062`)
|
||
|
||
TR_SWNR_00050 确保名称以最重要的信息开头，以非常特殊的细节结尾。
|
||
|
||
**示例**：
|
||
|
||
以下接口描述："如果同时踩下加速器和制动踏板并且发生不合理性，则驾驶员请求扭矩限制。" 将产生以下名称：`DrvrTqLimnReqForBrkAccrPedlImpy1`。整个接口描述了驾驶员扭矩限制请求。因此，`DrvrTqLimnReq` 是最重要的 FieldBlock。因此，它是第一个 FieldBlock。
|
||
|
||
以下示例显示了**不正确的名称**：
|
||
|
||
将 PortPrototype 命名为 `MaximumEngineSpeed` 会导致关键字序列错误：Condition-Qualifier 关键字不能在 Mean-Environment-Device 关键字之前。正确的序列是：`EngineSpeedMaximum`。
|
||
|
||
### 6.5 模型元素（Model Elements）
|
||
|
||
命名约定适用于元素的 `ShortName`（`SHORT-NAME`）属性。该元素必须是 `Identifiable` 的特化。这些元素通过其元模型名称引用。括号中的名称是 XML 元素名称。
|
||
|
||
为了制定合理的命名约定，首先描述每个约定的目标。
|
||
|
||
#### 6.5.1 ARPackage (AR-PACKAGE)
|
||
|
||
`ARPackage` 创建一个**命名空间**。在一个系统包中，名称必须是唯一的。包可以有子包。
|
||
|
||
为标准化包结构定义了以下规则：
|
||
|
||
- **[TR_SWNR_00022] ARPackage AUTOSAR** ⌈ 根据 [7] 第 3 章，在根之下应放置一个具有 `LongName` `AUTOSAR` 和 `ShortName` `AUTOSAR` 的 ARPackage。顶级包 `AUTOSAR` 内的所有内容均由 AUTOSAR 合作伙伴发布（参见需求 `RS_SWMG_00001`、`RS_SWMG_00056`）。顶级包 `LongName` 和 `ShortName` `AUTOSAR` 由 AUTOSAR 合作伙伴保留，不应在其他地方使用。 ⌋ (`RS_SWMG_00001`、`RS_SWMG_00054`、`RS_SWMG_00056`)
|
||
- **[TR_SWNR_00023] 包含在 ARPackage AUTOSAR 中的包** ⌈ 在此 ARPackage "AUTOSAR" 内包含以下包（ShortNames）：`AISpecification`、`ApplicationDataTypes_Blueprint`、`CompuMethods_Blueprint`、`DataConstrs_Blueprint`、`PortInterfaces_Blueprint`、`PortPrototypeBlueprints_Blueprint`、`Collections_Blueprint`、`KeywordSets_Blueprint`、`ApplicationDataTypes_Example`、`BlueprintMappingSets_Example`、`CompuMethods_Example`、`DataConstrs_Example`、`PortInterfaces_Example`、`SwComponentTypes_Example`、`PhysicalDimensions`、`Units`、`LifeCycleInfoSets`、`Systems`。 ⌋ (`RS_SWMG_00001`、`RS_SWMG_00054`)
|
||
|
||
这些规则定义了 M2 [1] 建模层定义元素的标准化包结构。根据需求 `RS_SWMG_00056`，AUTOSAR 包是保留的命名空间。
|
||
|
||
#### [TR_SWMG_00018] 名称标准化策略
|
||
|
||
⌈ **只有 AUTOSAR 合作伙伴定义的元素才应添加到此命名空间**。这些元素不应被修改（参见 [7]）。 ⌋ (`RS_SWMG_00001`、`RS_SWMG_00049`)
|
||
|
||
> *有关命名空间概念的描述，请参见 [4]。*
|
||
|
||
> **图 6：AUTOSAR 包结构**
|
||
|
||
作为建议，**非标准化** AUTOSAR 包的名称应遵循 6.4.1 节中定义的一般规则。
|
||
|
||
ARPackage AUTOSAR 没有类别，而其子包有类别。子包的类别设置如下：
|
||
|
||
| ARPackage | 类别 |
|
||
|-----------|------|
|
||
| PhysicalDimensions | STANDARD |
|
||
| Units | STANDARD |
|
||
| LifeCycleInfoSets | STANDARD |
|
||
| DataConstrs_Blueprint | BLUEPRINT |
|
||
| ApplicationDataTypes_Blueprint | BLUEPRINT |
|
||
| CompuMethods_Blueprint | BLUEPRINT |
|
||
| PortInterfaces_Blueprint | BLUEPRINT |
|
||
| PortPrototypeBlueprints_Blueprint | BLUEPRINT |
|
||
| KeywordSets_Blueprint | BLUEPRINT |
|
||
| Collections_Blueprint | BLUEPRINT |
|
||
| ApplicationDataTypes_Example | EXAMPLE |
|
||
| BlueprintMappingSets_Example | EXAMPLE |
|
||
| CompuMethods_Example | EXAMPLE |
|
||
| PortInterfaces_Example | EXAMPLE |
|
||
| SwComponentTypes_Example | EXAMPLE |
|
||
| DataConstrs_Example | EXAMPLE |
|
||
| Systems | EXAMPLE |
|
||
|
||
**表 3：ARPackages 的类别**
|
||
|
||
#### 6.5.2 SenderReceiverInterface (SENDER-RECEIVER-INTERFACE)
|
||
|
||
#### [TR_SWNR_00051] Sender-Receiver 接口名称中序列号的使用
|
||
|
||
⌈ **接口名称应以序列号结尾**以考虑接口的未来演进。 ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
|
||
接口的规则 TR_SWNR_00051 与数据类型的 TR_SWNR_00044 类似。
|
||
|
||
**示例**：
|
||
|
||
```xml
|
||
<SENDER-RECEIVER-INTERFACE>
|
||
<SHORT-NAME NAME-PATTERN="{anyName}">BattU1</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">Battery Voltage</L-4></LONG-NAME>
|
||
<DESC><L-2 L="EN">This interface provides the actual voltage level as measured at the
|
||
battery.</L-2></DESC>
|
||
<IS-SERVICE>false</IS-SERVICE>
|
||
<DATA-ELEMENTS>
|
||
<VARIABLE-DATA-PROTOTYPE>
|
||
<SHORT-NAME NAME-PATTERN="{anyName}">BattU</SHORT-NAME>
|
||
<TYPE-TREF DEST="APPLICATION-PRIMITIVE-DATA-TYPE"
|
||
BASE="ApplicationDataTypes">U1</TYPE-TREF>
|
||
</VARIABLE-DATA-PROTOTYPE>
|
||
</DATA-ELEMENTS>
|
||
</SENDER-RECEIVER-INTERFACE>
|
||
```
|
||
|
||
**建议**：
|
||
|
||
`SenderReceiverInterface` 应是可重用元素。该名称应独立于组件和端口的具体用途，并且应仅反映其一般用途。
|
||
|
||
为了允许重用，通信路径（使用接口的端口的源或目标的指示）**不应**编码在接口名称中。
|
||
|
||
以下是接口名称的**不良示例**：
|
||
|
||
- `YawRateStdByEsc`
|
||
- `YawRateStdBySecCtrlrYawRate`
|
||
|
||
此示例中的接口名称应为 "YawRate1"，并由两个端口重用，其名称可以是 "YawRateStdByEsc" 和 "YawRateStdBySecCtrlrYawRate"。
|
||
|
||
#### 6.5.3 VariableDataPrototype (VARIABLE-DATA-PROTOTYPE)
|
||
|
||
**目标**：
|
||
|
||
- 应仅相对于 `SenderReceiverInterface` 有意义。
|
||
- 每个 `SenderReceiverInterface` 应是唯一名称。
|
||
|
||
**规则**：
|
||
|
||
- **[TR_SWNR_00026] 反映数据内容的名称** ⌈ 名称应反映数据的内容。如果找不到数据元素的合理名称，并且接口用于指示数据传输，**建议使用名称 Val**（Value 的缩写）。 ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
|
||
**示例**：
|
||
|
||
```xml
|
||
<VARIABLE-DATA-PROTOTYPE>
|
||
<SHORT-NAME NAME-PATTERN="{anyName}">Val</SHORT-NAME>
|
||
<TYPE-TREF DEST="APPLICATION-PRIMITIVE-DATA-TYPE"
|
||
BASE="ApplicationDataTypes">T1</TYPE-TREF>
|
||
</VARIABLE-DATA-PROTOTYPE>
|
||
```
|
||
|
||
- **[TR_SWNR_00027] 反映操作的名称** ⌈ 如果数据元素原型不包含值信息，而是包含操作，则名称应反映由数据元素原型驱动的操作。 ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
|
||
**示例**：`Cls`（Close 的缩写）。
|
||
|
||
如果找不到数据元素原型的合理名称，并且接口用于指示操作，**应使用名称 Oper**（Operation 的缩写）。
|
||
|
||
- **[TR_SWNR_00029] 表示相同操作的多个数据** ⌈ 如果 `SenderReceiverInterface` 包含多个表示相同操作的数据元素原型，则**必须使用 "Mean-Environment-Device" 关键字来区分这些操作**。（这里的"操作"不是用于指代 `ClientServerInterface` 操作意义上的操作，而是指由 SenderReceiver 通信触发的操作或动作。"操作"也不等同于 "Action" 语义字段。） ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
|
||
**示例**：
|
||
|
||
- UserTransmit → `UsrTx`
|
||
- TelegramTransmit → `TelgrmTx`
|
||
- ExteriorLightDisplay → `ExtrLiDisp`
|
||
- ParkingLightDisplay → `PrkgLiDisp`
|
||
|
||
**备注**：在最后两个示例中，所有关键字都归类为 "Mean-Environment-Device"，因此它们可以按任何顺序排列。
|
||
|
||
**建议**：
|
||
|
||
- 在数据元素的名称中**重复**封闭接口的名称是允许的，但**不建议**。重复名称会导致冗余信息，并会对 RTE 生成的函数名称产生负面影响（有关接口名称和数据元素名称之间信息分布的示例，请参见 6.3.3 节）。
|
||
|
||
#### 6.5.4 ApplicationDataType
|
||
|
||
以下类是 AUTOSAR 元模型中 `ApplicationDataType` 类的子类。因此，命名约定也适用于这些类：
|
||
|
||
- `ApplicationPrimitiveDataType` (`APPLICATION-PRIMITIVE-DATA-TYPE`)
|
||
- `ApplicationRecordDataType` (`APPLICATION-RECORD-DATA-TYPE`)
|
||
- `ApplicationArrayDataType` (`APPLICATION-ARRAY-DATA-TYPE`)
|
||
|
||
**规则**：
|
||
|
||
- **[TR_SWNR_00056] 名称应反映类型的含义** ⌈ 名称应反映类型的含义。 ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
- **[TR_SWNR_00057] 不允许使用前缀** ⌈ **不应**在类型名称中使用前缀，例如 "t_"。 ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
- **[TR_SWNR_00055] 名称中不允许包含数组长度信息** ⌈ **不应**在 `ApplicationArrayDataType` 名称中使用数字来指定其长度。 ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
- **[TR_SWNR_00044] 数据类型名称中序列号的使用** ⌈ **数据类型名称应以序列号结尾**以考虑未来的演进。此规则还应用于区分表示相同物理实体但具有不同范围或分辨率的数据类型，即此类数据类型的名称应仅在序列号上不同。 ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
|
||
**示例**：
|
||
|
||
- `Temperature1` → `T1`
|
||
- `Temperature2` → `T2`
|
||
- `Temperature3` → `T3`
|
||
|
||
规则 TR_SWNR_00044 确保了数据类型的可重用性。
|
||
|
||
- **[TR_SWNR_00048] 名称中不包含通信信息** ⌈ 为了允许重用，**通信路径不应编码在数据类型名称中**。 ⌋ (`RS_SWMG_00031`、`RS_SWMG_00054`)
|
||
|
||
**示例 XML**：
|
||
|
||
```xml
|
||
<APPLICATION-PRIMITIVE-DATA-TYPE>
|
||
<SHORT-NAME NAME-PATTERN="{anyName}">U1</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">Voltage 1</L-4></LONG-NAME>
|
||
<DESC><L-2 L="EN">Generic data type for voltage</L-2></DESC>
|
||
<CATEGORY>VALUE</CATEGORY>
|
||
<SW-DATA-DEF-PROPS>
|
||
<SW-DATA-DEF-PROPS-VARIANTS>
|
||
<SW-DATA-DEF-PROPS-CONDITIONAL>
|
||
<SW-CALIBRATION-ACCESS>READ-ONLY</SW-CALIBRATION-ACCESS>
|
||
<COMPU-METHOD-REF DEST="COMPU-METHOD" BASE="CompuMethods">U1</COMPU-METHOD-REF>
|
||
<DATA-CONSTR-REF DEST="DATA-CONSTR" BASE="DataConstrs">U1</DATA-CONSTR-REF>
|
||
<SW-INTENDED-RESOLUTION>0.1</SW-INTENDED-RESOLUTION>
|
||
<UNIT-REF DEST="UNIT" BASE="Units">Volt</UNIT-REF>
|
||
</SW-DATA-DEF-PROPS-CONDITIONAL>
|
||
</SW-DATA-DEF-PROPS-VARIANTS>
|
||
</SW-DATA-DEF-PROPS>
|
||
</APPLICATION-PRIMITIVE-DATA-TYPE>
|
||
```
|
||
|
||
#### 6.5.5 CompuMethod (COMPU-METHOD)
|
||
|
||
`COMPU-METHOD` shortnames 元素遵循命名约定规则。
|
||
|
||
应遵循特定名称模式以区分特殊用例：
|
||
|
||
- **[TR_SWNR_00069] 每个 Unit 的类别 IDENTICAL 通用 CompuMethod** ⌈ 类别 IDENTICAL 的每个 Unit 的通用 CompuMethod 应遵循以下模式：
|
||
|
||
```
|
||
{shortName of Unit}Identcl （强制性）
|
||
```
|
||
|
||
⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
|
||
- **[TR_SWNR_00070] 每个 Unit 的类别 LINEAR 通用 CompuMethod** ⌈ 类别 LINEAR 的每个 Unit 的通用 CompuMethod（支持为特定分辨率重用 CompuMethods）应遵循以下模式：
|
||
|
||
```
|
||
{shortName of Unit}Lnr{sequence number}
|
||
（4.2.1 版本之后新建 compuMethod 强制性）
|
||
```
|
||
|
||
⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
|
||
- **[TR_SWNR_00071] 类别 TEXTTABLE 通用 CompuMethod** ⌈ 类别 TEXTTABLE 的通用 CompuMethod（通常用于枚举类型）应遵循以下模式：
|
||
|
||
```
|
||
{shortName of the corresponding ApplicationDataType} （强制性）
|
||
```
|
||
|
||
⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
|
||
**示例**：
|
||
|
||
1) **IDENTICAL CompuMethod**（适用于 float 实现，不需要 compu 比例）
|
||
|
||
```xml
|
||
<COMPU-METHOD>
|
||
<SHORT-NAME NAME-PATTERN="{anyName}">KelvinIdentcl</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">Kelvin Identical</L-4></LONG-NAME>
|
||
<CATEGORY>IDENTICAL</CATEGORY>
|
||
<UNIT-REF BASE="Units" DEST="UNIT">Kelvin</UNIT-REF>
|
||
</COMPU-METHOD>
|
||
```
|
||
|
||
2) **LINEAR CompuMethod**
|
||
|
||
```xml
|
||
<COMPU-METHOD>
|
||
<SHORT-NAME NAME-PATTERN="{anyName}">VoltLnr1</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">Voltage 1</L-4></LONG-NAME>
|
||
<DESC><L-2 L="EN">Generic data type for voltage</L-2></DESC>
|
||
<CATEGORY>LINEAR</CATEGORY>
|
||
<UNIT-REF BASE="Units" DEST="UNIT">Volt</UNIT-REF>
|
||
<COMPU-PHYS-TO-INTERNAL>
|
||
<COMPU-SCALES>
|
||
<COMPU-SCALE>
|
||
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">0</LOWER-LIMIT>
|
||
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">25.2</UPPER-LIMIT>
|
||
<COMPU-RATIONAL-COEFFS>
|
||
<COMPU-NUMERATOR>
|
||
<V>0</V>
|
||
<V>1</V>
|
||
</COMPU-NUMERATOR>
|
||
<COMPU-DENOMINATOR>
|
||
<V>0.1</V>
|
||
</COMPU-DENOMINATOR>
|
||
</COMPU-RATIONAL-COEFFS>
|
||
</COMPU-SCALE>
|
||
</COMPU-SCALES>
|
||
</COMPU-PHYS-TO-INTERNAL>
|
||
</COMPU-METHOD>
|
||
```
|
||
|
||
3) **TEXTTABLE CompuMethod**（用于枚举数据类型）
|
||
|
||
```xml
|
||
<COMPU-METHOD>
|
||
<SHORT-NAME NAME-PATTERN="{anyName}">AckSt1</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">Acknowledge Status 1</L-4></LONG-NAME>
|
||
<CATEGORY>TEXTTABLE</CATEGORY>
|
||
<UNIT-REF BASE="Units" DEST="UNIT">NoUnit</UNIT-REF>
|
||
<COMPU-INTERNAL-TO-PHYS>
|
||
<COMPU-SCALES>
|
||
<COMPU-SCALE>
|
||
<DESC><L-2 L="EN">0 = NotAcpt (Request not accepted.)</L-2></DESC>
|
||
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">0</LOWER-LIMIT>
|
||
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">0</UPPER-LIMIT>
|
||
<COMPU-CONST>
|
||
<VT>NotAcpt</VT>
|
||
</COMPU-CONST>
|
||
</COMPU-SCALE>
|
||
<COMPU-SCALE>
|
||
<DESC><L-2 L="EN">1 = Acpt (Request accepted.)</L-2></DESC>
|
||
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">1</LOWER-LIMIT>
|
||
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">1</UPPER-LIMIT>
|
||
<COMPU-CONST>
|
||
<VT>Acpt</VT>
|
||
</COMPU-CONST>
|
||
</COMPU-SCALE>
|
||
</COMPU-SCALES>
|
||
</COMPU-INTERNAL-TO-PHYS>
|
||
</COMPU-METHOD>
|
||
```
|
||
|
||
#### 6.5.6 SwComponentType (COMPOSITION-SW-COMPONENT-TYPE)
|
||
|
||
命名约定适用于 `SwComponentType` 类的以下子类：
|
||
|
||
- `ApplicationSwComponentType`
|
||
- `CompositionSwComponentType`
|
||
- `SensorActuatorSwComponentType`
|
||
- `ParameterSwComponentType`
|
||
|
||
**目标**：
|
||
|
||
- 避免包内的名称冲突
|
||
- 组件的分类
|
||
- 不适用于组件原型（参见 6.5.7）
|
||
|
||
**规则**：
|
||
|
||
- **[TR_SWNR_00035] 不允许对 SwComponentTypes 使用特定于域的前缀** ⌈ **不允许**使用前缀来指示 `SwComponentType` 的应用域（例如动力总成、车身、底盘）。 ⌋ (`RS_SWMG_00031`、`RS_SWMG_00054`)
|
||
|
||
**建议**：
|
||
|
||
- 使用名词或名词的连接。
|
||
|
||
**示例**：
|
||
|
||
- `SensorSpeed` → `SnsrSpd`
|
||
- 名称应易于理解。
|
||
|
||
**示例**：
|
||
|
||
- `VehicleSpeed` → `VehSpd`
|
||
- `VehicleMotionDemand` → `VehMtnDmd`
|
||
- `WiperWasher` → `WiprWshr`
|
||
|
||
**示例**（为缩短示例，已删除某些行）：
|
||
|
||
```xml
|
||
<COMPOSITION-SW-COMPONENT-TYPE>
|
||
<SHORT-NAME>KeyPad</SHORT-NAME>
|
||
<PORTS>
|
||
<P-PORT-PROTOTYPE>
|
||
<SHORT-NAME>DrvrDoorKeyPad</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">Driver Door Keypad</L-4></LONG-NAME>
|
||
<DESC><L-2 L="EN">Request to activate central locking master from the driver
|
||
door key pad</L-2></DESC>
|
||
<PROVIDED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE"
|
||
BASE="PortInterfaces_Blueprint">LockgCenReq1</PROVIDED-INTERFACE-TREF>
|
||
</P-PORT-PROTOTYPE>
|
||
…some ports skipped
|
||
<P-PORT-PROTOTYPE>
|
||
<SHORT-NAME>KeyPadOfLidRe</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">Rear Lid Keypad</L-4></LONG-NAME>
|
||
<DESC><L-2 L="EN">Request to activate central locking master on the rear
|
||
lid from lid key pad</L-2></DESC>
|
||
<PROVIDED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE"
|
||
BASE="PortInterfaces_Blueprint">LockgCenReq1</PROVIDED-INTERFACE-TREF>
|
||
</P-PORT-PROTOTYPE>
|
||
</PORTS>
|
||
<COMPONENTS>
|
||
<SW-COMPONENT-PROTOTYPE>
|
||
<SHORT-NAME>KeyPadMgr</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">KeyPadManager</L-4></LONG-NAME>
|
||
<DESC><L-2 L="EN">Key Pad Manager</L-2></DESC>
|
||
<TYPE-TREF DEST="COMPOSITION-SW-COMPONENT-TYPE"
|
||
BASE="SwComponentTypes_Example">KeyPadMgr</TYPE-TREF>
|
||
</SW-COMPONENT-PROTOTYPE>
|
||
</COMPONENTS>
|
||
<CONNECTORS>
|
||
<DELEGATION-SW-CONNECTOR>
|
||
<SHORT-NAME>delcon_0</SHORT-NAME>
|
||
<INNER-PORT-IREF>
|
||
<P-PORT-IN-COMPOSITION-INSTANCE-REF>
|
||
<CONTEXT-COMPONENT-REF DEST="SW-COMPONENT-PROTOTYPE"
|
||
BASE="SwComponentTypes_Example">KeyPad/KeyPadMgr</CONTEXT-COMPONENT-REF>
|
||
<TARGET-P-PORT-REF DEST="P-PORT-PROTOTYPE"
|
||
BASE="SwComponentTypes_Example">KeyPadMgr/DrvrDoorKeyPad</TARGET-P-PORT-REF>
|
||
</P-PORT-IN-COMPOSITION-INSTANCE-REF>
|
||
</INNER-PORT-IREF>
|
||
<OUTER-PORT-REF DEST="P-PORT-PROTOTYPE"
|
||
BASE="SwComponentTypes_Example">KeyPad/DrvrDoorKeyPad</OUTER-PORT-REF>
|
||
</DELEGATION-SW-CONNECTOR>
|
||
….some delegation ports skipped
|
||
</CONNECTORS>
|
||
</COMPOSITION-SW-COMPONENT-TYPE>
|
||
```
|
||
|
||
> **图 7：SwComponentType 示例**
|
||
|
||
#### 6.5.7 System (SYSTEM)
|
||
|
||
即使不在本文档的范围内，了解 AUTOSAR 系统描述的顶级元素由 `System` 元素表示也很重要。System 描述定义了五个主要元素：Topology、Software、Communication、Mapping 和 Mapping、Constraints。
|
||
|
||
根据 [11] 和 [3]，在 AUTOSAR 中，软件组件可以是原子的，也可以由其他软件组件和 `CompositionSwComponentType` 组成。为了从 AUTOSAR 组件组装非平凡的应用，这些组合可以分层构建，直到最外层的 `CompositionSwComponentType` 形成一种顶级组合。
|
||
|
||
`System` 元素直接聚合根软件组合，以分层结构包含系统中的所有软件组件。当系统描述用于仅网络用例时，不需要此元素。
|
||
|
||
此外，出于本文档的目的，`System` 元素始终引用 SW 组合的最高级别，称为 **TopLv**（Top Level），并且可以仅建模一次。
|
||
|
||
```xml
|
||
<AR-PACKAGE>
|
||
<SHORT-NAME>Systems</SHORT-NAME>
|
||
<CATEGORY>EXAMPLE</CATEGORY>
|
||
<REFERENCE-BASES>
|
||
<REFERENCE-BASE>
|
||
<SHORT-LABEL>SwComponentTypes</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">/AUTOSAR/AISpecification/SwComponentTypes_Example</PACKAGE-REF>
|
||
</REFERENCE-BASE>
|
||
</REFERENCE-BASES>
|
||
<ELEMENTS>
|
||
<SYSTEM>
|
||
<SHORT-NAME>System</SHORT-NAME>
|
||
<CATEGORY>SYSTEM_DESCRIPTION</CATEGORY>
|
||
<ROOT-SOFTWARE-COMPOSITIONS>
|
||
<ROOT-SW-COMPOSITION-PROTOTYPE>
|
||
<SHORT-NAME>TopLvl</SHORT-NAME>
|
||
<SOFTWARE-COMPOSITION-TREF BASE="SwComponentTypes" DEST="COMPOSITION-SW-COMPONENT-
|
||
TYPE">TopLvl</SOFTWARE-COMPOSITION-TREF>
|
||
</ROOT-SW-COMPOSITION-PROTOTYPE>
|
||
</ROOT-SOFTWARE-COMPOSITIONS>
|
||
</SYSTEM>
|
||
</ELEMENTS>
|
||
</AR-PACKAGE>
|
||
```
|
||
|
||
#### 6.5.8 SwComponentPrototype (SW-COMPONENT-PROTOTYPE)
|
||
|
||
组件原型（每个组件类型的实例）的命名约定目标：
|
||
|
||
- 避免组合内的名称冲突
|
||
- 组件的分类
|
||
|
||
这些名称不用于 RTE 的 API 中。
|
||
|
||
**规则**：
|
||
|
||
- **[TR_SWNR_00036] 不允许对 SwComponentPrototypes 使用特定于域的前缀** ⌈ **不允许**使用前缀来指示 `SwComponentPrototype` 的应用域（例如动力总成、车身、底盘）。 ⌋ (`RS_SWMG_00031`、`RS_SWMG_00054`)
|
||
|
||
**建议**：
|
||
|
||
- 名称应易于理解。如果组合包含同一组件类型的多个实例，则原型名称应反映此特定实例在组合中的角色。有关如何命名多个 `SwComponentPrototypes` 的示例，请参见 5.2 节。
|
||
|
||
**示例**：`DoorLe`、`DoorRi`
|
||
|
||
**示例**：
|
||
|
||
```xml
|
||
<SW-COMPONENT-PROTOTYPE>
|
||
<SHORT-NAME>MgrOfMirrAdjAutReqByUsr</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">ManagerOfMirrorAdjustmentAutomaticRequestByUser</L-4></LONG-NAME>
|
||
<DESC><L-2 L="EN">Component treating the Automatic mirror movement
|
||
requests - memory recall. </L-2></DESC>
|
||
<TYPE-TREF DEST="COMPOSITION-SW-COMPONENT-TYPE"
|
||
BASE="SwComponentTypes">MgrOfMirrAdjAutReqByUsr</TYPE-TREF>
|
||
</SW-COMPONENT-PROTOTYPE>
|
||
```
|
||
|
||
#### 6.5.9 PortPrototype (P-PORT-PROTOTYPE, R-PORT-PROTOTYPE)
|
||
|
||
**目标**：
|
||
|
||
- 应仅相对于 SW 组件（例如左、右等）有意义
|
||
- 每个组件的唯一名称
|
||
|
||
只要 `PortPrototypes` 使用兼容的 `PortInterfaces` 进行类型化，它们就可以连接。有关此类兼容性规则，请参阅文档 [3]。
|
||
|
||
**示例**：
|
||
|
||
- Short-Name: `EmgyLockg`
|
||
|
||
```xml
|
||
<R-PORT-PROTOTYPE>
|
||
<SHORT-NAME>EmgyLockg</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">Emergency Locking</L-4></LONG-NAME>
|
||
<DESC><L-2 L="EN">User request for emergency locking in case of danger.</L-2></DESC>
|
||
<REQUIRED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE"
|
||
BASE="PortInterfaces">LockUnlckReq1</REQUIRED-INTERFACE-TREF>
|
||
</R-PORT-PROTOTYPE>
|
||
```
|
||
|
||
#### 6.5.10 Units (UNIT)
|
||
|
||
**目标**：
|
||
|
||
- 应是唯一的。
|
||
|
||
**规则**：
|
||
|
||
- **[TR_SWNR_00040] 包含 "x 的 2 次方" 的公式** ⌈ 如果 unit 是包含 "x 的 2 次方" 的公式，则 short name 应包含 "Sqd"（关键字 "Squared" 的缩写）。 ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
- **[TR_SWNR_00041] 包含 "x 的 3 次方" 的公式** ⌈ 如果 unit 是包含 "x 的 3 次方" 的公式，则 short name 应包含 "Cubd"（关键字 "Cubed" 的缩写）。 ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
- **[TR_SWNR_00042] 包含 "x 的幂大于 3" 的公式** ⌈ 如果 unit 是包含 "x 的 number > 3 次方" 的公式，则 short name 应包含 `ToPwrOf<number>`。 ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
- **[TR_SWNR_00043] 包含除法的公式** ⌈ 如果 unit 是包含除法的公式，则 short name 应包含 "Per" ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
- **[TR_SWNR_00073] Display Names 中的特殊字符** ⌈ 要在 Units 的 Display names 中描述公式表达式，**应使用以下特殊字符列表**：
|
||
|
||
| 运算 | 字符 |
|
||
|------|------|
|
||
| 乘法（multiplication） | `*` |
|
||
| 除法（division） | `/` |
|
||
| 平方（square） | `^2` |
|
||
| 立方（cubic） | `^3` |
|
||
| 平方根（square root） | `^(1/2)` |
|
||
| 立方根（cubic root） | `^(1/3)` |
|
||
| x 次方根（x root） | `^(1/x)` |
|
||
| y/x 次方根（y/x root） | `^(y/x)` |
|
||
| 微（Micro） | `µ` |
|
||
| 百分比（Percent） | `%` |
|
||
| 千分比（Per mil） | `‰` |
|
||
| 欧姆（Ohm） | `Ω` |
|
||
| 无单位（No unit） | `-` |
|
||
| 左括号（Opening Bracket） | `(` |
|
||
| 右括号（Closing Bracket） | `)` |
|
||
|
||
⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
|
||
- **建议**：建议在 Units 的 Display Names 中以特定顺序使用括号以清楚地标识物理含义。
|
||
|
||
**示例**：建议不要写 `J/Kg*K`，而应写 `(J/Kg)*K` 或 `(J*K)/Kg`，基于物理含义。
|
||
|
||
**示例**：
|
||
|
||
```xml
|
||
<UNIT>
|
||
<SHORT-NAME>NwtPerMtr</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">Newton Per Meter</L-4></LONG-NAME>
|
||
<DESC><L-2 L="EN">surface tension (derived from SI units)</L-2></DESC>
|
||
<DISPLAY-NAME>N/m</DISPLAY-NAME>
|
||
<FACTOR-SI-TO-UNIT>1</FACTOR-SI-TO-UNIT>
|
||
<PHYSICAL-DIMENSION-REF DEST="PHYSICAL-DIMENSION"
|
||
BASE="PhysicalDimensions">M1TiNeg2</PHYSICAL-DIMENSION-REF>
|
||
</UNIT>
|
||
```
|
||
|
||
```xml
|
||
<UNIT>
|
||
<SHORT-NAME>MtrPerSecCubd</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">Meter Per Second Cubed</L-4></LONG-NAME>
|
||
<DESC><L-2 L="EN">jerk (derived from SI units), also called jolt (esp. in British
|
||
English), surge or lurch, is the rate of change of acceleration; more precisely, the
|
||
derivative of acceleration with respect to time, the second derivative of velocity, or the
|
||
third derivative of displacement.</L-2></DESC>
|
||
<DISPLAY-NAME>m/s^3</DISPLAY-NAME>
|
||
<FACTOR-SI-TO-UNIT>1</FACTOR-SI-TO-UNIT>
|
||
<PHYSICAL-DIMENSION-REF DEST="PHYSICAL-DIMENSION"
|
||
BASE="PhysicalDimensions">Len1TiNeg3</PHYSICAL-DIMENSION-REF>
|
||
</UNIT>
|
||
```
|
||
|
||
#### 6.5.11 Physical Dimensions
|
||
|
||
Physical Dimensions 用于完全描述和分类 Units 包中的元素。每个 unit 的物理维度表示为 7 个基本物理量的通用组合：电流、发光强度、时间、质量、物质的量、热力学温度、长度，具有特定的指数。
|
||
|
||
Physical Dimension 的 short name 由表达七个基本物理量及其相应指数的关键字序列构建。指数等于 0 的物理量在 Physical Dimension 的 short name 中不提及。在某些必须保证唯一性的特定情况下，可以使用特定的索引。
|
||
|
||
应使用以下语法：
|
||
|
||
#### [TR_SWNR_00072] Physical Dimensions 的 Long name 和 short name
|
||
|
||
⌈ 应使用以下语法：
|
||
|
||
```
|
||
ShortNamePhysDimension : ({Dim}* | NoDimension)(_{Index})
|
||
|
||
Dim :: {PhysDim}(Neg){Number}
|
||
|
||
PhysDim :: Len | M | Ti | I | T | Amnt | Lumi
|
||
|
||
Index: 1, 2, 3, 4, 5, 6, 7, …
|
||
```
|
||
|
||
**示例**：
|
||
|
||
- 示例 1：现有的 "Len1TiNeg1" 保持不变，然后可以根据需要创建 "Len1TiNeg1_1"。
|
||
- 示例 2："Len2M1TiNeg2" 表示扭矩，"Len2M1TiNeg2_1" 表示能量。
|
||
|
||
Long names 应描述物理含义。 ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
|
||
**示例 1**：Unit: Nm
|
||
|
||
- shortname: `"Len2M1TiNeg2"` 表示扭矩
|
||
- longname: `Torque`
|
||
|
||
```xml
|
||
<PHYSICAL-DIMENSION>
|
||
<SHORT-NAME>Len2M1TiNeg2</SHORT-NAME>
|
||
<LONG-NAME>
|
||
<L-4 L="EN">Torque</L-4>
|
||
</LONG-NAME>
|
||
<LENGTH-EXP>2</LENGTH-EXP>
|
||
<MASS-EXP>1</MASS-EXP>
|
||
<TIME-EXP>-2</TIME-EXP>
|
||
</PHYSICAL-DIMENSION>
|
||
```
|
||
|
||
**示例 2**：Unit: Joule
|
||
|
||
- shortname: `"Len2M1TiNeg2_1"` 表示能量
|
||
- longname: `Energy`
|
||
|
||
```xml
|
||
<PHYSICAL-DIMENSION>
|
||
<SHORT-NAME>Len2M1TiNeg2_1</SHORT-NAME>
|
||
<LONG-NAME>
|
||
<L-4 L="EN">Energy</L-4>
|
||
</LONG-NAME>
|
||
<LENGTH-EXP>2</LENGTH-EXP>
|
||
<MASS-EXP>1</MASS-EXP>
|
||
<TIME-EXP>-2</TIME-EXP>
|
||
</PHYSICAL-DIMENSION>
|
||
```
|
||
|
||
#### 6.5.12 枚举（Enumerations）
|
||
|
||
元模型中没有对枚举类型的显式支持。枚举通过使用 DataType 和 CompuMethod 进行建模。
|
||
|
||
**示例**：
|
||
|
||
```xml
|
||
<APPLICATION-PRIMITIVE-DATA-TYPE>
|
||
<SHORT-NAME NAME-PATTERN="{anyName}">UsrReqForWipg1</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">User Request For Wiping</L-4></LONG-NAME>
|
||
<DESC><L-2 L="EN">It represents the selection of the interval time or the speed of the
|
||
wiper requested by the user. The exact timings and wipe speeds are not standardized and need
|
||
therefore to be parameterized.</L-2></DESC>
|
||
<CATEGORY>VALUE</CATEGORY>
|
||
<SW-DATA-DEF-PROPS>
|
||
<SW-DATA-DEF-PROPS-VARIANTS>
|
||
<SW-DATA-DEF-PROPS-CONDITIONAL>
|
||
<SW-CALIBRATION-ACCESS>READ-ONLY</SW-CALIBRATION-ACCESS>
|
||
<COMPU-METHOD-REF DEST="COMPU-METHOD" BASE="CompuMethods">UsrReqForWipg1</COMPU-
|
||
METHOD-REF>
|
||
<DATA-CONSTR-REF DEST="DATA-CONSTR" BASE="DataConstrs">UsrReqForWipg1</DATA-CONSTR-
|
||
REF>
|
||
</SW-DATA-DEF-PROPS-CONDITIONAL>
|
||
</SW-DATA-DEF-PROPS-VARIANTS>
|
||
</SW-DATA-DEF-PROPS>
|
||
</APPLICATION-PRIMITIVE-DATA-TYPE>
|
||
```
|
||
|
||
```xml
|
||
<COMPU-METHOD>
|
||
<SHORT-NAME NAME-PATTERN="{anyName}">UsrReqForWipg1</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">User Request For Wiping</L-4></LONG-NAME>
|
||
<CATEGORY>TEXTTABLE</CATEGORY>
|
||
<COMPU-INTERNAL-TO-PHYS>
|
||
<COMPU-SCALES>
|
||
<COMPU-SCALE>
|
||
<DESC><L-2 L="EN">4 = UsrReqForWipgSpdHi</L-2></DESC>
|
||
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">4</LOWER-LIMIT>
|
||
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">4</UPPER-LIMIT>
|
||
<COMPU-CONST><VT>UsrReqForWipgSpdHi</VT></COMPU-CONST>
|
||
</COMPU-SCALE>
|
||
<COMPU-SCALE>
|
||
<DESC><L-2 L="EN">2 = UsrReqForWipgIntl</L-2></DESC>
|
||
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">2</LOWER-LIMIT>
|
||
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">2</UPPER-LIMIT>
|
||
<COMPU-CONST><VT>UsrReqForWipgIntl</VT></COMPU-CONST>
|
||
</COMPU-SCALE>
|
||
<COMPU-SCALE>
|
||
<DESC><L-2 L="EN">3 = UsrReqForWipgSpdLo</L-2></DESC>
|
||
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">3</LOWER-LIMIT>
|
||
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">3</UPPER-LIMIT>
|
||
<COMPU-CONST><VT>UsrReqForWipgSpdLo</VT></COMPU-CONST>
|
||
</COMPU-SCALE>
|
||
<COMPU-SCALE>
|
||
<DESC><L-2 L="EN">0 = UsrReqForWipgOff</L-2></DESC>
|
||
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">0</LOWER-LIMIT>
|
||
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">0</UPPER-LIMIT>
|
||
<COMPU-CONST><VT>UsrReqForWipgOff</VT></COMPU-CONST>
|
||
</COMPU-SCALE>
|
||
<COMPU-SCALE>
|
||
<DESC><L-2 L="EN">1 = WipgStrikeSngReqByUsr</L-2></DESC>
|
||
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">1</LOWER-LIMIT>
|
||
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">1</UPPER-LIMIT>
|
||
<COMPU-CONST><VT>WipgStrikeSngReqByUsr</VT></COMPU-CONST>
|
||
</COMPU-SCALE>
|
||
</COMPU-SCALES>
|
||
</COMPU-INTERNAL-TO-PHYS>
|
||
</COMPU-METHOD>
|
||
```
|
||
|
||
在 Application Domain（但不限于此）中，一个常见用例是通过存在共享相同枚举标签但具有不同值的两个或多个枚举数据类型来表示：
|
||
|
||
例如：
|
||
|
||
- 枚举数据类型 `CluSt1` 定义 `Opend = 0`
|
||
- 枚举数据类型 `LockSt2` 定义 `Opend = 1`
|
||
|
||
为了允许定义共享相同枚举标签但具有不同点范围的不同枚举数据类型，RTE 层提供了一种特定机制来解决否则会出现的配置错误。
|
||
|
||
这也是处理由基础软件模块提供的枚举常量的必要条件，这些模块都使用自己的前缀约定。此类枚举常量名称在整个 AUTOSAR 系统中必须是唯一的。
|
||
|
||
跳过 RTE 层的实现细节（请参见 [2]），可以概括为在生成最终代码之前，RTE 会结合一些来自用于枚举数据类型定义的 CompuMethod 的特定信息和由每个 SW-C 声明使用的数据集派生的其他特定信息。所有这些信息保证了软件架构中枚举标签的唯一性。如果 RTE 所需的信息集不完整，RTE 生成器应将此输入作为无效配置拒绝。
|
||
|
||
#### 6.5.13 ClientServerInterface (CLIENT-SERVER-INTERFACE)
|
||
|
||
在建模 `ClientServerInterface` 时，还应为以下属性定义名称：
|
||
|
||
- `OperationPrototype`
|
||
- `ArgumentPrototype`
|
||
|
||
**规则**：
|
||
|
||
- **[TR_SWNR_00062] Client-Server 接口名称中序列号的使用** ⌈ **接口名称应以序列号结尾**以考虑接口的未来演进。 ⌋ (`RS_SWMG_00010`、`RS_SWMG_00054`)
|
||
- `OperationPrototype` 属性的名称应遵循适用于 `VariableDataPrototype` 的 TR_SWNR_00029 规则（参见 6.5.3）
|
||
- `ArgumentPrototype` 属性的名称应遵循适用于 `VariableDataPrototype` 的所有规则（参见 6.5.3）
|
||
|
||
**建议**：
|
||
|
||
- `ClientServerInterface` 应是可重用元素。接口的名称应独立于组件和端口的具体用途，并且应仅反映其一般用途。
|
||
- 为了允许重用，通信路径（使用接口的端口的源或目标的指示）**不应**编码在接口名称中。
|
||
- `ArgumentPrototype` 属性的名称应遵循适用于 `VariableDataPrototype` 的所有建议（参见 6.5.3）
|
||
- `OperationPrototype` 属性的名称**应以归类为 "Action / Physical Type" 的关键字开头**
|
||
|
||
**OperationPrototype 示例**：
|
||
|
||
- Short-Name: `SetEveSt`
|
||
|
||
#### 6.5.14 ParameterInterface (PARAMETER-INTERFACE)
|
||
|
||
对于此模型元素，适用于 `SenderReceiverInterface`（参见第 6.5.2 节）的相同规则和建议。
|
||
|
||
#### 6.5.15 ParameterDataPrototype (PARAMETER-DATA-PROTOTYPE)
|
||
|
||
**目标**：
|
||
|
||
- 应仅相对于 `ParameterInterface` 有意义。
|
||
- 每个 `ParameterInterface` 应是唯一名称。
|
||
|
||
对于此模型元素，适用于 `VariableDataPrototype`（参见第 6.5.3 节）的相同规则和建议。
|
||
|
||
#### 6.5.16 DataConstrs (DATA-CONSTRS)
|
||
|
||
`DATA-CONSTRS` shortname 元素遵循命名约定规则。
|
||
|
||
**示例**：
|
||
|
||
```xml
|
||
<DATA-CONSTR>
|
||
<SHORT-NAME NAME-PATTERN="{anyName}">Flg1</SHORT-NAME>
|
||
<DATA-CONSTR-RULES>
|
||
<DATA-CONSTR-RULE>
|
||
<INTERNAL-CONSTRS>
|
||
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">0</LOWER-LIMIT>
|
||
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">1</UPPER-LIMIT>
|
||
</INTERNAL-CONSTRS>
|
||
</DATA-CONSTR-RULE>
|
||
</DATA-CONSTR-RULES>
|
||
</DATA-CONSTR>
|
||
```
|
||
|
||
#### 6.5.17 Application Interfaces 域中的 Blueprintable 元素
|
||
|
||
AUTOSAR 元模型提供并支持允许用户从定义明确的模型元素库创建和扩展模型元素的机制。其目标是提供从可在不同上下文中使用的具有增强特征和属性的元素派生的可能性（例如系列项目）。（有关 blueprint 机制和元模型 UML 类的完整定义，请参阅 [9]）
|
||
|
||
此 blueprint 机制主要基于三个实体：
|
||
|
||
- **Blueprint**：充当元素的预定义。它基本上遵循与派生元素相同的结构。
|
||
- **Blueprinted Element**：充当从 Blueprint 派生的元素。这些元素主要通过**复制和细化**从 blueprints 派生。这种"细化"可以添加进一步的属性值。
|
||
- **Blueprint Mapping**：充当 blueprints 及其派生元素之间的引用。此 blueprint 映射的主要目的是能够针对每个派生元素验证它们是否符合 blueprint。
|
||
|
||
专注于 Application Interfaces 域的目标是促进 `SwComponentType` 范围之外的模型元素的重用。Blueprintable 元素被收集到一个独立的元素库中，可以从中创建、细化派生元素（例如 `PortPrototypes`）并插入到 `SWComponentsProtoTypes` 中。Blueprintable 元素对 AUTOSAR RTE 级别没有影响（影响由 derive prototype 元素涵盖）。
|
||
|
||
Application Interfaces 域中有不同类型的 Blueprintable 元素。它们被收集到归类为 BLUEPRINT 的不同包中：
|
||
|
||
- `DataConstrs`
|
||
- `ApplicationDataTypes`
|
||
- `CompuMethods`
|
||
- `PortInterfaces`
|
||
- `PortPrototypeBlueprints`
|
||
- `Keywords`
|
||
- `Collections`
|
||
|
||
在 Application Interfaces 范围内，严格遵循 blueprint 和 blueprinted 元素合规性的一般规则 [9]。允许从 blueprint 派生的元素更改 `longName`、`desc`（description）和 `introduction` 属性，而如果 shortName 或符号不是固定的但打算在从 blueprints 派生对象时定义（例如在系列项目中），则指定一个称为 `namePattern` 的特定属性。派生对象的 shortName 应遵循 `namePattern` 属性中定义的模式。
|
||
|
||
`namePattern` 属性使用的完整语法在 [9] 中定义，此处不详细报告。尽管如此，由于此语法几乎可以产生用于构建 shortNames 的任何可能解决方案，因此强烈建议使用它来遵循本文档中已为每种元素类型定义的 shortName 构造规则。
|
||
|
||
即使没有定义强制性模式且属性值为 `anyName`，也强烈建议以下用例和相关语法使用：
|
||
|
||
- **用例 1**：元素使用一次（一个派生元素）：`{blueprintName}`
|
||
- **用例 2**：元素使用两次或更多次（两个或更多派生元素）：`{blueprintName}({<Keyword>})0..n`
|
||
|
||
其中 `{blueprintName}` 表示所应用 blueprint 的 `shortName` / `shortLabel` / `symbol`。
|
||
|
||
现在将特别关注 `PortPrototypeBlueprint` 元素，因为以下考虑对于一般的其他 blueprintable 元素也有效（请查看 [9] 了解更多具体细节）。
|
||
|
||
#### 6.5.18 PortPrototypeBlueprint (PORT-PROTOTYPE-BLUEPRINT)
|
||
|
||
对于本文档的范围，`PortPrototypeBlueprint` 具有以下特征：
|
||
|
||
- 它是一个 `ARElement`，因此除了 `ARPackage` 之外不需要任何元素作为上下文。因此，不需要将"辅助"模型元素涉及标准化"应用接口"的定义，仅仅是为了符合 AUTOSAR 元模型。
|
||
- 创建的 `PortPrototype` 的结构与在不采用 `PortPrototypeBlueprint` 作为 blueprint 的情况下创建的 `PortPrototype` 无法区分。`PortPrototypeBlueprint` 可以根据需要用作任意数量的 `PortPrototypes` 的 blueprint。
|
||
- 它只能用于"应用接口"的标准化。`PortPrototypeBlueprint` 在任何 `SwComponentType` 或相关模型工件的形式描述中不起任何作用。可以肯定的是，`PortPrototypeBlueprint` 的存在对 AUTOSAR RTE 没有影响。
|
||
- 派生的 `PortPrototypes` 可能具有比 `PortPrototypeBlueprint` 更多的属性
|
||
- 派生的 `PortPrototypes` 的属性从 `PortPrototypeBlueprint` 复制而来，但有一个例外，即可能无法复制的属性 `namePattern`。
|
||
|
||
属性 `namePattern` 表示应用于构建派生元素（在本例中为 `PortPrototypes`）的 shortName 的模式。这允许根据预定义规则更改从 `PortPrototypeBlueprint` 派生的 `PortPrototype` 的 shortName。
|
||
|
||
#### [TR_SWNR_00037] 提供/所需操作或数据的指示
|
||
|
||
⌈ `PortPrototypeBlueprint` 应**指示端口提供/所需的操作或数据**。 ⌋ (`RS_SWMG_00006`、`RS_SWMG_00054`)
|
||
|
||
```xml
|
||
<AR-PACKAGE>
|
||
<SHORT-NAME>PortPrototypeBlueprints_Blueprint</SHORT-NAME>
|
||
<CATEGORY>BLUEPRINT</CATEGORY>
|
||
<REFERENCE-BASES>
|
||
<REFERENCE-BASE>
|
||
<SHORT-LABEL>PortInterfaces</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">/AUTOSAR/AISpecification/PortInterfaces_Blueprint</PACKAGE-REF>
|
||
</REFERENCE-BASE>
|
||
</REFERENCE-BASES>
|
||
<ELEMENTS>
|
||
.
|
||
.
|
||
.
|
||
<PORT-PROTOTYPE-BLUEPRINT>
|
||
<SHORT-NAME NAME-PATTERN="{anyName}">DrvrProf</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">Driver Profile</L-4></LONG-NAME>
|
||
<DESC><L-2 L="EN">Status of current selected personalization profile from profile
|
||
manager. It is a common profile selectable from transponder, remote key, keyless access, Human
|
||
Machine Interface (HMI),...</L-2></DESC>
|
||
|
||
<INTERFACE-REF DEST="SENDER-RECEIVER-INTERFACE"
|
||
BASE="PortInterfaces">ProfPenSt1</INTERFACE-REF>
|
||
</PORT-PROTOTYPE-BLUEPRINT>
|
||
.
|
||
.
|
||
.
|
||
</ELEMENTS>
|
||
</AR-PACKAGE>
|
||
```
|
||
|
||
#### 6.5.19 Keywords
|
||
|
||
关键字（表示用于 short name 构造的一组基本元素）被收集到一个名为 `KeywordSets_Blueprint` 的包中，并归类为 BLUEPRINT 以支持以不同语言添加 long name 和文档。
|
||
|
||
有关在 shortname 构造中使用关键字及其缩写名称（充当 abbrName 属性）的规则在第 6.3.1 节中描述。
|
||
|
||
**示例**：
|
||
|
||
```xml
|
||
<AR-PACKAGE>
|
||
<SHORT-NAME>KeywordSets_Blueprint</SHORT-NAME>
|
||
<CATEGORY>BLUEPRINT</CATEGORY>
|
||
<ELEMENTS>
|
||
<KEYWORD-SET>
|
||
<SHORT-NAME>KeywordList</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">AUTOSAR Keywords and Keywords Abbreviations</L-4></LONG-NAME>
|
||
<KEYWORDS>
|
||
<KEYWORD>
|
||
<SHORT-NAME>Idx0</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">0</L-4></LONG-NAME>
|
||
<DESC><L-2 L="EN">Index 0. This keyword is used to express the number zero
|
||
in form of an index</L-2></DESC>
|
||
<ABBR-NAME>0</ABBR-NAME>
|
||
<CLASSIFICATIONS>
|
||
<CLASSIFICATION>Index</CLASSIFICATION>
|
||
</CLASSIFICATIONS>
|
||
</KEYWORD>
|
||
.
|
||
.
|
||
.
|
||
<KEYWORD>
|
||
<SHORT-NAME>Abs</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">Abs</L-4></LONG-NAME>
|
||
<DESC><L-2 L="EN">antilock braking system</L-2></DESC>
|
||
<ABBR-NAME>Abs</ABBR-NAME>
|
||
<CLASSIFICATIONS>
|
||
<CLASSIFICATION>Mean-Environment-Device</CLASSIFICATION>
|
||
</CLASSIFICATIONS>
|
||
</KEYWORD>
|
||
<KEYWORD>
|
||
<SHORT-NAME>Abslt</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">Absolute</L-4></LONG-NAME>
|
||
<DESC><L-2 L="EN">Absolute value</L-2></DESC>
|
||
<ABBR-NAME>Abslt</ABBR-NAME>
|
||
<CLASSIFICATIONS>
|
||
<CLASSIFICATION>Condition-Qualifier</CLASSIFICATION>
|
||
</CLASSIFICATIONS>
|
||
</KEYWORD>
|
||
.
|
||
.
|
||
</KEYWORDS>
|
||
</KEYWORD-SET>
|
||
</ELEMENTS>
|
||
</AR-PACKAGE>
|
||
```
|
||
|
||
#### 6.5.20 Application Level 的 Float Datatype 表示指南
|
||
|
||
Software Component Template [3] 没有明确指定如何实现 float 应用数据类型。Autosar 中存在三个级别的数据类型抽象：应用数据类型、实现数据类型和基本类型。
|
||
|
||
float 数据类型的使用通常会影响数据实现的低层。ECU 级别的最终 arxml 摘录如下：
|
||
|
||
```xml
|
||
<AR-PACKAGES>
|
||
<AR-PACKAGE>
|
||
<SHORT-NAME>AUTOSAR_PlatformTypes</SHORT-NAME>
|
||
<AR-PACKAGES>
|
||
<AR-PACKAGE>
|
||
<SHORT-NAME>SwBaseTypes</SHORT-NAME>
|
||
<ELEMENTS>
|
||
…
|
||
<SW-BASE-TYPE>
|
||
<SHORT-NAME>float32</SHORT-NAME>
|
||
<LONG-NAME>
|
||
<L-4 L="EN">Float</L-4>
|
||
</LONG-NAME>
|
||
<CATEGORY>FIXED_LENGTH</CATEGORY>
|
||
<BASE-TYPE-SIZE>32</BASE-TYPE-SIZE>
|
||
<BASE-TYPE-ENCODING>IEEE754</BASE-TYPE-ENCODING>
|
||
<MEM-ALIGNMENT>32</MEM-ALIGNMENT>
|
||
<BYTE-ORDER>MOST-SIGNIFICANT-BYTE-LAST</BYTE-ORDER>
|
||
</SW-BASE-TYPE>
|
||
…
|
||
</ELEMENTS>
|
||
</AR-PACKAGE>
|
||
<AR-PACKAGE>
|
||
<SHORT-NAME>ImplementationDataTypes</SHORT-NAME>
|
||
<LONG-NAME>
|
||
<L-4 L="EN">AUTOSAR Platform types</L-4>
|
||
</LONG-NAME>
|
||
<ELEMENTS>
|
||
….
|
||
<IMPLEMENTATION-DATA-TYPE>
|
||
<SHORT-NAME>float32</SHORT-NAME>
|
||
<LONG-NAME>
|
||
<L-4 L="EN">Float</L-4>
|
||
</LONG-NAME>
|
||
<CATEGORY>VALUE</CATEGORY>
|
||
<INTRODUCTION>
|
||
<TRACE>
|
||
<SHORT-NAME>PLATFORM041</SHORT-NAME>
|
||
<CATEGORY>SPECIFICATION_ITEM</CATEGORY>
|
||
<P>
|
||
<L-1 L="EN">This standard AUTOSAR type shall be mapped as a single precision (32 bit) floating-point number.</L-1>
|
||
</P>
|
||
</TRACE>
|
||
</INTRODUCTION>
|
||
<SW-DATA-DEF-PROPS>
|
||
<SW-DATA-DEF-PROPS-VARIANTS>
|
||
<SW-DATA-DEF-PROPS-CONDITIONAL>
|
||
<BASE-TYPE-REF DEST="SW-BASE-TYPE">/AUTOSAR_PlatformTypes/SwBaseTypes/float32</BASE-TYPE-REF>
|
||
</SW-DATA-DEF-PROPS-CONDITIONAL>
|
||
</SW-DATA-DEF-PROPS-VARIANTS>
|
||
</SW-DATA-DEF-PROPS>
|
||
</IMPLEMENTATION-DATA-TYPE>
|
||
….
|
||
</AR-PACKAGE>
|
||
</AR-PACKAGES>
|
||
```
|
||
|
||
为了考虑在 Application Level 使用 float 数据类型定义的一些初步要求，定义了一些建议：
|
||
|
||
**PortprototypeBlueprint 级别的建议**：
|
||
|
||
- 始终使用 1:1 缩放：例如内部表示 = 10.1 → 物理值 10.1Pa
|
||
- 应仅进行单精度计算（**不建议** float 64）
|
||
- 如果已知目标 ECU，**不要**在 RAM/Stack 资源比 CPU 负载更关键的情况下使用 float。
|
||
- Float 应始终与 SI Unit 一起用作物理表示。
|
||
- 如果对于同一信号需要大范围和低精度或小范围和高精度，则**严格建议**使用 Float。
|
||
- 示例：
|
||
- 严格建议对 Pressure（[Pa]）使用 Float
|
||
- 严格建议对 Injection Quantity（[kg]）使用 Float
|
||
- 当整数精度足够时（例如 Temperature（[K]）），**不应**使用 Float。
|
||
|
||
**AUTOSAR 中 Flat Instance Descriptors（SW Signals）使用 Float 数据类型的建议**：
|
||
|
||
- 必须满足 AUTOSAR 元模型的兼容性规则
|
||
- 可以使用任何物理显示表示
|
||
|
||
应使用 float 数据类型实现的 Application datatype 与其他连续值数据类型在以下方面有所不同：
|
||
|
||
- **Compumethod**：
|
||
- 它们引用与所涉及 Unit 相关的相应 IDENTICAL compumethod
|
||
- **DataConstrs**：
|
||
- 无限制（[-INF..+INF]）范围，由应用级别的 dataconstrs 元素 `RngUnlimd` 定义一次
|
||
- **swIntendedResolution**：
|
||
- 默认值 `0.0000001` 表示 32 位 IEEE754 的机器 epsilon（ISO C 标准；C、C++ 和 Python 语言常量）
|
||
|
||
例如：T6，温度的 float 数据类型：
|
||
|
||
**ApplicationDatatype 的定义**：
|
||
|
||
```xml
|
||
<APPLICATION-PRIMITIVE-DATA-TYPE>
|
||
<SHORT-NAME NAME-PATTERN="{anyName}">T6</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">Temperature 6</L-4> </LONG-NAME>
|
||
<DESC> <L-2 L="EN">Generic data type for temperature</L-2> </DESC>
|
||
<CATEGORY>VALUE</CATEGORY>
|
||
<INTRODUCTION>
|
||
<P> <L-1 L="EN">Examples for usage: glow plugs temperature, oil temperature, environment temperature, temperature differences
|
||
Remark: use for floating point implementation</L-1>
|
||
</P>
|
||
</INTRODUCTION>
|
||
<SW-DATA-DEF-PROPS>
|
||
<SW-DATA-DEF-PROPS-VARIANTS>
|
||
<SW-DATA-DEF-PROPS-CONDITIONAL>
|
||
<SW-CALIBRATION-ACCESS>READ-ONLY</SW-CALIBRATION-ACCESS>
|
||
<COMPU-METHOD-REF BASE="CompuMethods" DEST="COMPU-METHOD">KelvinIdentcl</COMPU-METHOD-REF>
|
||
<DATA-CONSTR-REF BASE="DataConstrs" DEST="DATA-CONSTR">RngUnlimd</DATA-CONSTR-REF>
|
||
<SW-INTENDED-RESOLUTION>0.0000001</SW-INTENDED-RESOLUTION>
|
||
<UNIT-REF BASE="Units" DEST="UNIT">Kelvin</UNIT-REF>
|
||
</SW-DATA-DEF-PROPS-CONDITIONAL>
|
||
</SW-DATA-DEF-PROPS-VARIANTS>
|
||
</SW-DATA-DEF-PROPS>
|
||
</APPLICATION-PRIMITIVE-DATA-TYPE>
|
||
```
|
||
|
||
**CompuMethod 的定义**：
|
||
|
||
```xml
|
||
<COMPU-METHOD>
|
||
<SHORT-NAME NAME-PATTERN="{anyName}">KelvinIdentcl</SHORT-NAME>
|
||
<LONG-NAME> <L-4 L="EN">Kelvin Identical</L-4> </LONG-NAME>
|
||
<DESC/>
|
||
<CATEGORY>IDENTICAL</CATEGORY>
|
||
<UNIT-REF BASE="Units" DEST="UNIT">Kelvin</UNIT-REF>
|
||
</COMPU-METHOD>
|
||
```
|
||
|
||
**无限制 DataConstrs 的定义**：
|
||
|
||
```xml
|
||
<DATA-CONSTR>
|
||
<SHORT-NAME NAME-PATTERN="{anyName}">RngUnlimd</SHORT-NAME>
|
||
<LONG-NAME><L-4 L="EN">Range Unlimited</L-4></LONG-NAME>
|
||
<DATA-CONSTR-RULES>
|
||
<DATA-CONSTR-RULE>
|
||
<PHYS-CONSTRS>
|
||
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">-INF</LOWER-LIMIT>
|
||
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">+INF</UPPER-LIMIT>
|
||
</PHYS-CONSTRS>
|
||
</DATA-CONSTR-RULE>
|
||
</DATA-CONSTR-RULES>
|
||
</DATA-CONSTR>
|
||
```
|
||
|
||
---
|
||
|
||
## 翻译说明
|
||
|
||
- 本文档为**建模指南类**，包含 70+ 项编号规则（TR_SWMG_xxxx 和 TR_SWNR_xxxx），已全部翻译
|
||
- XML 代码块已翻译注释（`<DESC>`、`<LONG-NAME>` 等），但保留所有 XML 标签、属性、属性值
|
||
- 元模型类名（如 `SwComponentType`、`PortPrototype`、`SenderReceiverInterface`）保持英文不译
|
||
- 所有需求 ID（`RS_SWMG_xxxxx`、`TR_SWMG_xxxx`、`TR_SWNR_xxxx`、`SWS_Rte_xxxx`）保持英文
|
||
- 关键字缩略语（如 `Drvr`、`Snsr`、`Actr`、`Tq`、`Spd`）保持英文不译
|
||
- AUTOSAR 方框符 `⌈⌋` 已保留，用于标记需求/规则文本的开始与结束
|
||
- 文档间交叉引用（如 [TPS_STDT_xxxxx]）已保留
|
||
|
||
---
|
||
|
||
*翻译：opencode-translator / Step 3 P0 批量翻译*
|