33 KiB
33 KiB
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 官方文档之间完整的可追溯性目标 • 根据标准化模板引入官方需求标识流程 • 命名约定需求扩展以涵盖 Long Names（长名称）领域 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | • 与一个方法论小组保持一致，对标签进行重命名 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | • 移除以下需求：MG015、MG050 • 新增以下需求：MG059、MG060、MG061 • MG014 中的 short name 长度限制设置为 128 个字符 • 修订法律免责声明 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | • 修订法律免责声明 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | • 初始发布（Initial Release） |
目录（Table of Contents）
- 文档范围（Scope of Document）
- 1.1 术语（Terminology）
- 使用的约定（Conventions to be used）
- 缩略语与缩写（Acronyms and Abbreviations）
- 命名约定需求（Naming Convention Requirements）
- 4.1 [RS_SWMG_00001] 区分标准化与非标准化的 ARElement 类型模型元素
- 4.2 [RS_SWMG_00002] 名称应反映模型元素的用途
- 4.3 [RS_SWMG_00005] 易于创建名称
- 4.4 [RS_SWMG_00006] 模型元素的名称应自解释
- 4.5 [RS_SWMG_00007] 区分不同供应商的模型元素
- 4.6 [RS_SWMG_00010] 模型元素名称应遵循语义规则
- 4.7 [RS_SWMG_00011] 模型元素名称由标准化关键字排列组成
- 4.8 [RS_SWMG_00012] 模型元素名称的语义应允许可变数量的关键字
- 4.9 [RS_SWMG_00014] Identifiable 的 short name 长度限制
- 4.10 [RS_SWMG_00016] 名称应允许表明值是直接测量值还是条件值
- 4.11 [RS_SWMG_00017] 名称应遵循 ISO 8855 进行英文命名
- 4.12 [RS_SWMG_00030] 使用英语作为名称的标准语言
- 4.13 [RS_SWMG_00031] 名称中不含架构信息
- 4.14 [RS_SWMG_00034] 关键字的唯一使用
- 4.15 [RS_SWMG_00039] 避免使用尾部下划线
- 4.16 [RS_SWMG_00040] 避免下划线字符的连续使用
- 4.17 [RS_SWMG_00041] 不仅依赖大小写差异区分名称
- 4.18 [RS_SWMG_00048] 易于在数据库中查找名称
- 4.19 [RS_SWMG_00049] 支持主表中已存在的 Identifiable
- 4.20 [RS_SWMG_00054] 提供解决命名冲突的指南
- 4.21 [RS_SWMG_00059] 应存在单一的关键字集
- 4.22 [RS_SWMG_00060] 命名约定的适用性
- 4.23 [RS_SWMG_00061] 命名约定应具有唯一性
- 4.24 [RS_SWMG_00062] 命名约定应规定 Short Names 与 Long Names 的构造
- 建模需求（Modeling Requirements）
- 参考文献（References）
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 中进行了规定。该需求的一种可能实现方式为： - 模型元素名称的前缀 - 模型元素名称的后缀 - 标准化组件的包（不适用于 Port），这也可以作为该需求的一种解决方案。 |
⌋()
4.2 [RS_SWMG_00002] 名称应反映模型元素的用途
⌈
| 字段 | 内容 |
|---|---|
| Type（类型） | valid |
| Description（描述） | 命名约定应允许定义的名称能让人一眼看出元素的用途。 |
| Rationale（原理） | 必须避免为具有不同用途的元素创建相同的名称。例如，需要区分数据流属性（如 Request 和 Status），以便对那些本应相等的名称加以区分。 |
| Use Case（用例） | 识别接口和/或数据元素是命令、状态、请求、值等。 示例： PGearEngaged（档位已接合）与 PGearRequest（档位请求） |
| Dependencies（依赖） | ⌋() [RS_SWMG_00005] 易于创建名称 |
| Supporting Material（支持材料） | 来源：Body 域内部文档AUTOSAR_CentralLocking_ApplicationInterfaces.doc：接口/数据元素名称中关键字（如 "operation"）的语义： • Cmd（command）：执行/激活某事（例如，从主控到执行器） • Req（request）：请求执行/激活某事（例如，从传感器到主控） • Sta（status）：获取功能状态信息 • Hmi：用户请求（例如，驾驶员通过开关、触摸屏等） • Dis（display）：用于驾驶员信息显示的状态反馈 • 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（依赖） | ⌋() [RS_SWMG_00005] 易于创建名称 ⌋() [RS_SWMG_00048] 易于在数据库中查找名称 |
| Supporting Material（支持材料） | 建模指南、AI 规范 |
⌋()
4.7 [RS_SWMG_00011] 模型元素名称由标准化关键字排列组成
⌈
| 字段 | 内容 |
|---|---|
| Type（类型） | valid |
| Description（描述） | -- |
| Rationale（原理） | 通过这样做，对命名约定的符合性可以通过名称检查器或名称创建工具进行验证。如果关键字和缩略语未标准化，名称长度限制会导致名称难以理解。 |
| Use Case（用例） | -- |
| Dependencies（依赖） | ⌋() [RS_SWMG_00005] 易于创建名称 ⌋() [RS_SWMG_00034] 关键字的唯一使用 |
| Supporting Material（支持材料） | 建模指南、AI 规范 |
⌋()
4.8 [RS_SWMG_00012] 模型元素名称的语义应允许可变数量的关键字
⌈
| 字段 | 内容 |
|---|---|
| Type（类型） | valid |
| Description（描述） | 组合关键字的数量应取决于解释的需要。 |
| Rationale（原理） | 创建的名称应尽可能简单，但应按需复杂。 |
| Use Case（用例） | -- |
| Dependencies（依赖） | ⌋() [RS_SWMG_00005] 易于创建名称 ⌋() [RS_SWMG_00010] 模型元素名称应遵循语义规则 ⌋() [RS_SWMG_00034] 关键字的唯一使用 |
| Supporting Material（支持材料） | 建模指南 解决方案示例： Eng_tqCluReqDrvSlow → Engine Torque at Clutch Slow Request（发动机离合器慢速请求扭矩）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（依赖） | ⌋() [RS_SWMG_00030] 使用英语作为名称的标准语言 |
| Supporting Material（支持材料） | -- |
⌋()
4.12 [RS_SWMG_00030] 使用英语作为名称的标准语言
⌈
| 字段 | 内容 |
|---|---|
| Type（类型） | Valid |
| Description（描述） | 名称和缩略语应使用英语。 |
| Rationale（原理） | 名称和关键字的国际性和共同理解。 |
| Use Case（用例） | 不同国籍的设计师在定义新名称时将得出相同的解决方案。 |
| Dependencies（依赖） | ⌋() [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（依赖） | ⌋() [RS_SWMG_00010] 模型元素名称应遵循语义规则 ⌋() [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（依赖） | ⌋() [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 定义。使用前缀解决方案，名称可能如下：PrimitiveTypeWithSemantic：Veh_v 用于车辆速度CompuMethode：Compu_Veh_v 用于车辆速度数据类型Interface：If_Veh_v 用于车辆速度的接口前缀解决方案的缺点是会增加名称的长度，并可能导致违反 RS_SWMG_00014。 另一种可能的解决方案是使用子包。 |
⌋()
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) 在任意方愿意合作的开放环境中，所有方都应使用相同的命名约定。 2) 如果支持特定域或方的专用命名约定，则该约定的接受度将非常低。许多方会争辩说他们需要针对其领域的特定约定。 |
| Use Case（用例） | -- |
| Dependencies（依赖） | [RS_SWMG_00002] 名称应反映模型元素的用途， ⌋() [RS_SWMG_00005] 易于创建名称， ⌋() [RS_SWMG_00006] 模型元素的名称应自解释， ⌋() [RS_SWMG_00034] 关键字的唯一使用 |
| Supporting Material（支持材料） | 通用命名约定的全球接受将需要时间，但不应限制该标准的要求。 |
⌋()
4.23 [RS_SWMG_00061] 命名约定应具有唯一性
⌈
| 字段 | 内容 |
|---|---|
| Type（类型） | valid |
| Description（描述） | 命名约定必须声明清晰且确定性的名称创建规则，以便可以从信号特征唯一地确定名称。 |
| Rationale（原理） | 1) 支持分布式开发 2) 避免冗余信号的定义，因为不同的开发人员将通过应用相同的规则来创建名称。 3) 避免信号的误用。 4) 启用一致性检查和基于工具的名称处理。 5) 增强可读性，因为所有开发人员/名称用户都形成相同的思维模式。 |
| Use Case（用例） | -- |
| Dependencies（依赖） | [RS_SWMG_00002] 名称应反映模型元素的用途， ⌋() [RS_SWMG_00006] 模型元素的名称应自解释， ⌋() [RS_SWMG_00010] 模型元素名称应遵循语义规则， ⌋() [RS_SWMG_00011] 模型元素名称由标准化关键字排列组成 ⌋() [RS_SWMG_00016] 名称应允许表明值是直接测量值还是条件值 ⌋() [RS_SWMG_00031] 名称中不含架构信息 ⌋() [RS_SWMG_00034] 关键字的唯一使用 [RS_SWMG_00054] 提供解决命名冲突的指南 [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] 名称应反映模型元素的用途， ⌋() [RS_SWMG_00006] 模型元素的名称应自解释， ⌋() [RS_SWMG_00010] 模型元素名称应遵循语义规则， ⌋() [RS_SWMG_00011] 模型元素名称由标准化关键字排列组成 [RS_SWMG_00012] 模型元素名称的语义应允许可变数量的关键字 ⌋() [RS_SWMG_00016] 名称应允许表明值是直接测量值还是条件值 ⌋() [RS_SWMG_00034] 关键字的唯一使用 [RS_SWMG_00049] 支持主表中已存在的 Identifiable [RS_SWMG_00054] 提供解决命名冲突的指南 [RS_SWMG_00059] 应存在单一的关键字集 [RS_SWMG_00060] 命名约定的适用性 [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（原理）** | 由于成本原因，当今市场上大多数商用处理器没有硬件浮点运算支持。为避免或限制此类功能的软件仿真（将导致软件执行开销），通常使用定点（整数）数学。 大部分处理器甚至没有整数乘法硬件支持。通过为定点（整数）数分配以 2 的幂表示的分辨率，乘法和除法的软件仿真将仅减少为算法功能上需要的那些操作。 |
| Use Case（用例） | 在 SWC 算法中，将分辨率为 0.001/lsb 的增益应用于类型为 UInt16 且分辨率为 0.004/lsb 的变量，以获得具有相同分辨率的结果。 在这种情况下，除了应用增益所需的乘法和范围饱和外，还需要除以 1000 以将结果重新缩放到所请求的分辨率。 通过将操作数转换为 2 的幂分辨率，即变量的 -8 次方/lsb 和增益的 -10 次方/lsb，重新缩放将通过 10 位的逻辑右移执行（在某些微处理器中只需一个指令周期），并且相对于第一种解决方案没有精度损失。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋()
5.4 [RS_SWMG_00056] 标准化模型元素不应包含非标准化元素
⌈
| 字段 | 内容 |
|---|---|
| Type（类型） | Valid |
| Description（描述） | 标准化模型元素不应包含非标准化元素。 |
| Rationale（原理） | 为避免混淆，必须使一个元素完全标准化，即使不是部分标准化。 |
| Use Case（用例） | -- |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | 建议的冲突解决方案如下： - 定义一种新的非标准化组合类型，其中包含标准化组件类型和附加的非标准化组件。 - 这种组合的接口可以是标准化组件类型的所有端口加上附加的非标准化端口。 |
⌋()
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 批量翻译