Standardization Template
参考文献¶
[1] Software Component Template
AUTOSAR_CP_TPS_SoftwareComponentTemplate
AUTOSAR_FO_TPS_StandardizationTemplate
[3] Requirements on AUTOSAR Features
AUTOSAR_CP_RS_Features
AUTOSAR_FO_RS_Main
[5] Specification of ECU Configuration
AUTOSAR_CP_TPS_ECUConfiguration
[6] Specification of Platform Types for Classic Platform
AUTOSAR_CP_SWS_PlatformTypes
[7] Generic Structure Template
AUTOSAR_FO_TPS_GenericStructureTemplate
[8] XML Specification of Application Interfaces
AUTOSAR_CP_MOD_AISpecification
[9] SW-C and System Modeling Guide
AUTOSAR_CP_TR_SWCModelingGuide
1. 简介¶
AUTOSAR 模型在许多情况下并非从零创建，而是以既有内容为基础。既有内容可以由 AUTOSAR 组织本身以标准化模型元素的形式提供。
本文档规定对标准化模板（Standardization Template）的需求。该模板旨在支持 AUTOSAR 交付标准化的模型元素。
AUTOSAR 4.0 已经规定了用于标准化的蓝图（blueprint）方法。标准化模板延续并改进了该方法。由此它将取代软件组件模板 [1] 中的附录 A。
作为一个具体示例，让我们考虑应用接口的标准化。即，就 AUTOSAR 元模型而言，标准化主要适用于为特定目的定义 PortPrototype。
由于 AUTOSAR 元模型的结构，仅仅表达一个标准化的 PortPrototype 是不可能的，因为有充分的理由，后者并不独立存在，而是始终由一个 SwComponentType 拥有。
标准化模板规定了克服这种情形的方法。
1.1. 文档约定¶
AUTOSAR 文档中需求的呈现遵循 TPS_STDT_00078 中规定的表格，参见标准化模板的「可追溯性支持（Support for Traceability）」章节（[2]）。
应使用 TPS_STDT_00053 中规定的表达义务的言语形式来表示需求，参见标准化模板的「可追溯性支持」章节（[2]）。
1.2. 指南¶
现有的规范应被引用（以单个需求的形式）。与这些规范的差异被规定为附加需求。所有需求应具有以下属性：
- 冗余性（Redundancy）
需求不得在单个需求内或其他需求中重复。
- 清晰性（Clearness）
所有需求应当只允许一种解释。所使用的、不在术语表中的技术术语必须被定义。
- 原子性（Atomicity）
每条需求应只包含一个需求。如果一个需求无法被进一步拆分为更多需求，则它是原子的。
- 可测试性（Testability）
需求应当可以通过分析、评审或测试来验证。
- 可追溯性（Traceability）
需求的来源和状态应当始终可见。
2. 用例¶
本章描述标准化模板的用例。这些用例的意图是指出标准化模板的潜在应用。总体上，标准化模板的用例是将 AUTOSAR 标准化的条目表达为 AUTOSAR XML 工件。该工件随后可用于支持开发符合 AUTOSAR 的产品。
本文档中定义的每个用例都有其唯一标识符，以前缀 UC_STDT_（表示 Standardization Template Use Case）开头。
2.1. 支持应用接口¶
AUTOSAR：为不同领域（例如底盘、动力总成、车身等）提供标准化、公开披露的接口。这些接口的定义可以在不同的深度层级上处理：
- L8：SWC 的完整描述，包括行为模型和端口
- L7：所有端口的完整描述，包括接口行为和数据质量
- L6：所有端口的完整描述，包括接口行为和数据质量的文字描述
- L5：所有端口的完整描述，包括接口的数据质量
- L4：所有端口的完整描述，包括在 AUTOSAR 内商定的数据质量
- L3：SWC 的端口/接口的部分描述，包括在 AUTOSAR 内商定的数据质量
请注意，这一部分描述既包括只描述了部分端口的事实，也包括对端口的描述是不完整的、并且与适用的组件相分离的事实。这也被称为 PortBluePrint。
- L2：接口字典，包括一组在 AUTOSAR 内商定的数据质量
- L1：数据元素字典，包括类型和范围。
- L0：名称字典
从 4.0 版本起，AUTOSAR 标准化覆盖 L0 … L3 层级。尽管如此，供应商内部应用也可能将标准化模板用于更高的层级。
该用例主要覆盖应用软件方面。
应用这种形式化描述将提高 AUTOSAR 应用接口的一致性和可用性，并支持形式化检查，例如应用接口的向后兼容性检查。
2.2. 表达 SWS 的部分内容¶
标准化模板应当允许使用 AUTOSAR schema 形式化地表达基础软件模块 SWS 的部分内容。这包括（但不限于）：
- 标准化接口（即 C 语言 API）
- 标准 AUTOSAR 接口（端口、端口接口等）
- ECUC 参数的定义（见 2.3）
应用这种形式化描述将提高 AUTOSAR SWS 的一致性和可用性，并支持形式化检查，例如接口的向后兼容性检查。
2.3. 标准化 ECUC 参数定义¶
AUTOSAR SWS 的组成部分还包括 ECU 配置参数定义的集合。这些参数定义是所谓的供应商特定参数的基础，后者用于具体的 AUTOSAR 实现中。
尽管这在 [5] 中有非常详细的规定，它同样在标准化模板的范围之内。
2.4. 表达预定义路径¶
开发伙伴可以就特定的包布局达成一致，从而在开发的后期阶段共享 AUTOSAR 工件。对于该用例，预先表达一组预定义或部分预定义的引用路径（reference path）或引用基（referenceBase）会很有帮助，它们可以被加载到各个 AUTOSAR 制作工具中。
该用例覆盖引用路径的开头或结尾。例如，用例是在一个可变路径之后标准化子结构：<MyPath>/PortInterfaces。在这种情形下只有 PortInterfaces 被标准化。
2.5. 表达平台类型¶
[6] 中定义的平台类型需要以可供 AUTOSAR 开发工具处理的格式提供。这种方法提高了 AUTOSAR 产品的一致性和质量。
适用 [7] 第 3.1 章的细节。
2.6. 表达已应用标准的示例¶
除了应用接口 [8] 之外，AUTOSAR 还提供如何应用标准化元素（特别是蓝图）的示例。
适用 [7] 第 3.1 章的细节。
2.7. 支持验证实现是否符合已定义的标准¶
在开发 AUTOSAR 产品时，可以通过将产品与形式化的标准进行验证来执行初始验证。这包括：
- 检查蓝图与派生模型元素之间的兼容性规则。这些兼容性规则要为每个有资格进行蓝图化的元类定义。
- 在模型元素与 SWS 或蓝图之间进行追溯，以检查是否实现了所有蓝图。
请注意，该用例是一种非常初始的验证，不与符合性测试规范竞争，更不能取代它。它只是为符合性测试做出贡献。
兼容性规则只需要在文档中描述，例如以约束的形式。元模型中不存在兼容性规则的形式化表示。
兼容性规则针对每个有资格进行蓝图化的元类单独规定。例如，所有端口蓝图遵循相同的兼容性规则。
2.8. 支持可复用的文档¶
AUTOSAR SWS 的部分内容可以被发布，使其能够被复用于实际的产品文档。实现的供应商随后从标准化模板的一个实例中取出这些部分，并将其纳入自己的软件文档中。
同样的方法也适用于应用接口的解释。
2.9. 定义命名约定¶
AUTOSAR 拥有建模指南和命名约定。如果这些约定作为标准化模板的实例发布，它们可以用于配置建模工具等。
该用例还覆盖表达不同义务层级的能力。这可以例如以类似于关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 的方式表达。
2.10. 在超出 AUTOSAR 范围的层级上执行标准化¶
标准化模板应当适用于公司内部的标准化或超出元层级 M1 上 AUTOSAR 标准化范围的双边协议（参见 2.1）。
关于元层级的更多细节见 [7] 第 2.2 章。
2.11. 通过手动更改属性从蓝图派生对象¶
用户制作一种蓝图的副本，并被允许添加自己的内容（例如向标准化的枚举类型添加自己的字段）。示例是 ApplicationInterfaces 和 ConfigurationParameters 的使用。
对于 AUTOSAR 服务的标准化端口接口，标准化模板应当提及如下用例：在这种情形下，基于「标准化端口接口蓝图」的端口接口可以包含 ClientServerOperations 的一个子集。
2.12. 以完全标准化的方式从蓝图派生对象¶
用户只能以完全标准化的方式配置或以其他方式影响所复制的「蓝图」的内容（例如根据软件的「需要」配置枚举类型的字段），而不能添加自己的内容。
这甚至可以走到这样的程度：只有配置的规则被标准化（如 DCM 端口接口的情形）——但这仍然完全决定了具体项目中的结果。
2.13. 集成编译测试¶
在 4.0 版本之前，所有 BSW 的 API 都被建模，SWS 的第 8 章主要从模型生成。此外，我们建议从模型生成空的 C 语言函数（以及数据结构/常量等），并将所有这些函数链接在一起。如果编译或链接过程失败，则一致性（例如不同 SWS 之间的）被违反，需要修复。
2.14. 从模型生成 BSW「标准 AUTOSAR 接口」描述¶
在 4.0 版本之前，「标准 AUTOSAR 接口」是提供该接口的每个 SWS 的一部分（通常包含在第 7 或第 8 章的一个单独的子章中）。该描述主要是纯文本，带有一些展示接口用法（包括常量等）的伪语言。此外，服务的描述经常使用元模型中已过时或含义已变化的「元素」。
计划将 SWS 的这一部分标准化，例如通过一个自己的模型（然后生成的描述可以像第 8 章那样导入 SWS），或者通过一种（标准化的）语言来澄清对接口的理解，并为 RTE 目的允许自动转换。
2.15. 处理通用规范项¶
可能存在一组需要由所有 SWS 文档满足的通用需求。另一方面，可能存在一个汇总所有通用规范项的通用规范。这种情形应通过追溯来处理：
- 追溯应同时使用两份需求文档，即通用文档和单独文档。
- 通用需求可以由通用规范或由单独规范满足。
- 通用需求可能不适用于某个特定规范。
- 通用需求可能只有由通用规范和单独规范一起才能完全满足。
2.16. 在 AUTOSAR 中管理需求¶
在 AUTOSAR 中，所有需求都以唯一的 id 形式化地记录在需求文档（RS/Feature/SRS）中。规范文档（SWS）包含形式化地追溯到需求的规范项。同一层级的需求之间的依赖关系在需求块本身中通过提供对需求的引用来表达。
2.17. 在 AUTOSAR 中管理规范项¶
在 AUTOSAR 中，所有规范项都以唯一的 id 形式化地记录在规范文档（TPS、SWS）中。规范项形式化地追溯到需求。
2.18. 在 AUTOSAR 中管理约束项¶
在 AUTOSAR 中，所有约束项都以唯一的 id 形式化地记录在规范文档（TPS、SWS）中。
2.19. 在 AUTOSAR 中管理测试项¶
在 AUTOSAR 中，所有测试项都以唯一的 id 形式化地记录在规范文档中。
2.20. 描述数据交换点¶
描述：一种机器可读的语言，允许描述一个数据交换点。该语言本质上是为某种预期用途选择 AUTOSAR 模板的一个子集。
后置条件：数据交换点的描述可用。
参与者：Profile 作者。
指南：Profile 制作工具。
- 基本流程：
- 描述概览和管理数据（例如工具、输入/输出、引用的资产、引用的 AUTOSAR 版本）
- 描述方法论中的工件（例如引用工件「ECU 系统描述」）
- 描述预期用途（例如以自由文本形式非正式地描述「创建一个 ECU 抽取，并为非分段发送和接收配置 CAN 通信栈」）
- 描述元模型的相关子集（例如列出与预期用途可能相关的元类和元属性名称）
- 描述相关约束（例如列出相关约束 ID）
- 描述相关规范项（例如列出相关规范项 ID）
- 描述模型的相关子集（例如标识根元素以及展示如何找到模型相关部分的查询）
- 描述被排除的模式（例如显式排除元类、元属性、枚举值、CATEGORY 等）
- 描述完整性（例如描述最小多重性或约束）
- 描述默认值（例如何时应用 AUTOSAR 定义的默认值的条件：「不应用」「值缺失时总是应用」「从无法表达该值的模型的版本更新时应用」等）
- 描述职责（例如通过标识消费者保证完整性的模型子集的查询）
- 记录决策的理由以便维护和复用（例如一组彼此关联的 profile 部分的引用。该组包含诸如「特性 a 所需」之类的文档）
2.21. 在 AUTOSAR 中管理建议项¶
在 AUTOSAR 中，所有建议项（advisory item）都以唯一的 id 形式化地记录在规范文档（TPS）中。
3. 需求¶
本章描述驱动标准化模板规范 [2] 定义工作的所有需求。
本文档中每条需求都有其唯一标识符，以前缀 RS_STDT_（表示 Requirement Specification for Standardization Template）开头。
3.1. 蓝图¶
3.1.1. 应总体上支持并解释蓝图¶
| 描述 | 标准化模板应支持蓝图。蓝图是一种「不完整」的模型，它被复制并在之后被精化。应定义蓝图的原则： * 「实例化」通过复制完成而不是通过引用。下游处理排除蓝图的使用。 * 为蓝图和蓝图化的模型元素定义合适的术语。 * 从蓝图创建的元素如何命名？ * 应清晰定义元模型的哪些部分有资格进行蓝图化。对元模型中无资格部分的蓝图化应被视为「验证错误」。 * 定义如何从蓝图派生对象的规则，特别是关于哪些属性可以被添加/删除/重定义的策略。这些规则应针对每个有资格进行蓝图化的元类单独定义。 应定义元模型的必要设施： * 特定的蓝图 * 蓝图与派生对象之间的映射 |
|---|---|
| 理由 | 这有助于理解蓝图的概念和应用，因为蓝图是标准化的主要手段。 |
| 用例 | 2.1、2.2、2.3、2.4、2.5、2.6、2.7、2.8、2.9 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.2. BSW SWS 的形式化描述¶
| 描述 | 标准化模板应当能够发布 SWS 的形式化部分，这些部分随后充当所规定模块的蓝图。标准化模板应提供描述标准化接口（C 语言 API）的手段。标准化模板应允许描述标准化的 AUTOSAR 接口。标准化模板必须支持接口变体的规定。 |
|---|---|
| 理由 | 尤其是「标准 AUTOSAR 接口」是提供该接口的每个 SWS 的一部分（通常包含在第 7 或第 8 章的一个单独的子章中）。该描述主要是纯文本，带有一些展示接口用法（包括常量等）的伪语言。此外，服务的描述经常使用元模型中已过时或含义已变化的「元素」。当前的状态在 RTE 在 BSW 和 SWC 之间「路由」调用时引发若干问题。伪语言必须被手动转换成某种「SWC 描述」。如果人们尝试混合来自不同供应商的模块，尚不清楚这如何工作。在我们的理解中，该格式需要被标准化。我们建议将 SWS 的这一部分标准化，例如通过一个自己的模型（然后生成的描述可以像第 8 章那样导入 SWS），或者通过一种（标准化的）语言来澄清对接口的理解，并为 RTE 目的允许自动转换。 |
| 用例 | 2.2、2.8 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.3. 应允许表示端口蓝图¶
| 描述 | AUTOSAR 标准化所谓的「应用接口」。这些接口实际上产生端口蓝图。 |
|---|---|
| 理由 | AUTOSAR 以 ARXML 形式发布标准化的模型。 |
| 用例 | 2.1、2.8 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.4. 应允许表示 shortName 模式¶
| 描述 | 蓝图应允许表示 shortName 模式，描述如何确定派生元素的 shortName。 |
|---|---|
| 理由 | AUTOSAR 发布应用接口建模指南。 |
| 用例 | 2.9 |
| 依赖项 | TR_SWCModelingGuide [9] 可能需要适配。 |
| 支撑材料 | - |
3.1.5. 应引用 ECUC 参数定义¶
| 描述 | ECUC 参数定义同样由 AUTOSAR 标准化。因此它在标准化模板的范围之内。严格来说，这些标准化的 ECUC 参数定义充当供应商特定参数的蓝图，即使它们没有使用 BluePrintMappingSet 映射。标准化模板至少对 AUTOSAR 4.0 不应改变这些方法，但应反映这些关系。 |
|---|---|
| 理由 | 这保持了总体范围和所应用的模式。 |
| 用例 | 2.3 |
| 依赖项 | - |
| 支撑材料 | [5] |
3.1.6. 应能够标准化组件¶
| 描述 | STDT 应能够表达组件的标准化，即使 AUTOSAR 不标准化组件。该需求覆盖一组单独的组件。STDT 中不得硬编码任何兼容性规则。支持来自这样一个事实：它只允许将 SwComponentType 指定为有资格进行蓝图化。 |
|---|---|
| 理由 | 这允许在公司内部利用 AUTOSAR 标准化原则。 |
| 用例 | 2.10 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.7. 应能够标准化架构¶
| 描述 | 标准化模板应当能够表达组件和通信的标准化，即使 AUTOSAR 不标准化应用软件的架构。该需求覆盖一组相互通信的组件。 |
|---|---|
| 理由 | 这允许在公司内部利用 AUTOSAR 标准化原则。 |
| 用例 | 2.10 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.8. 应能够表达引用路径和包层级的部分内容¶
| 描述 | 标准化模板应当能够表达标准化的引用路径或引用路径的部分内容。应当可以指定包层级的开头或结尾。示例见 2.4。 |
|---|---|
| 理由 | 这允许在公司内部利用 AUTOSAR 标准化原则。 |
| 用例 | 2.4 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.9. 应能够表达义务层级¶
| 描述 | 义务层级应通过关键字 'MUST'、'MUST NOT'、'REQUIRED'、'SHALL'、'SHALL NOT'、'SHOULD'、'SHOULD NOT'、'RECOMMENDED'、'MAY' 和 'OPTIONAL' 表达。 |
|---|---|
| 理由 | 这允许使用标准化模型来评估实现的符合性。 |
| 用例 | 2.9 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.10. 应支持从蓝图派生的不同方式¶
| 描述 | 应支持从蓝图派生的不同方式。这些不同的方式是： 1. 用户制作一种蓝图的副本，并被允许添加自己的内容（例如向标准化的枚举类型添加自己的字段）。 2. 用户只能以完全标准化的方式配置或以其他方式影响所复制的「蓝图」的内容（例如根据软件的「需要」配置枚举类型的字段），而不能添加自己的内容。 |
|---|---|
| 理由 | 这允许使用标准化模型来评估实现的符合性。符合性取决于派生对象的方式。 |
| 用例 | 2.7、2.11、2.12 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.11. 应涵盖蓝图与派生对象的兼容性¶
| 描述 | 标准化模板应描述蓝图与派生对象之间的兼容性规则。这些兼容性规则应针对每个有资格进行蓝图化的元类单独描述。 |
|---|---|
| 理由 | 这支持标准的持续演进。 |
| 用例 | 2.7 |
| 依赖项 | 3.1.1 |
| 支撑材料 | - |
3.1.12. 应允许描述 API 的依赖关系（例如调用和回调/轮询接口）¶
| 描述 | 标准化模板应允许描述调用接口与对应的回调或轮询接口之间的依赖关系。 |
|---|---|
| 理由 | 标准化接口在许多情况下由调用接口（C 语言 API）和回调或轮询接口组成。在许多情况下，使用哪种通信模式是可配置的。这种可配置的依赖关系和参数应通过蓝图描述。 |
| 用例 | 2.2 |
| 依赖项 | 3.1.2 |
| 支撑材料 | - |
3.1.13. 应为蓝图定义强制性语义¶
| 描述 | 对于给定的模型元素，模板必须定义该模型元素的哪些属性必须被标准化才能有资格作为蓝图。例如，端口接口的哪些信息必须存在才能被称为蓝图？对于 AUTOSAR 服务的标准化端口接口，标准化模板应当提及如下用例：在这种情形下，基于「标准化端口接口蓝图」的端口接口可以包含 ClientServerOperations 的一个子集。 |
|---|---|
| 理由 | 有助于对蓝图模型元素形成共同的理解。 |
| 用例 | 2.1 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.14. 应支持 VariableDataprototype 的变体¶
| 描述 | PortBlueprint 应能够映射到同一 PortInterface 实例的不同 VariableDataprototype。 |
|---|---|
| 理由 | WP10.3 的变体处理主要用于在乘用车和卡车之间复用定义。因此，在数据类型层级拥有变体可能比创建新的蓝图更有用。 |
| 用例 | 2.1 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.15. 应支持带有 PortBlueprint 的示例 SWC 的多重实例化¶
| 描述 | PortBlueprint 应能够支持多重实例化。 |
|---|---|
| 理由 | - |
| 用例 | 2.1 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.16. 利益相关方之间蓝图交换格式的方式¶
| 描述 | AUTOSAR 方法论应为给定的 SWC 描述文件定义 PortInterfaceMapping 的交换，即 RTE 和 VFB 原则上忽略蓝图，但在从蓝图创建 PortPrototype 时，应如何在利益相关方之间建立带有蓝图信息的交换？ |
|---|---|
| 理由 | - |
| 用例 | 2.1 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.17. 应能够标准化别名¶
| 描述 | STDT 应能够标准化别名（alias name）。 |
|---|---|
| 理由 | 例如用于测量和标定系统中的系统常量。如果系统常量将来被标准化（这尚未决定），这是必要的。 |
| 用例 | 2.8、2.9 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.18. 应允许表示端口接口蓝图¶
| 描述 | AUTOSAR 标准化所谓的「应用接口」。这些接口实际上产生端口蓝图以及相应的端口接口蓝图。 |
|---|---|
| 理由 | AUTOSAR 以 ARXML 形式发布标准化的模型。 |
| 用例 | 2.1、2.8 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.19. 应允许评估蓝图的完整性¶
| 描述 | 在 4.0 版本之前，所有 BSW 的 API 都被建模，SWS 的第 8 章主要从模型生成。此外，我们建议从模型生成空的 C 语言函数（以及数据结构/常量等），并将所有这些函数链接在一起。如果编译或链接过程失败，则一致性（例如不同 SWS 之间的）被违反，需要修复。 |
|---|---|
| 理由 | 过去我们经常遇到这样的问题：某些 SWS 假定来自其他模块的特定服务（结构体/常量等），而接口不匹配（甚至完全不存在）。在编译测试中会找到此类错误。 |
| 用例 | 2.13 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.20. 应能够表示更多的蓝图¶
| 描述 | STDT 应能够为以下元素表示蓝图： * AliasNameSet（见 3.1.17） * ApplicationDatatype * BswModuleEntry * BaseType * BswModuleDescription * CompuMethod——用于增强枚举器 * DataConstr——只要适合 BaseType 就可以加宽范围，不允许限制：工作包：不允许更改范围 * DatatypeMappingSet——派生映射集合中被映射的类型必须是从蓝图派生的类型 * EcucModuleDef * EcucDefintionCollection * ImplementationDatatype * ModeDeclarationGroup——用于添加额外的模式 * PortInterfaces（用于发送方-接收方和客户端-服务器接口）（见 3.1.18） * PortPrototypeBlueprints（见 3.1.3） |
|---|---|
| 理由 | - |
| 用例 | 2.3、2.11、2.12 |
| 依赖项 | 另见 3.1.3、3.1.18 |
| 支撑材料 | - |
3.1.21. 应允许标准化包结构¶
| 描述 | STDT 应能够表示包结构的蓝图，特别是为了预定义访问路径。 |
|---|---|
| 理由 | - |
| 用例 | 2.4 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.22. 应能够为角色和权限提供蓝图¶
| 描述 | 标准化模板应支持角色和权限的蓝图化。 |
|---|---|
| 理由 | - |
| 用例 | 2.10 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.23. 应能够为构建动作清单提供蓝图¶
| 描述 | 标准化模板应支持处理器清单（Processor Manifest）的蓝图化。 |
|---|---|
| 理由 | - |
| 用例 | 2.10 |
| 依赖项 | - |
| 支撑材料 | - |
3.1.24. 隐式通信行为的蓝图化¶
| 描述 | AUTOSAR 模板和方法论应支持隐式通信行为（Implicit Communication Behavior）描述的蓝图化。在所有细节（数据访问点）尚不可知之前，应可以对数据进行分组。在自顶向下的方法中，对 DataPrototype 的分组已经可以用于设计系统，以保证一致性属性，并使无关的 DataPrototype 之间不需要一致性。 |
|---|---|
| 理由 | 在自顶向下的设计方法中定义隐式通信行为需求。 |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
3.1.25. 应支持关键字的蓝图化¶
| 描述 | 关键字应当是可蓝图化的，以支持供应商特定的扩展。 |
|---|---|
| 理由 | 支持 AUTOSAR 发布。 |
| 用例 | 2.1 |
| 依赖项 | TR_SWCModelingGuide [9] 可能需要适配。 |
| 支撑材料 | - |
3.1.26. 派生对象中元素的多重性¶
| 描述 | 标准化模板应支持对上多重性大于 1 的元素描述所期望的派生对象数量。 |
|---|---|
| 理由 | 这支持「从蓝图派生」这一任务。 |
| 用例 | 2.11、2.12 |
| 依赖项 | - |
| 支撑材料 | - |
3.2. 关键字¶
3.2.1. 应支持关键字和关键字缩写¶
| 描述 | 在 [9] 中，AUTOSAR 发布了 ShortName 作为关键字序列的构建规则。这些关键字需要通过标准化模板表达。现有的 Keyword identifiable 应扩展一个 ShortLabel。SHORT-LABEL 的语义：用于替代 ShortName。在有多个名称部分要被同一关键字缩写缩写的情形下是必要的。由于关键字是 identifiable，这会导致冲突。 |
|---|---|
| 理由 | 支持 AUTOSAR 发布。 |
| 用例 | 2.1 |
| 依赖项 | TR_SWCModelingGuide [9] 可能需要适配。 |
| 支撑材料 | - |
3.3. AUTOSAR 集成与生命周期¶
3.3.1. 应在不与现有模板产生兼容性问题的前提下实现¶
| 描述 | 新模板应确保与现有模板兼容。 |
|---|---|
| 理由 | 4.0 所要求的 schema 向后兼容性的维护。 |
| 用例 | 2.1 |
| 依赖项 | - |
| 支撑材料 | - |
3.3.2. 应基于 AUTOSAR XML schema¶
| 描述 | 标准化模板应使用与其他模板相同的机制来描述。这包括在 AUTOSAR 元模型中的建模以及在 AUTOSAR XML Schema 中规定 XML 表示。 |
|---|---|
| 理由 | 为所有模板使用一个元模型的总体方法。 |
| 用例 | 2.1 |
| 依赖项 | - |
| 支撑材料 | - |
3.3.3. 应能够表达关于模型元素状态的信息¶
| 描述 | 如果 STDT 还能支持关于模型元素状态的信息，将是有益的。示例：由于向后兼容性，在未来的版本中删除已有的应用接口将很困难。如果某些模型元素不再是「最新技术水平」，它们可以被标记为例如「过时（obsolete）」。 |
|---|---|
| 理由 | 这支持标准的持续演进。 |
| 用例 | 2.1 |
| 依赖项 | - |
| 支撑材料 | - |
3.3.4. 支持 AUTOSAR 特定的建模模式¶
| 描述 | 用于描述数据交换点 profile 的模板应能够处理 AUTOSAR 特定的建模模式，例如： * VariationPoints * Splitable * 伪原始数据类型（例如 Identifier、Verbatim String、Limit） * 类型 / 实例引用（Type / InstanceRef references） * XML 中的相对引用 * xml.sequenceOffset * mixed 和 mixedString * 公式 |
|---|---|
| 理由 | - |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.4. 可追溯性¶
3.4.1. 应提供支持分析实现与 AUTOSAR 标准符合性的手段¶
| 描述 | 标准化模板应使实现者能够检查其描述（例如 BSWM）是否符合在 M1 层级（SWS）上规定的 AUTOSAR 标准。 |
|---|---|
| 理由 | 这建立了 AUTOSAR 实现与已定义标准之间的可追溯性。它也是检查不同版本之间应用兼容性的前提。 |
| 用例 | 2.7 |
| 依赖项 | - |
| 支撑材料 | - |
3.5. 规范元素的文档化¶
3.5.1. 应能够表示 SWS 中陈述的需求¶
| 描述 | 为了改进需求的可追溯性，SWS 的形式化描述应包含相应 SWS 文档中每条需求的文字代表（SWS 的规范项）。这些陈述应被归类为 {Requirement、Specification、Implementation、Constraint} 之一。 |
|---|---|
| 理由 | 该特性支持需求变更的自动化跟踪，这是改进的变更管理和兼容性评估的基础。 |
| 用例 | 2.7 |
| 依赖项 | - |
| 支撑材料 | - |
3.5.2. 应能够标准化唯一名称和显示名称¶
| 描述 | STDT 应能够标准化唯一名称和显示名称（Display Names），例如在文档中（完整的实例引用将不可读）以及在测量和标定系统中（像 A2L 这样的标准化测量和标定格式要求 SW 信号使用唯一名称）。 |
|---|---|
| 理由 | 支持唯一名称的标准化，例如用于： * 文档 * 标定和测量工具 |
| 用例 | 2.9、2.10 |
| 依赖项 | - |
| 支撑材料 | - |
3.5.3. 应能够标准化生命周期状态¶
| 描述 | STDT 应能够标准化特定生命周期的状态。 |
|---|---|
| 理由 | 由于 AUTOSAR 以向后兼容为目标，不可能直接删除一个标准化的模型元素并添加一个新的，或者——更糟糕的是——在不通知的情况下更改该模型元素。 |
| 用例 | 2.9、2.10 |
| 依赖项 | - |
| 支撑材料 | - |
3.5.4. 应允许从模型生成 BSW「标准 AUTOSAR 接口」描述¶
| 描述 | 「标准 AUTOSAR 接口」是提供该接口的每个 SWS 的一部分（通常包含在第 7 或第 8 章的一个单独的子章中）。该描述主要是纯文本，带有一些展示接口用法（包括常量等）的伪语言。此外，服务的描述经常使用元模型中已过时或含义已变化的「元素」。STDT 应提供标准化 SWS 这一部分的支持，例如通过一个自己的模型（然后生成的描述可以像第 8 章那样导入 SWS），或者通过一种（标准化的）语言来澄清对接口的理解，并为 RTE 目的允许自动转换。 |
|---|---|
| 理由 | - |
| 用例 | 2.14 |
| 依赖项 | - |
| 支撑材料 | - |
3.5.5. 应支持通用规范项¶
| 描述 | 支持显式指示不适用的需求和互补的规范项。特别地，允许专门的追溯索引「NA」和「SPEC」。 |
|---|---|
| 理由 | - |
| 用例 | 2.2、2.15 |
| 依赖项 | - |
| 支撑材料 | - |
3.5.6. 标准化模板应规定 AUTOSAR 文档中需求的表示¶
| 描述 | 规定 AUTOSAR 文档和 AUTOSAR 元模型中结构化需求的内容和首选图形表示。 |
|---|---|
| 理由 | 在 AUTOSAR 中一致地规范和表示需求与规范项。 |
| 用例 | 2.16 |
| 依赖项 | - |
| 支撑材料 | - |
3.5.7. 标准化模板应规定 AUTOSAR 文档中规范项的表示¶
| 描述 | 规定 AUTOSAR 文档和 AUTOSAR 元模型中规范项的内容。 |
|---|---|
| 理由 | 在 AUTOSAR 中一致地规范和表示规范项。 |
| 用例 | 2.17 |
| 依赖项 | - |
| 支撑材料 | - |
3.5.8. 标准化模板应规定 AUTOSAR 文档中约束项的表示¶
| 描述 | 规定 AUTOSAR 文档和 AUTOSAR 元模型中约束项的内容。 |
|---|---|
| 理由 | 在 AUTOSAR 中一致地规范和表示约束项。 |
| 用例 | 2.18 |
| 依赖项 | - |
| 支撑材料 | - |
3.5.9. 标准化模板应规定 AUTOSAR 文档中测试项的表示¶
| 描述 | 规定 AUTOSAR 文档和 AUTOSAR 元模型中测试项的内容。 |
|---|---|
| 理由 | 在 AUTOSAR 中一致地规范和表示测试项。 |
| 用例 | 2.19 |
| 依赖项 | - |
| 支撑材料 | - |
3.5.10. BSW 抽象 SWS 的形式化描述¶
| 描述 | 标准化模板应当能够发布通用 SWS 的形式化部分，这些部分随后被派生的具体 SWS 继承。 |
|---|---|
| 理由 | 一组 BSW SWS 通常共享一组共同的规范元素。这些通用规范元素不应被多次陈述，以避免冗余。因此，一个具体的 SWS 应能够从抽象 SWS 继承通用部分，并专注于那些必须被特别规定的元素。 |
| 用例 | 2.2、2.8、2.15 |
| 依赖项 | - |
| 支撑材料 | - |
3.5.11. 应提供为公共符号定义命名约定的能力¶
| 描述 | 标准化模板应提供为公共符号定义命名约定的能力。这尤其包括版本的文档中使用的需求 id、模块缩写、元数据和配置符号。 |
|---|---|
| 理由 | 避免规范内部的歧义和名称冲突。向规范的读者提供元数据的一致统一呈现。允许对规范元素进行自动化处理。 |
| 用例 | 2.9 |
| 依赖项 | - |
| 支撑材料 | - |
3.5.12. 标准化模板应规定 AUTOSAR 模板文档中建议项的表示¶
| 描述 | 规定 AUTOSAR 文档和 AUTOSAR 元模型中建议项的内容。 |
|---|---|
| 理由 | 在 AUTOSAR 中一致地规范和表示建议项。 |
| 用例 | 2.21 |
| 依赖项 | - |
| 支撑材料 | - |
3.6. 数据交换点的 Profile¶
3.6.1. 数据交换点的描述应提供人类可读的高层概览¶
| 描述 | 标准化模板应支持对数据交换点的人类可读的抽象概览的描述。该概览预期为自由文本。 |
|---|---|
| 理由 | 向用户提供关于 profile 范围的简要信息。使用户能够判断某个 profile 是否适用于预期的数据交换点。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.2. 数据交换点的描述应在方法论中描述工作产品¶
| 描述 | 标准化模板应支持对方法论中工作产品（即工件或交付物）的描述，该工作产品由数据交换点的描述表示。例如通过自由文本结合引用方法论模型中的工件。 |
|---|---|
| 理由 | 应当清楚 profile 适用于 AUTOSAR 方法论中的哪些工件。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.3. 数据交换点的描述应描述预期用途¶
| 描述 | 标准化模板应支持对预期用途的描述。（例如通过自由文本结合引用方法论模型中的工作定义（活动和任务）、BSW 模块，甚至 BSW 需求列表） |
|---|---|
| 理由 | 定义 profile 的范围以及它在方法论中适用的过程步骤。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | VFB 规范——「VFB 特性与 Profile」一节，RS/SRS 需求 |
3.6.4. 数据交换点的描述应描述工具和组织¶
| 描述 | 标准化模板应支持对 profile 所代表的工具和组织的描述。示例有： * Profile P1 描述工具 A 在版本 B 中、由组织 C 在项目 D 中使用时可能的输出 * Profile P2 描述由 AUTOSAR 定义的消费者的统一化参考 profile * Profile P3 描述由一组具有特定版本和配置的工具所支持的数据交换点的统一化子集 |
|---|---|
| 理由 | 帮助将 profile 与实际的工具、组织或项目关联的管理数据。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | ASAM ProjectData |
3.6.5. 数据交换点的描述应描述 AUTOSAR 版本¶
| 描述 | 标准化模板应支持对 profile 中的规则所关联的 AUTOSAR 版本的描述。 |
|---|---|
| 理由 | 规定作为整个 profile 基线的 AUTOSAR 版本。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.6. 数据交换点的描述应描述 AUTOSAR 元模型的相关或被排除的子集¶
| 描述 | 标准化模板应支持对与数据交换点相关的元模型子集的描述。 |
|---|---|
| 理由 | 记录元模型的哪些部分在方法论的特定步骤中涉及。有助于避免互操作性问题： * 在未裁剪的情况下应用严格的 XML schema * 缺失元素/属性 * 无内容的结构和孤立项——未定义的行为 * 信息丢失 * 未实现 AUTOSAR 特性或建模模式 * 在 ECU 配置中而不是在上游模板中进行配置 * 表达同一事物的多种可能性 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.7. 数据交换点的描述应描述模型的相关或被排除的子集¶
| 描述 | 标准化模板应支持对与数据交换点相关的模型子集的描述。（例如通过显式定义如何在模型中导航） |
|---|---|
| 理由 | 区分方法论中预期步骤执行所需、需要验证的数据，与（尚）未使用、不需要验证的数据。有助于避免互操作性问题： * 在未裁剪的情况下应用严格的 XML schema * 缺失元素/属性 * 无内容的结构和孤立项——未定义的行为 * 信息丢失 * 未实现 AUTOSAR 特性或建模模式 * 在 ECU 配置中而不是在上游模板中进行配置 * 表达同一事物的多种可能性 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.8. 数据交换点的描述应描述相关约束¶
| 描述 | 标准化模板应支持对与数据交换点相关的约束的描述。 |
|---|---|
| 理由 | 降低由以下原因引发的互操作性问题的风险： * 对约束的不同解释或选择 * 未实现所需的 AUTOSAR 功能 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.9. 数据交换点的描述应描述相关规范项¶
| 描述 | 标准化模板应支持对与数据交换点相关的、来自所有模板规范的规范项的描述。 |
|---|---|
| 理由 | 某些规范项具有可检查约束的性质。或者，规范项的选择记录了所支持的 AUTOSAR 能力。降低由以下原因引发的互操作性问题的风险： * 对规范项的不同解释或选择 * 未实现所需的 AUTOSAR 功能 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.10. 数据交换点的描述应描述模型完整性¶
| 描述 | 标准化模板应支持对数据交换点处数据完整性的描述。（例如通过按交换点精化元模型引用和属性的下多重性的语义） |
|---|---|
| 理由 | 如果没有为某个数据交换点规定完整性，则工具链中的消费工具可能需要生产工具未提供的信息。避免由对所需模型元素和特性的不同解释引起的互操作性问题。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.11. 数据交换点的描述应描述默认值的适用性¶
| 描述 | 标准化模板应支持描述 AUTOSAR 模型的消费者何时应应用 AUTOSAR 定义的默认值。例如「在版本更新时应用」「从不应用」「总是应用」。 |
|---|---|
| 理由 | 克服当前 AUTOSAR 定义的默认值较弱的语义。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.12. 数据交换点的描述应描述原始类型属性值的限制¶
| 描述 | 标准化模板应支持在特定数据交换点的特定上下文中、对具有原始数据类型的属性的值施加限制的描述（例如限制 category 或某个枚举的值）。 |
|---|---|
| 理由 | 消费工具可能只支持枚举值的一个子集或有限的参数范围。例如，消费工具只支持可能的 CATEGORY 值的一个子集。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.13. 数据交换点的描述应支持 Profile 单条规则符合性的严重级别¶
| 描述 | 标准化模板应支持对每条规则的严重级别的描述： * 错误（error）：模型元素被认为与 profile 不兼容 * 警告（warning）：模型元素可疑，但过程步骤可以继续 * 信息（info）：当规则适用但对过程步骤没有影响时，例如「未为变量 x 指定单位」 |
|---|---|
| 理由 | 并非模型与 profile 的每一处不一致都应阻塞工作流。在开发的早期阶段，对消费者来说某些数据缺失可能是可接受的。然而，此类问题应作为警告被报告。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.14. 数据交换点的描述应描述决策的理由¶
| 描述 | 标准化模板应支持对特定数据交换点中记录的任何决策的理由的描述。 |
|---|---|
| 理由 | 提供关于为什么某条特定规则是 profile 的一部分、以及为什么做出该决策的附加信息。这支持可维护性，并有助于关于工具不兼容性的讨论。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.15. 数据交换点的描述应描述 AUTOSAR 扩展机制的用法¶
| 描述 | 标准化模板应支持对特定数据交换点的 AUTOSAR 扩展机制（Category、SDG）用法的描述。这包括对扩展预期用途的文字文档记录，包括在较新的 AUTOSAR 规范版本中指向相关规范项和元类的交叉引用。 |
|---|---|
| 理由 | Category 和 SDG 是 AUTOSAR 元模型中的标准模式。当标准中没有预见某些内容时，它为项目特定的工作流提供了一种解决方案。然而，此类扩展与数据交换点处的互操作性相关，应当可以用 profile 对它们进行验证。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.16. AUTOSAR 应提供比较数据交换点 Profile 的指南¶
| 描述 | 标准化模板应定义在不同抽象层级上比较/对比（diff）profile 的指南。这些指南就如何高效地解释两个 profile 的差异、或如何创建一个简化比较的组合 profile 的规范化版本提供提示。 |
|---|---|
| 理由 | 用于描述 profile 的语言支持不同的形式化程度。某些部分被有意描述为自由文本，其他部分则针对被工具处理进行了优化。这允许确定例如同一工具的不同版本之间的修改。此外，这些规则可以限制分析 profile 之间差异的工作量：例如，如果在特性层级的比较发现大的不兼容性，则不再需要进行属性层级的比较。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.17. AUTOSAR 应提供数据交换点 Profile 兼容性的指南¶
| 描述 | 标准化模板应定义在不同抽象层级上检查 profile 兼容性的指南。 |
|---|---|
| 理由 | 与编程语言中的接口兼容性类似，并不总是需要拥有相同的接口。通常接口兼容就足够了。例如： * 生产者可以提供比消费者所需的更多的数据 * 如果消费者需要某些生产者未提供的数据，则两个工具不兼容 此外，这些规则可以限制分析 profile 之间不兼容性的工作量：例如，如果 profile 在特性层级不兼容，则可以从此层级开始讨论，然后再处理单个属性或约束。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.18. AUTOSAR 应提供处理不完整数据交换点 Profile 的支持¶
| 描述 | 标准化模板应定义如何比较、检查兼容性或检查不完整 profile 的可组合性的规则。 |
|---|---|
| 理由 | 在 AUTOSAR 的背景下，可能无法就 profile 的所有方面达成一致。然而，在进一步精化 AUTOSAR 所提供 profile 的较小群体的背景下达成一致是可能的。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.19. AUTOSAR 应提供检查 AUTOSAR 模型对数据交换点 Profile 符合性的指导¶
| 描述 | 标准化模板应定义检查 AUTOSAR 模型对给定 profile 符合性的指导。 |
|---|---|
| 理由 | 检查交换的数据是否符合约定的契约。克服对照严格 XML schema 检查的局限。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.20. AUTOSAR 应提供组合数据交换点 Profile 的规则¶
| 描述 | 标准化模板应定义组合多个 profile 的规则。 |
|---|---|
| 理由 | profile 的模块化、组合多个消费工具的 profile。例如：如果一个工具需要某些数据而另一个工具将这些数据视为无关紧要，这是可接受的。 例如：如果一个工具需要某些数据而另一个工具将其排除，则发生冲突。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.21. AUTOSAR 应提供识别数据交换点 Profile 中尚未描述方面的指导¶
| 描述 | 标准化模板应规定有助于识别数据交换点中尚未描述方面的指南。 |
|---|---|
| 理由 | profile 允许引用 AUTOSAR 规范中提到的规范项、约束、元类等。该指南例如就如何利用 AUTOSAR 规范中的既有信息来查找相关信息（例如通过上游映射、交叉引用、技术术语等）提供指导。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
3.6.22. AUTOSAR 应提供数据交换点 Profile 一致性的指南¶
| 描述 | 标准化模板应为数据交换点的 profile 定义一致性指南。 |
|---|---|
| 理由 | profile 的各部分相互依赖。例如，只有当相关属性是相关的时候，才需要关于默认值的陈述。只有当元类可以通过包含引用从类 AUTOSAR 到达时，才需要关于元类完整性的陈述。 |
| 用例 | 2.20 |
| 依赖项 | - |
| 支撑材料 | - |
4. 提及的类表格¶
出于完整性的考虑，本章包含一组类表格，代表在本文档上下文中被提及、但不直接包含在描述特定元模型语义范围之内的元类。
表A.1：DataPrototype
| 属性 | 内容 |
|---|---|
| 类 | DataPrototype（抽象） |
| 包 | M2::AUTOSARTemplates::SWComponentTemplate::Datatype::DataPrototypes |
| 注 | 任何数据类型的原型角色的基类。 |
| 基类 | ARObject、AtpFeature、AtpPrototype、Identifiable、MultilanguageReferrable、Referrable |
| 子类 | ApplicationCompositeElementDataPrototype、AutosarDataPrototype |
| 被聚合于 | AtpClassifier.atpFeature |
| 属性 | 类型 | 多重性 | 种类 | 注 |
|---|---|---|---|---|
| swDataDefProps | SwDataDefProps | 0..1 | aggr | 该属性允许指定在数据原型层级上应用的数据定义属性。构造型（Stereotypes）：atpSplitable；标签（Tags）：atp.Splitkey=swDataDefProps |
表A.2：RunnableEntity
| 属性 | 内容 |
|---|---|
| 类 | RunnableEntity |
| 包 | M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior |
| 注 | RunnableEntity 表示由 AtomicSwComponentType 提供的、在 RTE 控制下执行的最小代码片段。RunnableEntity 的设置例如用于响应数据接收或服务器上的操作调用。 |
| 基类 | ARObject、AtpClassifier、AtpFeature、AtpStructureElement、ExecutableEntity、Identifiable、MultilanguageReferrable、Referrable |
| 被聚合于 | AtpClassifier.atpFeature、SwcInternalBehavior.runnable |
| 属性 | 类型 | 多重性 | 种类 | 注 |
|---|---|---|---|---|
| argument（有序） | RunnableEntityArgument | * | aggr | 这表示 RunnableEntity 的参数的形式化定义。 |
| canBeInvokedConcurrently | Boolean | 0..1 | attr | 如果该属性的值被设置为 "true"，则外层的 RunnableEntity 可以被并发调用（即使对于对应 AtomicSwComponentType 的一个实例也是如此）。这意味着由 RunnableEntity 的实现负责处理这种形式的并发。 |
| dataReadAccess | VariableAccess | * | aggr | RunnableEntity 对发送方-接收方 PortPrototype 的 dataElement 或 nv 数据 PortPrototype 的 nv 数据拥有隐式读访问。dataReadAccess 的聚合受变体支配，目的是支持实现中发送方-接收方端口的条件性存在或 dataReadAccess 的变体存在。构造型：atpSplitable; atpVariation；标签：atp.Splitkey=dataReadAccess.shortName, dataReadAccess.variationPoint.shortLabel vh.latestBindingTime=preCompileTime |
| dataReceivePointByArgument | VariableAccess | * | aggr | RunnableEntity 对发送方-接收方 PortPrototype 的 dataElement 或 nv 数据 PortPrototype 的 nv 数据拥有显式读访问。结果通过函数签名中的一个参数传回应用。dataReceivePointByArgument 的聚合受变体支配，目的是支持实现中发送方-接收方 PortPrototype 的条件性存在或数据接收点的变体存在。构造型：atpSplitable; atpVariation；标签：atp.Splitkey=dataReceivePointByArgument.shortName, dataReceivePointByArgument.variationPoint.shortLabel vh.latestBindingTime=preCompileTime |
| dataReceivePointByValue | VariableAccess | * | aggr | RunnableEntity 对发送方-接收方 PortPrototype 的 dataElement 或 nv 数据 PortPrototype 的 nv 数据拥有显式读访问。结果通过返回值传回应用。dataReceivePointByValue 的聚合受变体支配，目的是支持实现中发送方-接收方端口的条件性存在或数据接收点的变体存在。构造型：atpSplitable; atpVariation；标签：atp.Splitkey=dataReceivePointByValue.shortName, dataReceivePointByValue.variationPoint.shortLabel |
| dataSendPoint | VariableAccess | * | aggr | RunnableEntity 对发送方-接收方 PortPrototype 的 dataElement 或 nv 数据 PortPrototype 的 nv 数据拥有显式写访问。dataSendPoint 的聚合受变体支配，目的是支持实现中发送方-接收方 PortPrototype 的条件性存在或数据发送点的变体存在。构造型：atpSplitable; atpVariation；标签：atp.Splitkey=dataSendPoint.shortName, dataSendPoint.variationPoint.shortLabel vh.latestBindingTime=preCompileTime |
| dataWriteAccess | VariableAccess | * | aggr | RunnableEntity 对发送方-接收方 PortPrototype 的 dataElement 或 nv 数据 PortPrototype 的 nv 数据拥有隐式写访问。dataWriteAccess 的聚合受变体支配，目的是支持实现中发送方-接收方端口的条件性存在或 dataWriteAccess 的变体存在。构造型：atpSplitable; atpVariation；标签：atp.Splitkey=dataWriteAccess.shortName, dataWriteAccess.variationPoint.shortLabel |
| externalTriggeringPoint | ExternalTriggeringPoint | * | aggr | ExternalTriggeringPoint 的聚合受变体支配，目的是支持实现中触发端口的条件性存在或外部触发点的变体存在。构造型：atpSplitable; atpVariation；标签：atp.Splitkey=externalTriggeringPoint.ident.shortName, externalTriggeringPoint.variationPoint.shortLabel vh.latestBindingTime=preCompileTime |
| internalTriggeringPoint | InternalTriggeringPoint | * | aggr | InternalTriggeringPoint 的聚合受变体支配，目的是支持实现中内部触发点的变体存在。构造型：atpSplitable; atpVariation；标签：atp.Splitkey=internalTriggeringPoint.shortName, internalTriggeringPoint.variationPoint.shortLabel vh.latestBindingTime=preCompileTime |
| modeAccessPoint | ModeAccessPoint | * | aggr | 该可运行体拥有一个模式访问点。ModeAccessPoint 的聚合受变体支配，目的是支持实现中模式端口的条件性存在或模式访问点的变体存在。构造型：atpSplitable; atpVariation；标签：atp.Splitkey=modeAccessPoint.ident.shortName, modeAccessPoint.variationPoint.shortLabel vh.latestBindingTime=preCompileTime |
| modeSwitchPoint | ModeSwitchPoint | * | aggr | 该可运行体拥有一个模式切换点。ModeSwitchPoint 的聚合受变体支配，目的是支持实现中模式端口的条件性存在或模式切换点的变体存在。构造型：atpSplitable; atpVariation；标签：atp.Splitkey=modeSwitchPoint.shortName, modeSwitchPoint.variationPoint.shortLabel vh.latestBindingTime=preCompileTime |
| parameterAccess | ParameterAccess | * | aggr | ParameterAccess 的存在意味着 RunnableEntity 需要对 ParameterDataPrototype 的只读访问，后者可以是本地的，也可以位于某个 PortPrototype 内。ParameterAccess 的聚合受变体支配，目的是支持实现中参数端口和组件本地参数的条件性存在以及 ParameterAccess（点）的变体存在。构造型：atpSplitable; atpVariation；标签：atp.Splitkey=parameterAccess.shortName, parameterAccess.variationPoint.shortLabel vh.latestBindingTime=preCompileTime |
| readLocalVariable | VariableAccess | * | aggr | readLocalVariable 的存在意味着 RunnableEntity 需要对作为 implicitInterRunnableVariable 或 explicitInterRunnableVariable 角色的 VariableDataPrototype 的读访问。readLocalVariable 的聚合受变体支配，目的是支持实现中 implicitInterRunnableVariable 和 explicitInterRunnableVariable 的条件性存在或 readLocalVariable（点）的变体存在。构造型：atpSplitable; atpVariation；标签：atp.Splitkey=readLocalVariable.shortName, readLocalVariable.variationPoint.shortLabel vh.latestBindingTime=preCompileTime |
| symbol | CIdentifier | 0..1 | attr | 描述该 RunnableEntity 入口的符号。它被视为 RunnableEntity 的 API，并在 RTE 契约阶段需要。 |
| waitPoint | WaitPoint | * | aggr | 与该 RunnableEntity 关联的 WaitPoint。 |
| writtenLocalVariable | VariableAccess | * | aggr | writtenLocalVariable 的存在意味着 RunnableEntity 需要对作为 implicitInterRunnableVariable 或 explicitInterRunnableVariable 角色的 VariableDataPrototype 的写访问。writtenLocalVariable 的聚合受变体支配，目的是支持实现中 implicitInterRunnableVariable 和 explicitInterRunnableVariable 的条件性存在或 writtenLocalVariable（点）的变体存在。构造型：atpSplitable; atpVariation；标签：atp.Splitkey=writtenLocalVariable.shortName, writtenLocalVariable.variationPoint.shortLabel vh.latestBindingTime=preCompileTime |
B. 变更历史¶
请注意，本章中的列表还包括在后续版本中已从规范中移除的约束和规范项。这些约束和规范项在文档中不作为超链接出现。
由于本批次决议整体省略需求项 ID，本附录变更表的 Number/Id 列省略，仅保留标题列。
B.1. R4.1.1 的变更历史¶
B.1.1. 4.1.1 中新增的用例¶
表B.1：4.1.1 中新增的用例
| 标题 |
|---|
| 在 AUTOSAR 中管理需求 |
B.1.2. 4.1.1 中新增的需求¶
表B.2：4.1.1 中新增的需求
| 标题 |
|---|
| 应支持通用规范项 |
| 应能够为角色和权限提供蓝图 |
| 应能够为构建动作清单提供蓝图 |
| 隐式通信行为的蓝图化 |
| 应支持关键字的蓝图化 |
| 标准化模板应规定 AUTOSAR 文档中需求的表示 |
B.2. R4.1.2 的变更历史¶
B.2.1. 4.1.2 中新增的用例¶
表B.3：4.1.2 中新增的用例
| 标题 |
|---|
| 在 AUTOSAR 中管理规范项 |
| 在 AUTOSAR 中管理约束项 |
B.2.2. 4.1.2 中新增的需求¶
表B.4：4.1.2 中新增的需求
| 标题 |
|---|
| 标准化模板应规定 AUTOSAR 文档中规范项的表示 |
| 标准化模板应规定 AUTOSAR 文档中约束项的表示 |
B.3. R4.1.3 的变更历史¶
B.3.1. 4.1.3 中新增的用例¶
无。
B.3.2. 4.1.3 中新增的需求¶
无。
B.4. R4.2.1 的变更历史¶
B.4.1. 4.2.1 中新增的需求¶
表B.5：4.2.1 中新增的可追溯项
| 标题 |
|---|
| 标准化模板应规定 AUTOSAR 文档中测试项的表示 |
| 派生对象中元素的多重性 |
| BSW 抽象 SWS 的形式化描述 |
| 应提供为公共符号定义命名约定的能力 |
| 在 AUTOSAR 中管理测试项 |
B.4.2. 4.2.1 中变更的需求¶
表B.6：4.2.1 中变更的可追溯项
| 标题 |
|---|
| 应总体上支持并解释蓝图 |
| BSW SWS 的形式化描述 |
| 应允许表示端口蓝图 |
| 应允许表示 shortName 模式 |
| 应支持关键字和关键字缩写 |
| 应在不与现有模板产生兼容性问题的前提下实现 |
| 应基于 AUTOSAR schema |
| 应提供支持分析实现与 AUTOSAR 标准符合性的手段 |
| 应能够表示 SWS 中陈述的需求 |
| 应引用 ECUC 参数定义 |
| 应能够标准化组件 |
| 应能够标准化架构 |
| 应能够表达引用路径和包层级的部分内容 |
| 应能够表达义务层级 |
| 应支持从蓝图派生的不同方式 |
| 应能够表达关于模型元素状态的信息 |
| 应涵盖蓝图与派生对象的兼容性 |
| 应允许描述 API 的依赖关系（例如调用和回调/轮询接口） |
| 应为蓝图定义强制性语义 |
| 应支持 VariableDataprototype 的变体 |
| 应支持带有 PortBlueprint 的示例 SWC 的多重实例化 |
| 利益相关方之间蓝图交换格式的方式 |
| 应能够标准化别名 |
| 应能够标准化唯一名称和显示名称 |
| 应能够标准化生命周期状态 |
| 应允许表示端口接口蓝图 |
| 应允许评估蓝图的完整性 |
| 应允许从模型生成 BSW「标准 AUTOSAR 接口」描述 |
| 应能够表示更多的蓝图 |
| 应允许标准化包结构 |
| 应支持通用规范项 |
| 应能够为角色和权限提供蓝图 |
| 应能够为构建动作清单提供蓝图 |
| 隐式通信行为的蓝图化 |
| 应支持关键字的蓝图化 |
| 标准化模板应规定 AUTOSAR 文档中需求的表示 |
| 标准化模板应规定 AUTOSAR 文档中规范项的表示 |
| 标准化模板应规定 AUTOSAR 文档中约束项的表示 |
| 表达已应用标准的示例 |
B.4.3. 4.2.1 中删除的需求¶
无。
B.5. R4.2.2 的变更历史¶
B.5.1. 4.2.2 中新增的需求¶
无。
B.5.2. 4.2.2 中变更的需求¶
无。
B.5.3. 4.2.2 中删除的需求¶
无。
B.6. R4.3.0 的变更历史¶
B.6.1. 4.3.0 中新增的需求¶
表B.7：4.3.0 中新增的可追溯项
| 标题 |
|---|
| 数据交换点的描述应提供人类可读的高层概览 |
| 数据交换点的描述应在方法论中描述工作产品 |
| 数据交换点的描述应描述预期用途 |
| 数据交换点的描述应描述工具和组织 |
| 数据交换点的描述应描述 AUTOSAR 版本 |
| 数据交换点的描述应描述 AUTOSAR 元模型的相关或被排除的子集 |
| 数据交换点的描述应描述模型的相关或被排除的子集 |
| 数据交换点的描述应描述相关约束 |
| 数据交换点的描述应描述相关规范项 |
| 数据交换点的描述应描述模型完整性 |
| 数据交换点的描述应描述默认值的适用性 |
| 数据交换点的描述应描述原始类型属性值的限制 |
| 数据交换点的描述应支持 Profile 单条规则符合性的严重级别 |
| 数据交换点的描述应描述决策的理由 |
| 数据交换点的描述应描述 AUTOSAR 扩展机制的用法 |
| AUTOSAR 应提供比较数据交换点 Profile 的指南 |
| AUTOSAR 应提供数据交换点 Profile 兼容性的指南 |
| AUTOSAR 应提供组合数据交换点 Profile 的规则 |
| AUTOSAR 应提供处理不完整数据交换点 Profile 的支持 |
| AUTOSAR 应提供检查 AUTOSAR 模型对数据交换点 Profile 符合性的指导 |
| AUTOSAR 应提供识别数据交换点 Profile 中尚未描述方面的指导 |
| AUTOSAR 应提供数据交换点 Profile 一致性的指南 |
| 支持 AUTOSAR 特定的建模模式 |
B.6.2. 4.3.0 中变更的需求¶
表B.8：4.3.0 中变更的可追溯项
| 标题 |
|---|
| 应基于 AUTOSAR XML schema |
B.6.3. 4.3.0 中删除的需求¶
无。
B.7. R4.3.1 的变更历史¶
B.7.1. 4.3.1 中新增的需求¶
无。
B.7.2. 4.3.1 中变更的需求¶
无。
B.7.3. 4.3.1 中删除的需求¶
无。
B.8. R21-11 的变更历史¶
B.8.1. R21-11 中新增的需求¶
无。
B.8.2. R21-11 中变更的需求¶
无。
B.8.3. R21-11 中删除的需求¶
无。
B.8.4. R21-11 中新增的约束¶
无。
B.8.5. R21-11 中变更的约束¶
无。
B.8.6. R21-11 中删除的约束¶
无。
B.9. R22-11 的变更历史¶
B.9.1. R22-11 中新增的需求¶
表B.9：R22-11 中新增的需求
| 标题 |
|---|
| 标准化模板应规定 AUTOSAR 模板文档中建议项的表示 |
| 在 AUTOSAR 中管理建议项 |
B.9.2. R22-11 中变更的需求¶
无。
B.9.3. R22-11 中删除的需求¶
无。
B.9.4. R22-11 中新增的约束¶
无。
B.9.5. R22-11 中变更的约束¶
无。
B.9.6. R22-11 中删除的约束¶
无。
B.10. R23-11 的变更历史¶
B.10.1. R23-11 中新增的需求¶
无。
B.10.2. R23-11 中变更的需求¶
无。
B.10.3. R23-11 中删除的需求¶
无。
B.10.4. R23-11 中新增的约束¶
无。
B.10.5. R23-11 中变更的约束¶
无。
B.10.6. R23-11 中删除的约束¶
无。