1543 lines
78 KiB
Markdown
1543 lines
78 KiB
Markdown
# AUTOSAR 标准化模板需求
|
||
|
||
> **AUTOSAR CP Release 4.4.0**
|
||
>
|
||
> 原文：*Requirements on Standardization Template*（文档 ID 536）
|
||
>
|
||
> 翻译状态：**已完成 v1**（封面+前言+目录+章节 1-3 + 附录 A、B 完整翻译；所有需求表格已汉化）
|
||
>
|
||
> 对应原文 PDF：`MethodologyAndTemplates/AUTOSAR_RS_StandardizationTemplate.pdf`
|
||
>
|
||
> 翻译日期：Step 3 - P0 批量翻译
|
||
|
||
---
|
||
|
||
## 文档标识
|
||
|
||
| 字段 | 值 |
|
||
|------|-----|
|
||
| 文档标题（Document Title） | 标准化模板需求（Requirements on Standardization Template） |
|
||
| 文档所有者（Document Owner） | AUTOSAR |
|
||
| 文档责任人（Document Responsibility） | AUTOSAR |
|
||
| 文档标识号（Document Identification No） | 536 |
|
||
| 文档状态（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 | • 编辑性变更 |
|
||
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | • 编辑性变更 |
|
||
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | • Profiles for Data Exchange Points（数据交换点的配置文件）<br>• 重组章节<br>• 编辑性变更 |
|
||
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | • 编辑性变更 |
|
||
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | • 扩展可追溯性到新的文档工件 |
|
||
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | • 编辑性变更 |
|
||
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | • 编辑性变更<br>• 改进文档可追溯性 |
|
||
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | • 编辑性变更<br>• 改进文档可追溯性 |
|
||
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | • 初始发布 |
|
||
|
||
---
|
||
|
||
## 目录
|
||
|
||
1. [引言（Introduction）](#1-引言introduction)
|
||
- 1.1 [文档约定（Document Conventions）](#11-文档约定document-conventions)
|
||
- 1.2 [指南（Guidelines）](#12-指南guidelines)
|
||
- 1.3 [用例追溯（Use Case Tracing）](#13-用例追溯use-case-tracing)
|
||
- 1.4 [需求追溯（Requirements Tracing）](#14-需求追溯requirements-tracing)
|
||
2. [用例（Use Cases）](#2-用例use-cases)
|
||
3. [需求（Requirements）](#3-需求requirements)
|
||
- 3.1 [蓝图（Blueprints）](#31-蓝图blueprints)
|
||
- 3.2 [关键字（Keywords）](#32-关键字keywords)
|
||
- 3.3 [AUTOSAR 集成与生命周期（AUTOSAR Integration and Lifecycle）](#33-autosar-集成与生命周期autosar-integration-and-lifecycle)
|
||
- 3.4 [可追溯性（Traceability）](#34-可追溯性traceability)
|
||
- 3.5 [规范元素的文档化（Documentation of Specification Elements）](#35-规范元素的文档化documentation-of-specification-elements)
|
||
- 3.6 [数据交换点的配置文件（Profiles for Data Exchange Points）](#36-数据交换点的配置文件profiles-for-data-exchange-points)
|
||
- [附录 A 变更历史（Change History）](#附录-a-变更历史change-history)
|
||
- [附录 B 引用的类表（Mentioned Class Tables）](#附录-b-引用的类表mentioned-class-tables)
|
||
|
||
---
|
||
|
||
## 参考文献（References）
|
||
|
||
- [1] Software Component Template，AUTOSAR_TPS_SoftwareComponentTemplate
|
||
- [2] Standardization Template，AUTOSAR_TPS_StandardizationTemplate
|
||
- [3] Requirements on AUTOSAR Features，AUTOSAR_RS_Features
|
||
- [4] Main Requirements，AUTOSAR_RS_Main
|
||
- [5] Specification of ECU Configuration，AUTOSAR_TPS_ECUConfiguration
|
||
- [6] Specification of Platform Types，AUTOSAR_SWS_PlatformTypes
|
||
- [7] Generic Structure Template，AUTOSAR_TPS_GenericStructureTemplate
|
||
- [8] XML Specification of Application Interfaces，AUTOSAR_MOD_AISpecification
|
||
- [9] SW-C and System Modeling Guide，AUTOSAR_TR_SWCModelingGuide
|
||
- [10] Requirements on Interoperability of AUTOSAR Tools，AUTOSAR_RS_InteroperabilityOfAutosarTools
|
||
|
||
> 注：被引用的可交付物 AUTOSAR_RS_InteroperabilityOfAutosarTools 在 4.4.0 版本中状态被设为 obsolete（已废弃）。
|
||
|
||
---
|
||
|
||
## 1 引言（Introduction）
|
||
|
||
AUTOSAR 模型在许多情况下并非从零开始创建，而是以现有内容为基础。这些现有内容可以由 AUTOSAR 计划本身以标准化模型元素的形式提供。
|
||
|
||
本文档规定了**标准化模板**（Standardization Template）的需求。该模板旨在支持 AUTOSAR 提供标准化的模型元素。
|
||
|
||
AUTOSAR 4.0 已经规定了用于标准化的蓝图方法（blueprint approach）。标准化模板延续并细化了此方法。因此，它将取代《Software Component Template》[1] 的附录 A。
|
||
|
||
作为一个特殊例子，让我们考虑一下应用接口的标准化。即，就 AUTOSAR 元模型而言，标准化主要应用于为特定目的定义 PortPrototypes。
|
||
|
||
由于 AUTOSAR 元模型的结构，不可能仅表示一个标准化的 PortPrototype，因为出于合理的原因，PortPrototype 本身并不独立存在，而是始终由一个 SwComponentType 所拥有。标准化模板规定了克服这种情况的方法。
|
||
|
||
---
|
||
|
||
### 1.1 文档约定（Document Conventions）
|
||
|
||
AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中规定的表格，详见《Standardization Template》[2] 的"Support for Traceability"一章。
|
||
|
||
用于表达义务的动词形式应遵循 [TPS_STDT_00053] 的规定，用以表示需求，详见《Standardization Template》[2] 的"Support for Traceability"一章。
|
||
|
||
---
|
||
|
||
### 1.2 指南（Guidelines）
|
||
|
||
应引用现有规范（以单一需求的形式）。与这些规范的差异被规定为附加需求。所有需求应具有以下属性：
|
||
|
||
- **冗余性（Redundancy）**
|
||
需求不应在单一需求中或在不同需求之间重复。
|
||
- **清晰性（Clearness）**
|
||
所有需求应仅允许一种解释。所使用的、不在术语表中的技术术语必须予以定义。
|
||
- **原子性（Atomicity）**
|
||
每条需求应仅包含一个需求。如果某条需求无法被进一步拆分为更多需求，则该需求是原子的。
|
||
- **可测试性（Testability）**
|
||
需求应能通过分析、评审或测试进行测试。
|
||
- **可追溯性（Traceability）**
|
||
需求来源和状态应始终可见。
|
||
|
||
---
|
||
|
||
### 1.3 用例追溯（Use Case Tracing）
|
||
|
||
下表引用所规定的用例，并将其与相关的需求联系起来。
|
||
|
||
| 用例 | 描述 | 满足者 |
|
||
|------|------|--------|
|
||
| [UC_STDT_00001] | 支持应用接口 | [RS_STDT_00001] [RS_STDT_00003] [RS_STDT_00005] [RS_STDT_00006] [RS_STDT_00007] [RS_STDT_00016] [RS_STDT_00019] [RS_STDT_00020] [RS_STDT_00021] [RS_STDT_00022] [RS_STDT_00026] [RS_STDT_00035] |
|
||
| [UC_STDT_00002] | 表达 SWS 的部分 | [RS_STDT_00001] [RS_STDT_00002] [RS_STDT_00018] [RS_STDT_00041] |
|
||
| [UC_STDT_00003] | 标准化 ECUC 参数 | [RS_STDT_00001] [RS_STDT_00010] [RS_STDT_00029] |
|
||
| [UC_STDT_00004] | 表达预定义路径 | [RS_STDT_00001] [RS_STDT_00013] [RS_STDT_00030] |
|
||
| [UC_STDT_00005] | 表达平台类型 | [RS_STDT_00001] |
|
||
| [UC_STDT_00006] | 表达已应用标准的示例 | [RS_STDT_00001] |
|
||
| [UC_STDT_00007] | 支持验证实现是否遵循已定义标准 | [RS_STDT_00001] [RS_STDT_00008] [RS_STDT_00009] [RS_STDT_00015] [RS_STDT_00017] |
|
||
| [UC_STDT_00008] | 支持可重用文档 | [RS_STDT_00001] [RS_STDT_00002] [RS_STDT_00003] [RS_STDT_00023] [RS_STDT_00026] [RS_STDT_00041] |
|
||
| [UC_STDT_00009] | 定义命名约定 | [RS_STDT_00001] [RS_STDT_00004] [RS_STDT_00014] [RS_STDT_00023] [RS_STDT_00024] [RS_STDT_00025] [RS_STDT_00042] |
|
||
| [UC_STDT_00010] | 在 AUTOSAR 范围之外的层级执行标准化 | [RS_STDT_00011] [RS_STDT_00012] [RS_STDT_00024] [RS_STDT_00025] [RS_STDT_00032] [RS_STDT_00033] |
|
||
| [UC_STDT_00011] | 通过手动更改属性从蓝图派生对象 | [RS_STDT_00015] [RS_STDT_00029] [RS_STDT_00040] |
|
||
| [UC_STDT_00012] | 以完全标准化的方式从蓝图派生对象 | [RS_STDT_00015] [RS_STDT_00029] [RS_STDT_00040] |
|
||
| [UC_STDT_00013] | 集成编译测试 | [RS_STDT_00027] |
|
||
| [UC_STDT_00014] | 从模型生成 BSW"标准 AUTOSAR 接口"描述 | [RS_STDT_00028] |
|
||
| [UC_STDT_00015] | 处理通用规范条目 | [RS_STDT_00031] [RS_STDT_00041] |
|
||
| [UC_STDT_00016] | 在 AUTOSAR 中管理需求 | [RS_STDT_00036] |
|
||
| [UC_STDT_00017] | 在 AUTOSAR 中管理规范条目 | [RS_STDT_00037] |
|
||
| [UC_STDT_00018] | 在 AUTOSAR 中管理约束条目 | [RS_STDT_00038] |
|
||
| [UC_STDT_00019] | 在 AUTOSAR 中管理测试条目 | [RS_STDT_00039] |
|
||
|
||
> **表 1.1：用例追溯（Use Case Tracing）**
|
||
|
||
---
|
||
|
||
### 1.4 需求追溯（Requirements Tracing）
|
||
|
||
下表引用 [3]、[4] 中规定的需求，并将其与本文档对它们的实现联系起来。
|
||
|
||
| 需求 | 描述 | 满足者 |
|
||
|------|------|--------|
|
||
| [RS_BRF_01024] | AUTOSAR 应为公共符号提供命名规则 | [RS_STDT_00042] |
|
||
| [RS_BRF_01056] | AUTOSAR BSW 模块应提供标准化的接口 | [RS_STDT_00028] |
|
||
| [RS_BRF_01064] | AUTOSAR BSW 应提供回调函数以访问上层模块 | [RS_STDT_00018] |
|
||
| [RS_BRF_04000] | AUTOSAR 文档应支持可追溯性 | [RS_STDT_00013] [RS_STDT_00030] [RS_STDT_00041] |
|
||
| [RS_BRF_04008] | AUTOSAR 文档应支持一致性和质量保证 | [RS_STDT_00040] |
|
||
| [RS_BRF_04016] | AUTOSAR 应支持建模和文档指南 | [RS_STDT_00002] [RS_STDT_00004] [RS_STDT_00005] [RS_STDT_00006] [RS_STDT_00007] [RS_STDT_00008] [RS_STDT_00009] [RS_STDT_00011] [RS_STDT_00012] [RS_STDT_00014] [RS_STDT_00016] [RS_STDT_00020] [RS_STDT_00023] [RS_STDT_00024] [RS_STDT_00025] [RS_STDT_00031] [RS_STDT_00036] [RS_STDT_00037] [RS_STDT_00038] [RS_STDT_00039] |
|
||
| [RS_BRF_04024] | AUTOSAR 应支持应用规范的指南 | [RS_STDT_00001] [RS_STDT_00003] [RS_STDT_00010] [RS_STDT_00015] [RS_STDT_00017] [RS_STDT_00019] [RS_STDT_00021] [RS_STDT_00022] [RS_STDT_00026] [RS_STDT_00027] [RS_STDT_00029] [RS_STDT_00032] [RS_STDT_00033] [RS_STDT_00034] [RS_STDT_00035] |
|
||
| [RS_Main_00300] | AUTOSAR 应提供数据交换格式，以支持大型跨公司及公司内部开发组之间的分工 | [RS_STDT_00101] [RS_STDT_00102] [RS_STDT_00103] [RS_STDT_00104] [RS_STDT_00105] [RS_STDT_00106] [RS_STDT_00107] [RS_STDT_00108] [RS_STDT_00109] [RS_STDT_00110] [RS_STDT_00111] [RS_STDT_00113] [RS_STDT_00114] [RS_STDT_00115] [RS_STDT_00116] [RS_STDT_00117] [RS_STDT_00118] [RS_STDT_00119] [RS_STDT_00120] [RS_STDT_00121] [RS_STDT_00122] [RS_STDT_00123] [RS_STDT_00125] |
|
||
|
||
> **表 1.2：需求追溯（Requirements Tracing）**
|
||
|
||
---
|
||
|
||
## 2 用例（Use Cases）
|
||
|
||
本章描述标准化模板的用例。这些用例的意图是指出标准化模板的潜在应用。总体而言，标准化模板的用例是将 AUTOSAR 标准化项表达为 AUTOSAR XML 工件。该工件随后可用于支持开发符合 AUTOSAR 规范的产品。
|
||
|
||
本文档中定义的每个用例都有其唯一标识符，以"UC_STDT_"（即 Standardization Template Use Case）作为前缀。
|
||
|
||
#### ⌈[UC_STDT_00001] 支持应用接口⌋
|
||
|
||
AUTOSAR：为不同的领域（如底盘、动力总成、车身等）提供标准化的、公开披露的接口。这些接口的定义可以在各种深度层级上处理：
|
||
|
||
- L8：包括行为模型和端口的 SWC 完整描述
|
||
- L7：包括接口行为和数据质量的全部端口的完整描述
|
||
- L6：包括接口行为的文本描述和接口数据质量的全部端口的完整描述
|
||
- L5：包括接口数据质量的全部端口的完整描述
|
||
- L4：包括 AUTOSAR 内部已商定数据质量的全部端口的完整描述
|
||
- L3：包括 AUTOSAR 内部已商定数据质量的 SWC 端口/接口的部分描述
|
||
> 注意：此部分描述既包括只描述了部分端口这一事实，也包括对某个端口的描述不完整、且与适用组件相分离的事实。这也被称为 **PortBluePrint**。
|
||
- L2：包括一组 AUTOSAR 内部已商定数据质量的接口字典
|
||
- L1：包括类型和范围的数据元素字典
|
||
- L0：名称字典
|
||
|
||
自 Release 4.0 起，AUTOSAR 标准化涵盖 L0 … L3 层级。然而，供应商内部应用也可能使用标准化模板覆盖更高级别。
|
||
|
||
此用例主要涵盖应用软件方面。
|
||
|
||
应用此形式化描述将提高 AUTOSAR 应用接口的一致性和可用性，并强化形式化检查，例如对应用接口的向后兼容性检查。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00002] 表达 SWS 的部分⌋
|
||
|
||
标准化模板应允许使用 AUTOSAR 模式形式化地表达基础软件模块的 SWS 的部分。这包括（但不限于）：
|
||
|
||
- 标准化接口（即 C-API）
|
||
- 标准化 AUTOSAR 接口（端口、PortInterfaces、…）
|
||
- ECUC 参数的定义（见 [UC_STDT_00003]）
|
||
|
||
应用此形式化描述将提高 AUTOSAR SWS 的一致性和可用性，并强化形式化检查，例如对接口的向后兼容性检查。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00003] 标准化 ECUCParamdefs⌋
|
||
|
||
AUTOSAR SWS 的部分内容也是 ECU 配置参数定义的集合。这些参数定义是所谓供应商特定参数的基础，这些参数在特定的 AUTOSAR 实现中使用。
|
||
|
||
尽管在 [5] 中对此进行了非常详细的规定，但它也在标准化模板的范围之内。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00004] 表达预定义路径⌋
|
||
|
||
开发合作伙伴可以相互约定特定的包布局，从而在开发的后期阶段共享 AUTOSAR 工件。对于此用例，最初表达一组预定义或部分预定义的引用路径以及相应的 referenceBase 会有所帮助，这些路径可以被加载到各个 AUTOSAR 创作工具中。
|
||
|
||
此用例涵盖引用路径的起点或终点。例如用例是对 `<MyPath>/PortInterfaces` 中变量路径后的子结构进行标准化。在这种情况下，只有 PortInterfaces 被标准化。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00005] 表达 PlatformTypes⌋
|
||
|
||
[6] 中定义的平台类型需要以可处理的格式提供给 AUTOSAR 开发工具。此方法提高了 AUTOSAR 产品的一致性和质量。
|
||
|
||
[7] 第 3.1 章的细节适用。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00006] 表达已应用标准的示例⌋
|
||
|
||
除应用接口 [8] 外，AUTOSAR 还提供了如何应用标准化元素（特别是蓝图）的示例。
|
||
|
||
[7] 第 3.1 章的细节适用。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00007] 支持验证实现是否遵循已定义标准⌋
|
||
|
||
当开发 AUTOSAR 产品时，可通过对产品进行形式化标准的验证来执行初步验证。这包括：
|
||
|
||
- 检查蓝图与派生模型元素之间的兼容性规则。这些兼容性规则需要为每个可作为蓝图的元类进行定义。
|
||
- 跟踪模型元素与 SWS 或蓝图之间的关系，以检查是否实现了所有蓝图。
|
||
|
||
请注意，此用例是非常初步的验证，并不与一致性测试规范竞争，甚至不能替代一致性测试。它更倾向于对一致性测试作出贡献。
|
||
|
||
兼容性规则仅需在文档中描述，例如以约束的形式。在元模型中不存在兼容性规则的形式化表示。
|
||
|
||
兼容性规则针对每个适合蓝图的元类单独进行规定。例如，所有 port blueprint 遵循相同的兼容性规则。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00008] 支持可重用文档⌋
|
||
|
||
AUTOSAR SWS 的部分内容可以以可重用的形式发布，用于实际产品文档。实现的供应商随后从标准化模板的实例中取出这些部分，并将其整合到其自己的软件文档中。
|
||
|
||
相同的方法可能适用于应用接口的解释。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00009] 定义命名约定⌋
|
||
|
||
AUTOSAR 拥有建模指南和命名约定。如果这些约定作为标准化模板的实例发布，它们可以用于配置建模工具等。
|
||
|
||
此用例还涵盖表达各种义务层级的能力。这可以类似关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 那样进行表达。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00010] 在 AUTOSAR 范围之外的层级执行标准化⌋
|
||
|
||
标准化模板应适用于公司内部标准化或超出 AUTOSAR 元层级 M1 标准化（见 [UC_STDT_00001]）的相互约定。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00011] 通过手动更改属性从蓝图派生对象⌋
|
||
|
||
用户对蓝图进行一种复制，并被允许添加自己的内容（例如向标准化的枚举类型添加自己的字段）。示例是 ApplicationInterfaces 和 ConfigurationParamaters 的使用。
|
||
|
||
对于 AUTOSAR 服务的标准化 PortInterfaces，标准化模板应提及此用例：在此情况下，基于"标准化 PortInterface Blueprint"的 PortInterface 可能包含 ClientServerOperations 的子集。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00012] 以完全标准化的方式从蓝图派生对象⌋
|
||
|
||
用户只能以完全标准化的方式配置或以其他方式影响复制的"蓝图"的内容（例如根据软件的"需要"配置枚举类型的字段），但不能添加自己的内容。
|
||
|
||
这甚至可能达到只对配置规则进行标准化的程度（如 DCM-PortInterfaces 的情况）——但这在具体项目中仍完全确定了结果。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00013] 集成编译测试⌋
|
||
|
||
截至 Release 4.0，BSW 的所有 API 均已建模，SWS 的第 8 章主要从模型生成。此外，我们建议从模型生成空的 C 函数（以及数据结构/常量/…）并将这些函数链接在一起。如果编译或链接过程失败，则表明一致性（例如在不同 SWS 之间）被违反，需要进行修复。
|
||
|
||
> 关于元层级的更多详细信息，请参见 [7] 第 2.2 章。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00014] 从模型生成 BSW"标准 AUTOSAR 接口"描述⌋
|
||
|
||
截至 Release 4.0，"标准 AUTOSAR 接口"是提供该接口的每个 SWS 的一部分（通常包含在第 7 或 8 章的子章节中）。该描述主要是带有一些伪语言的纯文本，以展示接口的使用（包括常量等）。此外，服务的描述经常使用元模型中已过时或含义已发生变化的"元素"。
|
||
|
||
计划对 SWS 的这部分进行标准化，例如通过一个独立模型（然后可以将生成的描述导入 SWS 如第 8 章）或通过一种标准化语言以澄清对接口的理解，并允许 RTE 目的的自动转换。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00015] 处理通用规范条目⌋
|
||
|
||
可能存在一组通用需求，所有 SWS 文档都需要满足这些需求。另一方面，可能存在一个通用规范，其中汇总了所有通用规范条目。这种情况应通过可追溯性来处理：
|
||
|
||
- 追溯应同时使用需求文档：通用需求文档和单独需求文档
|
||
- 通用需求可由通用规范或单独规范满足
|
||
- 通用需求可能不适用于特定规范
|
||
- 通用需求可能仅由通用规范和单独规范共同完全满足
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00016] 在 AUTOSAR 中管理需求⌋
|
||
|
||
在 AUTOSAR 中，所有需求都以唯一 ID 形式正式记录在需求文档（RS/Feature/SRS）中。规范文档（SWS）包含正式追溯到需求的规范条目。同一层级需求之间的依赖关系通过在需求块本身中提供对需求的引用来表达。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00017] 在 AUTOSAR 中管理规范条目⌋
|
||
|
||
在 AUTOSAR 中，所有规范条目都以唯一 ID 形式正式记录在规范文档（TPS、SWS）中。规范条目正式追溯到需求。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00018] 在 AUTOSAR 中管理约束条目⌋
|
||
|
||
在 AUTOSAR 中，所有约束条目都以唯一 ID 形式正式记录在规范文档（TPS、SWS）中。
|
||
|
||
⌊()
|
||
|
||
#### ⌈[UC_STDT_00019] 在 AUTOSAR 中管理测试条目⌋
|
||
|
||
在 AUTOSAR 中，所有测试条目都以唯一 ID 形式正式记录在规范文档中。
|
||
|
||
⌊()
|
||
|
||
---
|
||
|
||
## 3 需求（Requirements）
|
||
|
||
本章描述驱动标准化模板规范 [2] 定义工作的所有需求。
|
||
|
||
本文档中的每条需求都有其唯一标识符，以"RS_STDT_"（即 Requirement Specification for Standardization Template）作为前缀。
|
||
|
||
### 3.1 蓝图（Blueprints）
|
||
|
||
#### ⌈[RS_STDT_00001] 应支持并解释蓝图总体概念⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持蓝图。蓝图是一种"不完整"的模型，可在之后被复制和细化。应定义蓝图的原则：<br>• "实例化"通过复制完成，而非引用。下游处理不包括对蓝图的引用使用。<br>• 为蓝图及被蓝图的模型元素定义适当的术语。<br>• 由蓝图创建的元素如何命名？<br>• 应明确定义元模型中哪些部分适合进行蓝图化。对不适合的元模型部分进行蓝图化应算作"验证错误"。<br>• 定义从蓝图派生对象的规则，特别是可添加/删除/重新定义的属性的策略。这些规则需要针对每个适合蓝图的元类单独进行规定。<br>元模型所需的设施应予以定义：<br>• 具体的蓝图<br>• 蓝图与派生对象的映射<br>这有助于理解蓝图的概念和应用，因为蓝图是标准化的主要手段。 |
|
||
| **理由** | 蓝图是标准化的主要手段。 |
|
||
| **用例** | [UC_STDT_00001]，[UC_STDT_00002]，[UC_STDT_00003]，[UC_STDT_00004]，[UC_STDT_00005]，[UC_STDT_00006]，[UC_STDT_00007]，[UC_STDT_00008]，[UC_STDT_00009] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04024)
|
||
|
||
#### ⌈[RS_STDT_00002] BSW SWS 的形式化描述⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应能够发布 SWS 的形式化部分，该部分随后作为所规定模块的蓝图。<br>标准化模板应提供描述标准化接口（C-API）的手段。<br>标准化模板应允许描述标准化的 AUTOSAR 接口。<br>标准化模板必须支持对接口变体的规定。<br>特别是"标准 AUTOSAR 接口"是提供该接口的每个 SWS 的一部分（通常包含在第 7 或 8 章的子章节中）。 |
|
||
| **理由** | 描述主要是带有一些伪语言的纯文本，以展示接口的使用（包括常量等）。此外，服务的描述经常使用元模型中已过时或含义已发生变化的"元素"。当 RTE 在 BSW 和 SWC 之间"路由"调用时，目前的状态会导致若干问题。伪语言必须手动转换为某种"SWC-Description"。如果人们试图混合来自不同供应商的模块，则不清楚这如何工作。我们认为该格式需要标准化。建议对 SWS 的这部分进行标准化，例如通过一个独立模型（然后可以将生成的描述导入 SWS 如第 8 章）或通过一种标准化语言以澄清对接口的理解，并允许 RTE 目的的自动转换。 |
|
||
| **用例** | [UC_STDT_00002]，[UC_STDT_00008] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00003] 应允许表示 port blueprint⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | AUTOSAR 标准化所谓的"应用接口"。这些接口实际上产生 port blueprint。 |
|
||
| **理由** | AUTOSAR 以 ARXML 形式发布标准化模型。 |
|
||
| **用例** | [UC_STDT_00001]，[UC_STDT_00008] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04024)
|
||
|
||
#### ⌈[RS_STDT_00004] 应允许表示 shortName 模式⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 蓝图应允许表示 shortName 模式，描述如何确定派生元素的 shortName。 |
|
||
| **理由** | AUTOSAR 发布应用接口建模指南。 |
|
||
| **用例** | [UC_STDT_00009] |
|
||
| **依赖** | TR_SWCModelingGuide [9] 可能需要调整。 |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00010] 应引用 ECUC 参数定义⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | ECUC 参数定义也由 AUTOSAR 标准化。因此，它在标准化模板的范围之内。严格来说，这些标准化的 ECUC 参数定义充当供应商特定参数的蓝图，即使这些参数没有使用 BluePrintMappingSet 进行映射。<br>标准化模板不应改变至少在 AUTOSAR 4.0 中的方法，但应反映这些关系。 |
|
||
| **理由** | 这维护了整体范围和所应用的模式。 |
|
||
| **用例** | [UC_STDT_00003] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | [5] |
|
||
|
||
⌊(RS_BRF_04024)
|
||
|
||
#### ⌈[RS_STDT_00011] 应能够标准化组件⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | STDT 应能够表达组件的标准化，即使 AUTOSAR 本身并不标准化组件。本需求涵盖一组单独的组件。 |
|
||
| **理由** | STDT 中不应硬编码任何兼容性规则。由于仅允许将 SwComponentType 指定为适合蓝图化，因此提供了支持。这允许在公司内部利用 AUTOSAR 标准化原则。 |
|
||
| **用例** | [UC_STDT_00010] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00012] 应能够标准化架构⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应能够表达组件和通信的标准化，即使 AUTOSAR 本身并不标准化应用软件的架构。本需求涵盖一组通信的组件。 |
|
||
| **理由** | 这允许在公司内部利用 AUTOSAR 标准化原则。 |
|
||
| **用例** | [UC_STDT_00010] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00013] 应能够表达引用路径的部分或包层次结构⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应能够表达标准化的引用路径或引用路径的部分。应可以指定包层次结构的起点或终点。示例见 UC_STDT_004。 |
|
||
| **理由** | 这允许在公司内部利用 AUTOSAR 标准化原则。 |
|
||
| **用例** | [UC_STDT_00004] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04000)
|
||
|
||
#### ⌈[RS_STDT_00014] 应能够表达义务层级⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 义务层级应由关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 表达。 |
|
||
| **理由** | 这允许使用标准化模型评估实现的一致性。 |
|
||
| **用例** | [UC_STDT_00009] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00015] 应支持从蓝图派生的不同方法⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 应支持从蓝图派生的不同方法。这些不同的方法包括：<br>1. 用户对蓝图进行一种复制，并被允许添加自己的内容（例如向标准化的枚举类型添加自己的字段）。<br>2. 用户只能以完全标准化的方式配置或以其他方式影响复制的"蓝图"的内容（例如根据软件的"需要"配置枚举类型的字段），但不能添加自己的内容。 |
|
||
| **理由** | 这允许使用标准化模型评估实现的一致性。一致性取决于派生对象的方法。 |
|
||
| **用例** | [UC_STDT_00007]，[UC_STDT_00011]，[UC_STDT_00012] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04024)
|
||
|
||
#### ⌈[RS_STDT_00017] 应涵盖蓝图和派生对象之间的兼容性⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应描述蓝图与派生对象之间的兼容性规则。这些兼容性应针对每个适合蓝图化的元类单独进行描述。 |
|
||
| **理由** | 这支持标准的持续演进。 |
|
||
| **用例** | [UC_STDT_00007] |
|
||
| **依赖** | [RS_STDT_00001] |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04024)
|
||
|
||
#### ⌈[RS_STDT_00018] 应允许描述 API 的依赖关系（例如调用和回调/轮询接口）⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应允许描述调用接口与相应回调或轮询接口之间的依赖关系。 |
|
||
| **理由** | 标准化接口在许多情况下由调用接口（C-API）以及回调或轮询接口组成。在许多情况下，可配置使用哪种通信模式。此可配置的依赖关系及其参数应通过蓝图描述。 |
|
||
| **用例** | [UC_STDT_00002] |
|
||
| **依赖** | [RS_STDT_00002] |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_01064)
|
||
|
||
#### ⌈[RS_STDT_00019] 应定义蓝图的强制语义⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 对于给定的模型元素，模板必须定义模型元素的哪些属性必须被标准化才能被称为蓝图。例如，PortInterface 必须包含哪些信息才能被称为蓝图？<br>对于 AUTOSAR 服务的标准化 PortInterfaces，标准化模板应提及此用例：在此情况下，基于"标准化 PortInterface Blueprint"的 PortInterface 可能包含 ClientServerOperations 的子集。 |
|
||
| **理由** | 有助于对蓝图模型元素形成共同理解。 |
|
||
| **用例** | [UC_STDT_00001] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04024)
|
||
|
||
#### ⌈[RS_STDT_00020] 应支持 VariableDataprototype 的变体⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | PortBlueprint 应能够映射到同一 PortInterface 实例的不同 VariableDataprototype。 |
|
||
| **理由** | WP10.3 的变体处理主要旨在重用客车和卡车之间的定义。因此，在数据类型层级拥有变体（而不是创建新蓝图）可能是有用的。 |
|
||
| **用例** | [UC_STDT_00001] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00021] 应支持带有 PortBlueprint 的示例 SWC 的多实例化⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | PortBlueprint 应能够支持多实例化。 |
|
||
| **理由** | – |
|
||
| **用例** | [UC_STDT_00001] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04024)
|
||
|
||
#### ⌈[RS_STDT_00022] 利益相关方之间用于蓝图的交换格式手段⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | AUTOSAR 方法论应定义针对给定 SWC 描述文件的 PortInterfaceMapping 交换。即，RTE 和 VFB 原则上忽略蓝图，但是在创建 PortPrototypes 时，利益相关方之间应如何进行蓝图信息的交换？ |
|
||
| **理由** | – |
|
||
| **用例** | [UC_STDT_00001] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04024)
|
||
|
||
#### ⌈[RS_STDT_00023] 应能够标准化别名⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | STDT 应能够标准化别名。 |
|
||
| **理由** | 例如用于测量和标定系统中的系统常量。如果系统常量将来需要被标准化（目前尚未决定），则这是必要的。 |
|
||
| **用例** | [UC_STDT_00008]，[UC_STDT_00009] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00026] 应允许表示 port interface blueprint⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | AUTOSAR 标准化所谓的"应用接口"。这些接口实际上产生 port blueprint 和相应的 port interface blueprint。 |
|
||
| **理由** | AUTOSAR 以 ARXML 形式发布标准化模型。 |
|
||
| **用例** | [UC_STDT_00001]，[UC_STDT_00008] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04024)
|
||
|
||
#### ⌈[RS_STDT_00027] 应允许评估蓝图的完整性⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 截至 Release 4.0，BSW 的所有 API 均已建模，SWS 的第 8 章主要从模型生成。此外，我们建议从模型生成空的 C 函数（以及数据结构/常量/…）并将这些函数链接在一起。如果编译或链接过程失败，则表明一致性（例如在不同 SWS 之间）被违反，需要进行修复。 |
|
||
| **理由** | 过去我们经常遇到这样的问题：某些 SWS 假定来自其他模块的特定服务（结构体/常量/…），但接口不匹配（甚至根本不存在）。在编译测试中将发现此类错误。 |
|
||
| **用例** | [UC_STDT_00013] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04024)
|
||
|
||
#### ⌈[RS_STDT_00029] 应能够表示进一步的蓝图⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | STDT 应能够表示以下元素的蓝图：<br>• AliasNameSet（见 RS_STDT_00023）<br>• ApplicationDatatype<br>• BswModuleEntry<br>• BaseType<br>• BswModuleDescription<br>• CompuMethod - 以增强枚举器<br>• DataConstr - 在适合 BaseType 的情况下扩大范围（不允许限制）<br>• DatatypeMappingSet - 派生映射集中的映射类型必须是蓝图的派生类型<br>• EcucModuleDef<br>• EcucDefinitionCollection<br>• ImplementationDatatype<br>• ModeDeclarationGroup - 以添加其他模式<br>• PortInterfaces（针对 sender-receiver 和 client-server 接口）（见 RS_STDT_00026）<br>• PortPrototypeBlueprints（见 RS_STDT_00003）<br>• SwComponentType |
|
||
| **理由** | – |
|
||
| **用例** | [UC_STDT_00003]，[UC_STDT_00011]，[UC_STDT_00012] |
|
||
| **依赖** | 另见 [RS_STDT_00003]，[RS_STDT_00026] |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04024)
|
||
|
||
#### ⌈[RS_STDT_00030] 应允许标准化包结构⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | STDT 应能够表示包结构的蓝图，特别是预定义访问路径。 |
|
||
| **理由** | – |
|
||
| **用例** | [UC_STDT_00004] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04000)
|
||
|
||
#### ⌈[RS_STDT_00032] 应能够为角色和权限提供蓝图⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持角色和权限的蓝图化。 |
|
||
| **理由** | – |
|
||
| **用例** | [UC_STDT_00010] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04024)
|
||
|
||
#### ⌈[RS_STDT_00033] 应能够为 Build Action Manifest 提供蓝图⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持 Processor Manifest 的蓝图化。 |
|
||
| **理由** | – |
|
||
| **用例** | [UC_STDT_00010] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04024)
|
||
|
||
#### ⌈[RS_STDT_00034] 隐式通信行为的蓝图化⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | AUTOSAR 模板和方法论应支持隐式通信行为描述的蓝图化。在已知 RunnableEntity 及其所有细节（数据访问点）之前，应可以先对数据进行分组。在自顶向下的方法中，DataPrototypes 的分组可以用于以保证一致性属性的方式设计系统，并且不相关的 DataPrototypes 不需要保持一致性。 |
|
||
| **理由** | 在自顶向下设计方法中定义隐式通信行为需求。 |
|
||
| **用例** | – |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04024)
|
||
|
||
#### ⌈[RS_STDT_00035] 应支持关键字的蓝图化⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 关键字应可蓝图化，以支持供应商特定扩展。 |
|
||
| **理由** | 支持 AUTOSAR 发布。 |
|
||
| **用例** | [UC_STDT_00001] |
|
||
| **依赖** | TR_SWCModelingGuide [9] 可能需要调整。 |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04024)
|
||
|
||
#### ⌈[RS_STDT_00040] 派生对象中元素的多重性⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应对具有上限多重性 > 1 的元素支持描述预期的派生对象数量。 |
|
||
| **理由** | 这支持从蓝图派生的任务。 |
|
||
| **用例** | [UC_STDT_00011]，[UC_STDT_00012] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04008)
|
||
|
||
### 3.2 关键字（Keywords）
|
||
|
||
#### ⌈[RS_STDT_00005] 应支持关键字和关键字缩写⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 在 [9] 中，AUTOSAR 发布 ShortName 作为关键字序列的构建规则。这些关键字需要由标准化模板表达。现有可识别的关键字应通过 ShortLabel 进行扩展。<br>SHORT-LABEL 的语义：代替 ShortName 使用。在有多个名称部分需要被同一关键字缩写所缩写的情况下，这是必要的。由于关键字是可识别的，这将导致冲突。 |
|
||
| **理由** | 支持 AUTOSAR 发布。 |
|
||
| **用例** | [UC_STDT_00001] |
|
||
| **依赖** | TR_SWCModelingGuide [9] 可能需要调整。 |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
### 3.3 AUTOSAR 集成与生命周期（AUTOSAR Integration and Lifecycle）
|
||
|
||
#### ⌈[RS_STDT_00006] 应实现而不会与现有模板产生兼容性问题⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 新模板应确保与现有模板兼容。 |
|
||
| **理由** | 维护 4.0 模式所要求的 Schema 向后兼容性。 |
|
||
| **用例** | [UC_STDT_00001] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00007] 应基于 AUTOSAR XML schema⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应使用与其他模板相同的机制进行描述。这包括在 AUTOSAR 元模型中的建模以及 AUTOSAR XML Schema 中 XML 表示的规定。 |
|
||
| **理由** | 为所有模板使用一个元模型的通用方法。 |
|
||
| **用例** | [UC_STDT_00001] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00016] 应能够表达关于模型元素状态的信息⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 如果 STDT 也能支持关于模型元素状态的信息，将会是有益的。<br>示例：由于向后兼容性，在未来版本中删除现有应用接口将是困难的。如果某些模型元素已不再是"最先进的"，可以将它们标记为例如"已废弃（obsolete）"。 |
|
||
| **理由** | 这支持标准的持续演进。 |
|
||
| **用例** | [UC_STDT_00001] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00125] 支持 AUTOSAR 特定建模模式⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 用于描述数据交换点配置文件的模板应能够处理 AUTOSAR 特定建模模式，例如：<br>• VariationPoints<br>• Splitable<br>• 伪原始数据类型（例如 Identifier、Verbatim String、Limit）<br>• 类型/实例引用<br>• XML 中的相对引用<br>• xml.sequenceOffset<br>• mixed 和 mixedString<br>• 公式 |
|
||
| **理由** | – |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
### 3.4 可追溯性（Traceability）
|
||
|
||
#### ⌈[RS_STDT_00008] 应提供支持分析实现与 AUTOSAR 标准一致性的手段⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应使实施者能够检查其描述（例如 BSWM）是否符合 M1 层级（SWS）上规定的 AUTOSAR 标准。 |
|
||
| **理由** | 这建立了 AUTOSAR 实现与已定义标准之间的可追溯性。也是检查不同发布之间应用兼容性的前提。 |
|
||
| **用例** | [UC_STDT_00007] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
### 3.5 规范元素的文档化（Documentation of Specification Elements）
|
||
|
||
#### ⌈[RS_STDT_00009] 应能够表示 SWS 中所述的需求⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 为了改进需求可追溯性，SWS 的形式化描述应包含相应 SWS 文档中每条需求的文本表示（SWS 的规范条目）。<br>这些陈述应归类为 {Requirement、Specification、Implementation、Constraint} 之一。 |
|
||
| **理由** | 此功能支持对需求变更的自动跟踪，这是改进变更管理和兼容性评估的基础。 |
|
||
| **用例** | [UC_STDT_00007] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00024] 应能够标准化唯一名称和显示名称⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | STDT 应能够标准化唯一名称和显示名称，例如在文档中（完整实例引用将不可读）以及在测量和标定系统中（标准化的测量和标定格式如 A2L 要求 SW 信号的唯一名称）。<br>支持标准化唯一名称，例如用于：<br>• 文档<br>• 标定和测量工具 |
|
||
| **理由** | 支持唯一名称的标准化。 |
|
||
| **用例** | [UC_STDT_00009]，[UC_STDT_00010] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00025] 应能够标准化生命周期状态⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | STDT 应能够标准化特定生命周期的状态。 |
|
||
| **理由** | 由于 AUTOSAR 目标是向后兼容，因此不可能仅删除一个标准化的模型元素并添加一个新元素，或更糟的是，在没有通知的情况下更改模型元素。 |
|
||
| **用例** | [UC_STDT_00009]，[UC_STDT_00010] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00028] 应允许从模型生成 BSW"标准 AUTOSAR 接口"描述⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | "标准 AUTOSAR 接口"是提供该接口的每个 SWS 的一部分（通常包含在第 7 或 8 章的子章节中）。该描述主要是带有一些伪语言的纯文本，以展示接口的使用（包括常量等）。此外，服务的描述经常使用元模型中已过时或含义已发生变化的"元素"。<br>STDT 应提供支持以标准化 SWS 的这部分，例如通过一个独立模型（然后可以将生成的描述导入 SWS 如第 8 章）或通过一种标准化语言以澄清对接口的理解，并允许 RTE 目的的自动转换。 |
|
||
| **理由** | – |
|
||
| **用例** | [UC_STDT_00014] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_01056)
|
||
|
||
#### ⌈[RS_STDT_00031] 应支持通用规范条目⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 支持对不适用的需求和补充规范条目的明确指示。特别是允许特定的追踪索引"NA"和"SPEC"。 |
|
||
| **理由** | – |
|
||
| **用例** | [UC_STDT_00002]，[UC_STDT_00015] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00036] 标准化模板应规定 AUTOSAR 文档中需求的表示⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 规定 AUTOSAR 文档和 AUTOSAR 元模型中结构化需求的内容和首选图形表示。 |
|
||
| **理由** | AUTOSAR 中需求和规范条目的一致性规范与表示。 |
|
||
| **用例** | [UC_STDT_00016] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00037] 标准化模板应规定 AUTOSAR 文档中规范条目的表示⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 规定 AUTOSAR 文档和 AUTOSAR 元模型中规范条目的内容。 |
|
||
| **理由** | AUTOSAR 中规范条目的一致性规范与表示。 |
|
||
| **用例** | [UC_STDT_00017] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00038] 标准化模板应规定 AUTOSAR 文档中约束条目的表示⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 规定 AUTOSAR 文档和 AUTOSAR 元模型中约束条目的内容。 |
|
||
| **理由** | AUTOSAR 中约束条目的一致性规范与表示。 |
|
||
| **用例** | [UC_STDT_00018] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00039] 标准化模板应规定 AUTOSAR 文档中测试条目的表示⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 规定 AUTOSAR 文档和 AUTOSAR 元模型中测试条目的内容。 |
|
||
| **理由** | AUTOSAR 中测试条目的一致性规范与表示。 |
|
||
| **用例** | [UC_STDT_00019] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04016)
|
||
|
||
#### ⌈[RS_STDT_00041] BSW 抽象 SWS 的形式化描述⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应能够发布通用 SWS 的形式化部分，这些部分随后被派生的具体 SWS 继承。 |
|
||
| **理由** | BSW SWS 组通常共享一组通用规范元素。这些通用规范元素不应被多次陈述以避免冗余。因此，特定 SWS 应能够从抽象 SWS 继承通用部分，并专注于必须特别规定的元素。 |
|
||
| **用例** | [UC_STDT_00002]，[UC_STDT_00008]，[UC_STDT_00015] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_04000)
|
||
|
||
#### ⌈[RS_STDT_00042] 应提供为公共符号定义命名约定的能力⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应提供为公共符号定义命名约定的能力。这尤其包括需求 ID、模块缩写、发布文档中使用的元数据和配置符号。 |
|
||
| **理由** | 避免规范内部的歧义和名称冲突；向规范读者提供一致、统一的元数据呈现；允许自动处理规范元素。 |
|
||
| **用例** | [UC_STDT_00009] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_BRF_01024)
|
||
|
||
### 3.6 数据交换点的配置文件（Profiles for Data Exchange Points）
|
||
|
||
#### ⌈[RS_STDT_00101] 数据交换点的描述应提供人类可读的高级概览⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持对数据交换点的人类可读抽象概览的描述。该概览预期为自由文本。 |
|
||
| **理由** | 向用户提供有关配置文件范围的简要信息，使用户能够决定配置文件是否适用于预期的数据交换点。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00102] 数据交换点的描述应描述方法论中的工作产品⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持对方法论中由数据交换点描述所表示的工作产品（即工件或可交付物）的描述。例如通过自由文本结合引用方法论模型中的工件。 |
|
||
| **理由** | 应明确配置文件适用于 AUTOSAR 方法论中的哪些工件。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00103] 数据交换点的描述应描述预期用途⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持对预期用途的描述（例如通过自由文本结合引用方法论模型中的工作定义（活动与任务）、BSW 模块或 BSW 需求列表）。 |
|
||
| **理由** | 定义配置文件的范围以及其在方法论中所适用的流程步骤。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | VFB specification - section "VFB Features and Profiles"，RS / SRS 需求 |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00104] 数据交换点的描述应描述工具和组织⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持描述由配置文件所表示的工具和组织。示例包括：<br>• 配置文件 P1 描述了组织 C 在项目 D 中使用的工具 A 版本 B 的可能输出<br>• 配置文件 P2 描述了由 AUTOSAR 定义的消费者的协调参考配置文件<br>• 配置文件 P3 描述了由一组具有特定版本和配置的工具所支持的数据交换点的协调子集 |
|
||
| **理由** | 有助于将配置文件与实际工具、组织或项目相关联的管理数据。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | ASAM ProjectData |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00105] 数据交换点的描述应描述 AUTOSAR 版本⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持描述配置文件中规则所关联的 AUTOSAR 版本。 |
|
||
| **理由** | 指定作为整个配置文件基线的 AUTOSAR 版本。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00106] 数据交换点的描述应描述 AUTOSAR 元模型的相关或排除子集⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持描述对数据交换点相关的元模型子集。 |
|
||
| **理由** | 记录元模型的哪些部分在方法论中的特定步骤中涉及。有助于避免互操作性问题：<br>• 在没有调整的情况下应用严格的 XML schema<br>• 缺少元素/属性<br>• 没有内容的结构和孤立元素 - 未定义的行为<br>• 信息丢失<br>• 缺少 AUTOSAR 功能或建模模式的实现<br>• 在 ECU 配置中而非上游模板中进行的配置<br>• 同一事物的多种表达可能性 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00107] 数据交换点的描述应描述模型的相关或排除子集⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持描述对数据交换点相关的模型子集（例如通过明确定义如何遍历模型）。 |
|
||
| **理由** | 区分方法论中需要验证的预期步骤所必需的数据与尚未使用且不需要验证的数据。有助于避免互操作性问题：<br>• 在没有调整的情况下应用严格的 XML schema<br>• 缺少元素/属性<br>• 没有内容的结构和孤立元素 - 未定义的行为<br>• 信息丢失<br>• 缺少 AUTOSAR 功能或建模模式的实现<br>• 在 ECU 配置中而非上游模板中进行的配置<br>• 同一事物的多种表达可能性 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00108] 数据交换点的描述应描述相关约束⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持描述对数据交换点相关的约束。 |
|
||
| **理由** | 降低由以下原因引起的互操作性问题的风险：<br>• 约束的不同解释或选择<br>• 未实现所需的 AUTOSAR 功能 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00109] 数据交换点的描述应描述相关规范条目⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持描述来自对数据交换点相关的所有模板规范的规范条目。<br>某些规范条目具有可检查的约束的性质。或者规范条目的选择记录了所支持的 AUTOSAR 能力。 |
|
||
| **理由** | 降低由以下原因引起的互操作性问题的风险：<br>• 规范条目的不同解释或选择<br>• 未实现所需的 AUTOSAR 功能 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00110] 数据交换点的描述应描述模型的完整性⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持描述数据交换点处数据的完整性（例如通过细化每个交换点的元模型引用和属性的低重数的语义）。 |
|
||
| **理由** | 如果未为数据交换点指定完整性，则工具链中的消费工具可能需要由生产工具未提供的信息。避免因对所需模型元素和功能的不同理解所引起的互操作性问题。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00111] 数据交换点的描述应描述默认值的适用性⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持描述 AUTOSAR 模型的消费者何时应应用 AUTOSAR 定义的默认值。例如"在版本更新时应用"、"从不应用"、"始终应用"。 |
|
||
| **理由** | 克服当前 AUTOSAR 定义默认值的弱语义。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00113] 数据交换点的描述应描述原始属性值的限制⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持描述特定数据交换点上下文中对具有原始数据类型的属性值的限制（例如限制 category 或枚举的值）。 |
|
||
| **理由** | 消费工具可能仅支持枚举值或受限参数范围的子集。例如，消费工具仅支持可能的 CATEGORY 值的子集。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00114] 数据交换点的描述应支持配置文件各规则合规性的严重性级别⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持描述每条规则的严重性：<br>**error**：模型元素被视为与配置文件不兼容<br>**warning**：模型元素可疑，但流程步骤可继续<br>**info**：当规则适用但对流程步骤无影响时，例如"变量 x 未指定单位" |
|
||
| **理由** | 并非模型与配置文件的每个不一致都会阻塞工作流。在开发早期阶段，消费者可以接受某些数据缺失。尽管如此，此类问题应作为警告被报告。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00115] 数据交换点的描述应描述决策的理由⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持描述在特定数据交换点中所记录的任何决策的理由。 |
|
||
| **理由** | 提供关于为何将特定规则纳入配置文件以及为何采取该决策的附加信息。这支持可维护性，并有助于在讨论工具不兼容性时使用。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00116] 数据交换点的描述应描述 AUTOSAR 扩展机制的使用⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应支持描述特定数据交换点的 AUTOSAR 扩展机制（Category、SDGs）的使用。这包括对扩展预期用途的文本文档，包括对相关规范条目和元类在较新版本的 AUTOSAR 规范中的交叉引用。 |
|
||
| **理由** | 类别和 SDG 是 AUTOSAR 元模型中的标准模式。当标准中未预见某内容时，这为项目特定工作流提供了一种解决方案。尽管如此，此类扩展与数据交换点处的互操作性相关，并且应能使用配置文件进行验证。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00117] AUTOSAR 应提供比较数据交换点配置文件的指南⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应定义用于比较/区分不同抽象层级配置文件的指南。这些指南提供关于如何有效解释两个配置文件的差异，或如何创建简化比较的组合配置文件的规范化版本的提示。 |
|
||
| **理由** | 用于描述配置文件的语言支持不同程度的规范化。虽然某些部分故意被描述为自由文本，但其他部分则经过优化以便由工具处理。这允许确定例如同一工具不同版本之间的修改。此外，这些规则可以限制分析配置文件之间差异的工作量：例如，如果在功能层级上的比较发现重大不兼容，则属性层级上的比较就不再必要。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00118] AUTOSAR 应提供数据交换点配置文件兼容性的指南⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应定义用于检查不同抽象层级配置文件兼容性的指南。 |
|
||
| **理由** | 与编程语言中的接口兼容性类似，并不总是需要具有相同的接口。通常只要接口兼容即可。<br>例如：生产者可能提供比消费者所需更多的数据。<br>例如：如果消费者需要某些未由生产者提供的数据，则两个工具不兼容。<br>此外，这些规则可以限制分析配置文件之间不兼容性的工作量：例如：如果配置文件在功能层级上不兼容，则讨论可以在该层级上开始，然后再处理各个属性或约束。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00120] AUTOSAR 应支持处理不完整的数据交换点配置文件⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应定义用于比较、检查兼容性或检查不完整配置文件可组合性的规则。 |
|
||
| **理由** | 在 AUTOSAR 上下文中可能无法就配置文件的所有方面达成一致。然而，在进一步细化 AUTOSAR 所提供配置文件的较小组的上下文中则可能达成一致。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00121] AUTOSAR 应提供针对数据交换点配置文件的 AUTOSAR 模型合规性检查的指南⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应定义检查 AUTOSAR 模型对给定配置文件合规性的指南。 |
|
||
| **理由** | 检查交换数据是否符合已商定的契约。克服针对严格 XML schema 的检查的局限性。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00119] AUTOSAR 应提供数据交换点配置文件的组合规则⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应定义组合多个配置文件的规则。 |
|
||
| **理由** | 配置文件的模块化、组合多个消费工具的配置文件。<br>例如：如果一个工具需要某些数据而另一个工具将其视为"不关心"，则这是可以接受的。<br>例如：如果一个工具需要某些数据而另一个工具排除它，则会发生冲突。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00122] AUTOSAR 应提供用于识别数据交换点配置文件内尚未描述方面的指南⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应规定有助于识别数据交换点尚未描述方面的指南。 |
|
||
| **理由** | 该配置文件允许引用 AUTOSAR 规范中提到的规范条目、约束、元类等。这些指南例如提供关于如何利用 AUTOSAR 规范中的现有信息以查找相关信息（例如通过上游映射、交叉引用、技术术语等）的指导。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
#### ⌈[RS_STDT_00123] AUTOSAR 应提供数据交换点配置文件一致性的指南⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效（valid） |
|
||
| **描述** | 标准化模板应定义数据交换点配置文件的一致性指南。 |
|
||
| **理由** | 配置文件的各部分相互依赖。例如，关于默认值的陈述仅在相关属性相关时才是必需的。关于元类完整性的陈述仅在元类可从类 AUTOSAR 通过包含引用到达时才是必需的。 |
|
||
| **用例** | [10] 中的 [UC_IOAT_00030] |
|
||
| **依赖** | – |
|
||
| **支撑材料** | – |
|
||
|
||
⌊(RS_Main_00300)
|
||
|
||
---
|
||
|
||
## 附录 A 变更历史（Change History）
|
||
|
||
### A.1 变更历史 R4.0.3
|
||
|
||
#### A.1.1 已新增的用例
|
||
|
||
| 编号 | 标题 |
|
||
|------|------|
|
||
| [UC_STDT_00001] | 支持应用接口 |
|
||
| [UC_STDT_00002] | 表达 SWS 的部分 |
|
||
| [UC_STDT_00003] | 标准化 ECUCParamdefs |
|
||
| [UC_STDT_00004] | 表达预定义路径 |
|
||
| [UC_STDT_00005] | 表达平台类型 |
|
||
| [UC_STDT_00006] | 表达已应用标准的示例 |
|
||
| [UC_STDT_00007] | 支持验证实现是否遵循已定义标准 |
|
||
| [UC_STDT_00008] | 支持可重用文档 |
|
||
| [UC_STDT_00009] | 定义命名约定 |
|
||
| [UC_STDT_00010] | 在 AUTOSAR 范围之外的层级执行标准化 |
|
||
| [UC_STDT_00011] | 通过手动更改属性从蓝图派生对象 |
|
||
| [UC_STDT_00012] | 以完全标准化的方式从蓝图派生对象 |
|
||
| [UC_STDT_00013] | 集成编译测试 |
|
||
| [UC_STDT_00014] | 从模型生成 BSW"标准 AUTOSAR 接口"描述 |
|
||
|
||
> **表 A.1：4.0.3 中已新增的用例**
|
||
|
||
#### A.1.2 已新增的需求
|
||
|
||
| 编号 | 标题 |
|
||
|------|------|
|
||
| [RS_STDT_00001] | 应支持并解释蓝图总体概念 |
|
||
| [RS_STDT_00002] | BSW SWS 的形式化描述 |
|
||
| [RS_STDT_00003] | 应允许表示 port blueprint |
|
||
| [RS_STDT_00004] | 应允许表示 shortName 模式 |
|
||
| [RS_STDT_00005] | 应支持关键字和关键字缩写 |
|
||
| [RS_STDT_00006] | 应实现而不会与现有模板产生兼容性问题 |
|
||
| [RS_STDT_00007] | 应基于 AUTOSAR schema |
|
||
| [RS_STDT_00008] | 应提供支持分析实现与 AUTOSAR 标准一致性的手段 |
|
||
| [RS_STDT_00009] | 应能够表示 SWS 中所述的需求 |
|
||
| [RS_STDT_00010] | 应引用 ECUC 参数定义 |
|
||
| [RS_STDT_00011] | 应能够标准化组件 |
|
||
| [RS_STDT_00012] | 应能够标准化架构 |
|
||
| [RS_STDT_00013] | 应能够表达引用路径的部分或包层次结构 |
|
||
| [RS_STDT_00014] | 应能够表达义务层级 |
|
||
| [RS_STDT_00015] | 应支持从蓝图派生的不同方法 |
|
||
| [RS_STDT_00016] | 应能够表达关于模型元素状态的信息 |
|
||
| [RS_STDT_00017] | 应涵盖蓝图和派生对象之间的兼容性 |
|
||
| [RS_STDT_00018] | 应允许描述 API 的依赖关系（例如调用和回调/轮询接口） |
|
||
| [RS_STDT_00019] | 应定义蓝图的强制语义 |
|
||
| [RS_STDT_00020] | 应支持 VariableDataprototype 的变体 |
|
||
| [RS_STDT_00021] | 应支持带有 PortBlueprint 的示例 SWC 的多实例化 |
|
||
| [RS_STDT_00022] | 利益相关方之间用于蓝图的交换格式手段 |
|
||
| [RS_STDT_00023] | 应能够标准化别名 |
|
||
| [RS_STDT_00024] | 应能够标准化唯一名称和显示名称 |
|
||
| [RS_STDT_00025] | 应能够标准化生命周期状态 |
|
||
| [RS_STDT_00026] | 应允许表示 port interface blueprint |
|
||
| [RS_STDT_00027] | 应允许评估蓝图的完整性 |
|
||
| [RS_STDT_00028] | 应允许从模型生成 BSW"标准 AUTOSAR 接口"描述 |
|
||
| [RS_STDT_00029] | 应能够表示进一步的蓝图 |
|
||
| [RS_STDT_00030] | 应允许标准化包结构 |
|
||
|
||
> **表 A.2：4.0.3 中已新增的需求**
|
||
|
||
### A.2 变更历史 R4.1.1
|
||
|
||
#### A.2.1 已新增的用例
|
||
|
||
| 编号 | 标题 |
|
||
|------|------|
|
||
| [UC_STDT_00016] | 在 AUTOSAR 中管理需求 |
|
||
|
||
> **表 A.3：4.1.1 中已新增的用例**
|
||
|
||
#### A.2.2 已新增的需求
|
||
|
||
| 编号 | 标题 |
|
||
|------|------|
|
||
| [RS_STDT_00031] | 应支持通用规范条目 |
|
||
| [RS_STDT_00032] | 应能够为角色和权限提供蓝图 |
|
||
| [RS_STDT_00033] | 应能够为 Build Action Manifest 提供蓝图 |
|
||
| [RS_STDT_00034] | 隐式通信行为的蓝图化 |
|
||
| [RS_STDT_00035] | 应支持关键字的蓝图化 |
|
||
| [RS_STDT_00036] | 标准化模板应规定 AUTOSAR 文档中需求的表示 |
|
||
|
||
> **表 A.4：4.1.1 中已新增的需求**
|
||
|
||
### A.3 变更历史 R4.1.2
|
||
|
||
#### A.3.1 已新增的用例
|
||
|
||
| 编号 | 标题 |
|
||
|------|------|
|
||
| [UC_STDT_00017] | 在 AUTOSAR 中管理规范条目 |
|
||
| [UC_STDT_00018] | 在 AUTOSAR 中管理约束条目 |
|
||
|
||
> **表 A.5：4.1.2 中已新增的用例**
|
||
|
||
#### A.3.2 已新增的需求
|
||
|
||
| 编号 | 标题 |
|
||
|------|------|
|
||
| [RS_STDT_00037] | 标准化模板应规定 AUTOSAR 文档中规范条目的表示 |
|
||
| [RS_STDT_00038] | 标准化模板应规定 AUTOSAR 文档中约束条目的表示 |
|
||
|
||
> **表 A.6：4.1.2 中已新增的需求**
|
||
|
||
### A.4 变更历史 R4.1.3
|
||
|
||
#### A.4.1 已新增的用例
|
||
|
||
无
|
||
|
||
#### A.4.2 已新增的需求
|
||
|
||
无
|
||
|
||
### A.5 变更历史 R4.2.1
|
||
|
||
#### A.5.1 4.2.1 中已新增的可追溯项
|
||
|
||
| 编号 | 标题 |
|
||
|------|------|
|
||
| [RS_STDT_00039] | 标准化模板应规定 AUTOSAR 文档中测试条目的表示 |
|
||
| [RS_STDT_00040] | 派生对象中元素的多重性 |
|
||
| [RS_STDT_00041] | BSW 抽象 SWS 的形式化描述 |
|
||
| [RS_STDT_00042] | 应提供为公共符号定义命名约定的能力 |
|
||
| [UC_STDT_00019] | 在 AUTOSAR 中管理测试条目 |
|
||
|
||
> **表 A.7：4.2.1 中已新增的可追溯项**
|
||
|
||
#### A.5.2 4.2.1 中已变更的可追溯项
|
||
|
||
| 编号 | 标题 |
|
||
|------|------|
|
||
| [RS_STDT_00001] | 应支持并解释蓝图总体概念 |
|
||
| [RS_STDT_00002] | BSW SWS 的形式化描述 |
|
||
| [RS_STDT_00003] | 应允许表示 port blueprint |
|
||
| [RS_STDT_00004] | 应允许表示 shortName 模式 |
|
||
| [RS_STDT_00005] | 应支持关键字和关键字缩写 |
|
||
| [RS_STDT_00006] | 应实现而不会与现有模板产生兼容性问题 |
|
||
| [RS_STDT_00007] | 应基于 AUTOSAR schema |
|
||
| [RS_STDT_00008] | 应提供支持分析实现与 AUTOSAR 标准一致性的手段 |
|
||
| [RS_STDT_00009] | 应能够表示 SWS 中所述的需求 |
|
||
| [RS_STDT_00010] | 应引用 ECUC 参数定义 |
|
||
| [RS_STDT_00011] | 应能够标准化组件 |
|
||
| [RS_STDT_00012] | 应能够标准化架构 |
|
||
| [RS_STDT_00013] | 应能够表达引用路径的部分或包层次结构 |
|
||
| [RS_STDT_00014] | 应能够表达义务层级 |
|
||
| [RS_STDT_00015] | 应支持从蓝图派生的不同方法 |
|
||
| [RS_STDT_00016] | 应能够表达关于模型元素状态的信息 |
|
||
| [RS_STDT_00017] | 应涵盖蓝图和派生对象之间的兼容性 |
|
||
| [RS_STDT_00018] | 应允许描述 API 的依赖关系（例如调用和回调/轮询接口） |
|
||
| [RS_STDT_00019] | 应定义蓝图的强制语义 |
|
||
| [RS_STDT_00020] | 应支持 VariableDataprototype 的变体 |
|
||
| [RS_STDT_00021] | 应支持带有 PortBlueprint 的示例 SWC 的多实例化 |
|
||
| [RS_STDT_00022] | 利益相关方之间用于蓝图的交换格式手段 |
|
||
| [RS_STDT_00023] | 应能够标准化别名 |
|
||
| [RS_STDT_00024] | 应能够标准化唯一名称和显示名称 |
|
||
| [RS_STDT_00025] | 应能够标准化生命周期状态 |
|
||
| [RS_STDT_00026] | 应允许表示 port interface blueprint |
|
||
| [RS_STDT_00027] | 应允许评估蓝图的完整性 |
|
||
| [RS_STDT_00028] | 应允许从模型生成 BSW"标准 AUTOSAR 接口"描述 |
|
||
| [RS_STDT_00029] | 应能够表示进一步的蓝图 |
|
||
| [RS_STDT_00030] | 应允许标准化包结构 |
|
||
| [RS_STDT_00031] | 应支持通用规范条目 |
|
||
| [RS_STDT_00032] | 应能够为角色和权限提供蓝图 |
|
||
| [RS_STDT_00033] | 应能够为 Build Action Manifest 提供蓝图 |
|
||
| [RS_STDT_00034] | 隐式通信行为的蓝图化 |
|
||
| [RS_STDT_00035] | 应支持关键字的蓝图化 |
|
||
| [RS_STDT_00036] | 标准化模板应规定 AUTOSAR 文档中需求的表示 |
|
||
| [RS_STDT_00037] | 标准化模板应规定 AUTOSAR 文档中规范条目的表示 |
|
||
| [RS_STDT_00038] | 标准化模板应规定 AUTOSAR 文档中约束条目的表示 |
|
||
| [UC_STDT_00006] | 表达已应用标准的示例 |
|
||
|
||
> **表 A.8：4.2.1 中已变更的可追溯项**
|
||
|
||
#### A.5.3 4.2.1 中已删除的可追溯项
|
||
|
||
无
|
||
|
||
### A.6 变更历史 R4.2.2
|
||
|
||
#### A.6.1 4.2.2 中已新增的可追溯项
|
||
|
||
无
|
||
|
||
#### A.6.2 4.2.2 中已变更的可追溯项
|
||
|
||
无
|
||
|
||
#### A.6.3 4.2.2 中已删除的可追溯项
|
||
|
||
无
|
||
|
||
### A.7 变更历史 R4.3.0
|
||
|
||
#### A.7.1 4.3.0 中已新增的可追溯项
|
||
|
||
| 编号 | 标题 |
|
||
|------|------|
|
||
| [RS_STDT_00101] | 数据交换点的描述应提供人类可读的高级概览 |
|
||
| [RS_STDT_00102] | 数据交换点的描述应描述方法论中的工作产品 |
|
||
| [RS_STDT_00103] | 数据交换点的描述应描述预期用途 |
|
||
| [RS_STDT_00104] | 数据交换点的描述应描述工具和组织 |
|
||
| [RS_STDT_00105] | 数据交换点的描述应描述 AUTOSAR 版本 |
|
||
| [RS_STDT_00106] | 数据交换点的描述应描述 AUTOSAR 元模型的相关或排除子集 |
|
||
| [RS_STDT_00107] | 数据交换点的描述应描述模型的相关或排除子集 |
|
||
| [RS_STDT_00108] | 数据交换点的描述应描述相关约束 |
|
||
| [RS_STDT_00109] | 数据交换点的描述应描述相关规范条目 |
|
||
| [RS_STDT_00110] | 数据交换点的描述应描述模型的完整性 |
|
||
| [RS_STDT_00111] | 数据交换点的描述应描述默认值的适用性 |
|
||
| [RS_STDT_00113] | 数据交换点的描述应描述原始属性值的限制 |
|
||
| [RS_STDT_00114] | 数据交换点的描述应支持配置文件各规则合规性的严重性级别 |
|
||
| [RS_STDT_00115] | 数据交换点的描述应描述决策的理由 |
|
||
| [RS_STDT_00116] | 数据交换点的描述应描述 AUTOSAR 扩展机制的使用 |
|
||
| [RS_STDT_00117] | AUTOSAR 应提供比较数据交换点配置文件的指南 |
|
||
| [RS_STDT_00118] | AUTOSAR 应提供数据交换点配置文件兼容性的指南 |
|
||
| [RS_STDT_00119] | AUTOSAR 应提供数据交换点配置文件的组合规则 |
|
||
| [RS_STDT_00120] | AUTOSAR 应支持处理不完整的数据交换点配置文件 |
|
||
| [RS_STDT_00121] | AUTOSAR 应提供针对数据交换点配置文件的 AUTOSAR 模型合规性检查的指南 |
|
||
| [RS_STDT_00122] | AUTOSAR 应提供用于识别数据交换点配置文件内尚未描述方面的指南 |
|
||
| [RS_STDT_00123] | AUTOSAR 应提供数据交换点配置文件一致性的指南 |
|
||
| [RS_STDT_00125] | 支持 AUTOSAR 特定建模模式 |
|
||
|
||
> **表 A.9：4.3.0 中已新增的可追溯项**
|
||
|
||
#### A.7.2 4.3.0 中已变更的可追溯项
|
||
|
||
| 编号 | 标题 |
|
||
|------|------|
|
||
| [RS_STDT_00007] | 应基于 AUTOSAR XML schema |
|
||
|
||
> **表 A.10：4.3.0 中已变更的可追溯项**
|
||
|
||
#### A.7.3 4.3.0 中已删除的可追溯项
|
||
|
||
无
|
||
|
||
### A.8 变更历史 R4.3.1
|
||
|
||
#### A.8.1 4.3.1 中已新增的可追溯项
|
||
|
||
无
|
||
|
||
#### A.8.2 4.3.1 中已变更的可追溯项
|
||
|
||
无
|
||
|
||
#### A.8.3 4.3.1 中已删除的可追溯项
|
||
|
||
无
|
||
|
||
---
|
||
|
||
## 附录 B 引用的类表（Mentioned Class Tables）
|
||
|
||
为完备起见，本章包含一组类表，表示在本文档上下文中被提到但并不直接属于描述特定元模型语义范围的元类。
|
||
|
||
### 表 B.1：DataPrototype
|
||
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| **类（Class）** | DataPrototype (abstract) |
|
||
| **包（Package）** | M2::AUTOSARTemplates::SWComponentTemplate::Datatype::DataPrototypes |
|
||
| **说明（Note）** | 任何数据类型的原型角色的基类。 |
|
||
| **基类（Base）** | ARObject, AtpFeature, AtpPrototype, Identifiable, MultilanguageReferrable, Referrable |
|
||
| **子类（Subclasses）** | ApplicationCompositeElementDataPrototype, AutosarDataPrototype |
|
||
|
||
| 属性（Attribute） | 类型（Type） | 多重性（Mul.） | 种类（Kind） | 说明（Note） |
|
||
|-------------------|--------------|-----------------|--------------|--------------|
|
||
| swDataDefProps | SwDataDefProps | 0..1 | aggr | 此属性允许指定在数据原型层级适用的数据定义属性。 |
|
||
|
||
### 表 B.2：RunnableEntity
|
||
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| **类（Class）** | RunnableEntity |
|
||
| **包（Package）** | M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior |
|
||
| **说明（Note）** | RunnableEntity 表示由 AtomicSwComponentType 提供并在 RTE 控制下执行的最小代码片段。RunnableEntity 例如被设置为响应数据接收或服务器上的操作调用。 |
|
||
| **基类（Base）** | ARObject, AtpClassifier, AtpFeature, AtpStructureElement, ExecutableEntity, Identifiable, MultilanguageReferrable, Referrable |
|
||
|
||
| 属性（Attribute） | 类型（Type） | 多重性（Mul.） | 种类（Kind） | 说明（Note） |
|
||
|-------------------|--------------|-----------------|--------------|--------------|
|
||
| argument (ordered) | RunnableEntityArgument | * | aggr | 表示 RunnableEntity 的某个参数的形式定义。 |
|
||
| asynchronousServerCallResultPoint | AsynchronousServerCallResultPoint | * | aggr | 服务器调用结果点允许 runnable 获取异步服务器调用的结果。AsynchronousServerCallResultPoint 的聚合受可变性约束，以支持 client-server PortPrototypes 的条件存在以及实现中服务器调用结果点的变体存在。<br>Stereotypes: atpSplitable; atpVariation<br>Tags: atp.Splitkey=shortName, variationPoint.shortLabel<br>vh.latestBindingTime=preCompileTime |
|
||
| canBeInvokedConcurrently | Boolean | 1 | attr | 如果此属性的值设置为 "true"，则封闭的 RunnableEntity 可以被并发调用（即使对于相应 AtomicSwComponentType 的同一实例）。这意味着 RunnableEntity 的实现有责任处理这种并发形式。请注意，此属性的默认值设置为 "false"。 |
|
||
| dataReadAccess | VariableAccess | * | aggr | RunnableEntity 对 sender-receiver PortPrototype 的 dataElement 或 nv data PortPrototype 的 nv data 具有隐式读访问权限。dataReadAccess 的聚合受可变性约束，以支持 sender-receiver 端口的条件存在或实现中 dataReadAccess 的变体存在。<br>Stereotypes: atpSplitable; atpVariation<br>Tags: atp.Splitkey=shortName, variationPoint.shortLabel<br>vh.latestBindingTime=preCompileTime |
|
||
| dataReceivePointByArgument | VariableAccess | * | aggr | RunnableEntity 对 sender-receiver PortPrototype 的 dataElement 或 nv data PortPrototype 的 nv data 具有显式读访问权限。结果通过函数签名中的参数传递回应用。dataReceivePointByArgument 的聚合受可变性约束，以支持 sender-receiver PortPrototype 的条件存在或实现中数据接收点的变体存在。<br>Stereotypes: atpSplitable; atpVariation<br>Tags: atp.Splitkey=shortName, variationPoint.shortLabel<br>vh.latestBindingTime=preCompileTime |
|
||
| dataReceivePointByValue | VariableAccess | * | aggr | RunnableEntity 对 sender-receiver PortPrototype 的 dataElement 或 nv data PortPrototype 的 nv data 具有显式读访问权限。结果通过返回值传递回应用。dataReceivePointByValue 的聚合受可变性约束，以支持 sender-receiver 端口的条件存在或实现中数据接收点的变体存在。<br>Stereotypes: atpSplitable; atpVariation<br>Tags: atp.Splitkey=shortName, variationPoint.shortLabel<br>vh.latestBindingTime=preCompileTime |
|
||
| dataSendPoint | VariableAccess | * | aggr | RunnableEntity 对 sender-receiver PortPrototype 的 dataElement 或 nv data PortPrototype 的 nv data 具有显式写访问权限。dataSendPoint 的聚合受可变性约束，以支持 sender-receiver PortPrototype 的条件存在或实现中数据发送点的变体存在。<br>Stereotypes: atpSplitable; atpVariation<br>Tags: atp.Splitkey=shortName, variationPoint.shortLabel<br>vh.latestBindingTime=preCompileTime |
|
||
| dataWriteAccess | VariableAccess | * | aggr | RunnableEntity 对 sender-receiver PortPrototype 的 dataElement 或 nv data PortPrototype 的 nv data 具有隐式写访问权限。dataWriteAccess 的聚合受可变性约束，以支持 sender-receiver 端口的条件存在或实现中 dataWriteAccess 的变体存在。<br>Stereotypes: atpSplitable; atpVariation<br>Tags: atp.Splitkey=shortName, variationPoint.shortLabel<br>vh.latestBindingTime=preCompileTime |
|
||
| externalTriggeringPoint | ExternalTriggeringPoint | * | aggr | ExternalTriggeringPoint 的聚合受可变性约束，以支持触发端口的条件存在或实现中外部触发点的变体存在。<br>Stereotypes: atpSplitable; atpVariation<br>Tags: atp.Splitkey=externalTriggeringPoint, variationPoint.shortLabel<br>vh.latestBindingTime=preCompileTime |
|
||
| internalTriggeringPoint | InternalTriggeringPoint | * | aggr | InternalTriggeringPoint 的聚合受可变性约束，以支持实现中内部触发点的变体存在。<br>Stereotypes: atpSplitable; atpVariation<br>Tags: atp.Splitkey=shortName, variationPoint.shortLabel<br>vh.latestBindingTime=preCompileTime |
|
||
| modeAccessPoint | ModeAccessPoint | * | aggr | runnable 拥有一个 mode access point。ModeAccessPoint 的聚合受可变性约束，以支持模式端口的条件存在或实现中模式访问点的变体存在。<br>Stereotypes: atpSplitable; atpVariation<br>Tags: atp.Splitkey=modeAccessPoint, variationPoint.shortLabel<br>vh.latestBindingTime=preCompileTime |
|
||
| modeSwitchPoint | ModeSwitchPoint | * | aggr | runnable 拥有一个 mode switch point。ModeSwitchPoint 的聚合受可变性约束，以支持模式端口的条件存在或实现中模式切换点的变体存在。<br>Stereotypes: atpSplitable; atpVariation<br>Tags: atp.Splitkey=shortName, variationPoint.shortLabel<br>vh.latestBindingTime=preCompileTime |
|
||
| parameterAccess | ParameterAccess | * | aggr | ParameterAccess 的存在意味着 RunnableEntity 需要对 ParameterDataPrototype（可以是本地的或位于 PortPrototype 内）进行只读访问。ParameterAccess 的聚合受可变性约束，以支持参数端口和组件本地参数的条件存在以及实现中 Parameter Access（点）的变体存在。<br>Stereotypes: atpSplitable; atpVariation<br>Tags: atp.Splitkey=shortName, variationPoint.shortLabel<br>vh.latestBindingTime=preCompileTime |
|
||
| readLocalVariable | VariableAccess | * | aggr | readLocalVariable 的存在意味着 RunnableEntity 需要对处于 implicitInterRunnableVariable 或 explicitInterRunnableVariable 角色的 VariableDataPrototype 进行读访问。readLocalVariable 的聚合受可变性约束，以支持 implicitInterRunnableVariable 和 explicitInterRunnableVariable 的条件存在或实现中 readLocalVariable（点）的变体存在。<br>Stereotypes: atpSplitable; atpVariation<br>Tags: atp.Splitkey=shortName, variationPoint.shortLabel<br>vh.latestBindingTime=preCompileTime |
|
||
| serverCallPoint | ServerCallPoint | * | aggr | RunnableEntity 拥有一个 ServerCallPoint。ServerCallPoint 的聚合受可变性约束，以支持 client-server PortPrototypes 的条件存在或实现中服务器调用点的变体存在。<br>Stereotypes: atpSplitable; atpVariation<br>Tags: atp.Splitkey=shortName, variationPoint.shortLabel<br>vh.latestBindingTime=preCompileTime |
|
||
| symbol | CIdentifier | 1 | attr | 描述此 RunnableEntity 入口点的符号。这被视为 RunnableEntity 的 API，在 RTE 契约阶段是必需的。 |
|
||
| waitPoint | WaitPoint | * | aggr | 与 RunnableEntity 关联的 WaitPoint。 |
|
||
| writtenLocalVariable | VariableAccess | * | aggr | writtenLocalVariable 的存在意味着 RunnableEntity 需要对处于 implicitInterRunnableVariable 或 explicitInterRunnableVariable 角色的 VariableDataPrototype 进行写访问。writtenLocalVariable 的聚合受可变性约束，以支持 implicitInterRunnableVariable 和 explicitInterRunnableVariable 的条件存在或实现中 writtenLocalVariable（点）的变体存在。<br>Stereotypes: atpSplitable; atpVariation<br>Tags: atp.Splitkey=shortName, variationPoint.shortLabel<br>vh.latestBindingTime=preCompileTime |
|
||
|
||
---
|
||
|
||
## 翻译说明
|
||
|
||
- 本文档为 **AUTOSAR 标准化模板需求**（RS_STDT）的完整中文翻译，包含 19 个用例（UC_STDT_00001 至 UC_STDT_00019）和 53 条需求条目（RS_STDT_00001 至 RS_STDT_00125，含预留编号）。
|
||
- AUTOSAR 方框符 `⌈⌋` 用于标识需求块、用例块以及类表的起止。
|
||
- 需求 ID（如 `RS_STDT_00001`、`RS_BRF_01024`、`UC_STDT_00001`）保持英文。
|
||
- 关键术语（Blueprint、ARXML、PortBlueprint、PortInterface、PortPrototype、SwComponentType、DataPrototype、RunnableEntity、DataConstr、ModeDeclarationGroup、ECUC、SDGs、Category、VFB、OEM、Postbuild、VariationPoint、VariationPoint、BSW、SWS、TPS 等）保持英文。
|
||
- 文档间交叉引用（如 [RS_BRF_04016]、[RS_Main_00300]、[UC_IOAT_00030] 等）保持英文原样。
|
||
- 文档变更历史（附录 A）按版本号 4.0.3、4.1.1、4.1.2、4.1.3、4.2.1、4.2.2、4.3.0、4.3.1 顺序完整翻译。
|
||
- 引用的类表（附录 B）包含 DataPrototype 和 RunnableEntity 两个类表，所有元模型字段（包、基类、子类、属性、stereotypes、tags）保留英文。
|