27 KiB
AUTOSAR 特性模型交换格式需求
AUTOSAR CP Release 4.4.0
原文：AUTOSAR Feature Model Exchange Format Requirements（文档 ID 605）
翻译状态：已完成 v1（封面+前言+用例+需求+术语表完整翻译）
对应原文 PDF：
MethodologyAndTemplates/AUTOSAR_RS_FeatureModelExchangeFormat.pdf翻译日期：Step 3 - P0 批量翻译
文档标识
| 字段 | 值 |
|---|---|
| 文档标题（Document Title） | AUTOSAR 特性模型交换格式需求（AUTOSAR Feature Model Exchange Format Requirements） |
| 文档所有者（Document Owner） | AUTOSAR |
| 文档责任人（Document Responsibility） | AUTOSAR |
| 文档标识号（Document Identification No） | 605 |
| 文档状态（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 | 编辑性修订 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 编辑性修订 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 编辑性修订 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 编辑性修订 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 初始发布（Initial release） |
目录
参考文献（References）
- [1] Standardization Template，AUTOSAR_TPS_StandardizationTemplate
- [2] Software Process Engineering Meta-Model Specification，http://www.omg.org/spec/SPEM/2.0/
1 引言（Introduction）
1.1 文档约定（Document Conventions）
AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中规定的表格，详见《标准化模板》的"可追溯性支持"一章 ([1])。
用于表达义务的动词形式应遵循 [TPS_STDT_00053] 的规定，用以表示需求，详见《标准化模板》的"可追溯性支持"一章 ([1])。
1.2 需求追溯（Requirements Tracing）
下表引用本文档中规定的用例，并将其与本文档中实现的需求联系起来。
| 需求（Requirement） | 描述（Description） | 满足者（Satisfied by） |
|---|---|---|
| [UC_FMDT_00001] | 整体工作流（Overall Workflow） | [RS_FMDT_00001], [RS_FMDT_00002], [RS_FMDT_00013] |
| [UC_FMDT_00002] | 特性模型的交换（Exchange of Feature Models） | [RS_FMDT_00001], [RS_FMDT_00002], [RS_FMDT_00013] |
| [UC_FMDT_00003] | 特性的特征（Characteristics of Features） | [RS_FMDT_00005], [RS_FMDT_00006] |
| [UC_FMDT_00004] | 特性的限制（Restrictions for Features） | [RS_FMDT_00008] |
| [UC_FMDT_00005] | 特性的复杂限制（Complex Restrictions for Features） | [RS_FMDT_00008] |
| [UC_FMDT_00006] | 特性之间的关系（Relations among Features） | [RS_FMDT_00008] |
| [UC_FMDT_00007] | 特性的属性（Attributes for Features） | [RS_FMDT_00009] |
| [UC_FMDT_00008] | 特性模型的分布式开发 | [RS_FMDT_00011], [RS_FMDT_00012] |
| [UC_FMDT_00009] | 特性模型为可选（Feature Models are optional） | [RS_FMDT_00014] |
| [UC_FMDT_00010] | 为具体产品定义特性配置（Feature Configuration） | [RS_FMDT_00003] |
| [UC_FMDT_00011] | 特性配置的交换 | [RS_FMDT_00003] |
| [UC_FMDT_00012] | 特性的文档化 | [RS_FMDT_00004] |
| [UC_FMDT_00013] | 特性的多重性（Multiplicity of Features） | [RS_FMDT_00007] |
| [UC_FMDT_00014] | 关联特性建模与变体处理 | [RS_FMDT_00010] |
| [UC_FMDT_00015] | 协作式特性模型开发 | [RS_FMDT_00011], [RS_FMDT_00012] |
| [UC_FMDT_00016] | 特性的绑定时间（BindingTimes） | [RS_FMDT_00015], [RS_FMDT_00016] |
表 1.1：需求追溯
2 用例（Use Cases）
⌈[UC_FMDT_00001] 整体工作流⌋
OEM 使用工具集 A 开发 AUTOSAR 模型和一个特性模型。然后将两个模型传递给供应商完成补充。供应商使用工具集 B 增强工作内容，然后再回传给 OEM。OEM 重新导入 AUTOSAR 模型。此过程在开发周期内可能发生多次。
不同的工程领域为变体管理使用不同的特性建模工具，因为特定工具能更好地满足各自的需求；因此工具集 A 与 B 通常不同。
在开发期间的几个同步点上，不仅需要集成解决方案，也需要集成特性描述。⌊()
⌈[UC_FMDT_00002] 特性模型的交换⌋
OEM 开发一个 AUTOSAR 模型和一个特性模型。该特性模型实际上是在外部工具中维护的。这可能是因为 OEM 的工具链中不包含直接支持 AUTOSAR 特性模型的变体管理工具，或公司标准要求使用某种并不原生支持 AUTOSAR 特性模型格式的特定工具。
注：在此用例中，特性模型不会被供应商更改。⌊()
⌈[UC_FMDT_00003] 特性的特征⌋
特性模型开发者希望表达特性的某些特征：
- 为清晰起见，特性模型具有层次结构¹，其解读如下：仅当一个特性的父特性也被包含在产品中时，该特性才可能被包含在产品中。
- 一个特性对于一个产品是强制的（mandatory）。例如，汽车必须有一个方向盘。需要注意的是（与层次结构一致），这并不意味着该特性出现在每个产品中。强制特性仅当其父特性被包含在产品中时（但那时则总是）才被包含。例如，如果汽车配备了收音机，则扬声器也是强制的。
- 一个特性是可选的（optional），即它可能存在也可能不存在于产品中。例如，收音机或天窗是可选特性。
- 两个或多个特性被标记为互斥的（alternative）：其中只有一个必须出现在产品中。例如，汽车可能配备柴油发动机或汽油发动机。
- 两个或多个特性被标记为 multipleFeatures：其中至少一个必须存在（下限不为零，因为零情形已由可选特性覆盖）。可以选择多个特性。
¹ 此处的层次实际上是树形结构，意味着除最顶层之外每个元素恰好有一个父元素。
⌊()
⌈[UC_FMDT_00004] 特性的限制⌋
有时仅靠层次结构不足以表达特性模型上的所有约束。
例如，存在与国家相关的特性，如方向盘位置或速度表的默认设置。但不希望将"国家 x"作为高层级特性并把所有其他特性都置于其下，因为这会导致不必要的重复。
更好的做法是将"国家 x"特性置于特性树中的合适位置，然后从特性树的任何位置引用该特性。⌊()
具有国家相关限制的特性模型示例参见图 2.1（原文图，略）。
⌈[UC_FMDT_00005] 特性的复杂限制⌋
一个特性可能依赖于若干其他特性。也就是说，仅当所有这些其他特性也被包含在产品中时，它才被包含。这无法用 [UC_FMDT_00003] 中提议的层次结构表达。
此外，可能还会应用更复杂的限制类型。例如，[UC_FMDT_00004] 可以使用如下形式的更复杂公式：
(Germany or US) and not UK
UK and not (Germany or US)
(UK or US) and not Germany
Germany or not (UK or US)
⌊()
⌈[UC_FMDT_00006] 特性之间的关系⌋
与 [UC_FMDT_00004] 和 [UC_FMDT_00005] 类似，特性模型需要表达特性之间的关系，其中特性 A 需要或排除特性 B。
这也可以通过对特性 B 设置限制来表达（参见 [UC_FMDT_00004]、[UC_FMDT_00005]）。但有时无法对特性 B 作此更改，因为它所在的特性模型无法被修改。例如特性 B 可能由其他方"拥有"。
此外，关系通常比限制更易于理解或使用，因为它们是带特性列表的简单关键字，而不是公式。
因此，特性 A 必须能够表达其与特性 B 之间的关系。⌊()
图 2.2 给出了一个特性模型，遵循 [UC_FMDT_00004] 中图 2.1 的示例，但使用关系而非限制。请注意，关系的起点位于与国家相关的特性（Germany、UK、US）上，而前一模型中限制的位置在 Steering Wheel 和 Speedometer default 特性上。
其他关系的例子有 recommended for、discouraged for 和 impacts。
⌈[UC_FMDT_00007] 特性的属性⌋
特性建模者希望为特性提供附加信息，例如对应设备可使用的最大带宽。
如果存在若干选项（例如 [UC_FMDT_00003] 中的 multipleFeatures），每个特性对应一个独立设备，但这些设备可用的总带宽受总线特性限制，则此类信息有用。这将得到限制：
(child1.bandwidth + child2.bandwidth + child3.bandwidth) < maximumBandwidth
⌊()
⌈[UC_FMDT_00008] 特性模型的分布式开发⌋
特性模型由不同实体开发。这些实体可能是同一公司内的不同部门，或完全不同的公司。
例如，OEM 创建的、已经有特性模型的 AUTOSAR 软件模型与供应商创建的、带有自身特性模型的另一个软件模型集成。
再如，考虑两个独立的 AUTOSAR 软件组件，各自带有自己的特性模型。它们必须被集成到一个描述整个系统的大型 AUTOSAR 模型中，该模型也包含自身的特性模型。
如果每个方都能编辑并写入自己的文件，则这些例子能得到最佳处理。整体特性模型分布在若干文件中，或被拆分为若干个相互配合的不同特性模型。⌊()
⌈[UC_FMDT_00009] 特性模型为可选⌋
OEM A 借助特性模型开发 AUTOSAR 模型，并希望包含供应商 B 提供的软件组件。但 B 不使用特性建模（或虽使用但因知识产权或合同原因不共享其特性模型）。
这不妨碍使用 AUTOSAR 变体处理——后者的开发与特性建模相互独立。⌊()
⌈[UC_FMDT_00010] 为具体产品定义特性配置⌋
特性模型描述了一个产品线的特性及其相互依赖关系。其中一些特性可能是可选的。相反，具体产品由所选特性的集合描述，且所选特性集必须满足特性模型定义的各种约束。
为定义具体产品的特性，OEM（或供应商）选择特性模型中特性的一个子集。此外，必须检查特性选择是否满足特性模型中定义的各种约束（特别参见 [UC_FMDT_00003]、[UC_FMDT_00004]、[UC_FMDT_00005] 和 [UC_FMDT_00006]）。
此过程对于产品线内的每个适用产品反复进行。即可能存在多个特性配置。⌊()
⌈[UC_FMDT_00011] 特性配置的交换⌋
OEM 为产品线定义一个特性模型，然后按 [UC_FMDT_00010] 所述选择若干特性配置以定义各个产品。这些特性配置与特性模型一起被交付给供应商，以确保具体软件适用于预期的产品（即特性配置）。⌊()
⌈[UC_FMDT_00012] 特性的文档化⌋
经验表明，定义特性模型的结构（即有哪些特性、它们的层次结构、特征是什么）、建立特性之间的关系并定义哪些特性由哪些系统常量实现是一个耗时的过程。
尤其当为已存在的软件产品线创建特性模型时更是如此。通常会有来自不同部门的多人参与此任务。
因此，需要文档化在形成特性模型最终版本时所做决策的理由（why）。⌊()
⌈[UC_FMDT_00013] 特性的多重性⌋
在 [UC_FMDT_00003] 中被刻画为 multipleFeatures 的特性可以提供多重性约束。该约束限制了一个特性配置中可包含的特性数量。
例如，可能有 5 个 multipleFeatures 特性，但任何特性配置必须包含至少 2 个且至多 4 个此类特性。例如，控制面板可能包含若干开关，但最多只有空间容纳四个开关。⌊()
⌈[UC_FMDT_00014] 关联特性建模与变体处理⌋
创建特性模型后，开发者需要在特性模型与对应 AUTOSAR 模型中的变体点（variation points）之间建立链接。
特性与变体点之间的关系不是一对一关系。例如，一个特性可能影响多个变体点，或一个变体点可能受多个特性影响。⌊()
⌈[UC_FMDT_00015] 协作式特性模型开发⌋
OEM 创建一个特性模型，将其导出为 AUTOSAR 特性模型，并传递给供应商。供应商修改该模型并回传给 OEM。OEM 然后导入该模型。⌊()
⌈[UC_FMDT_00016] 特性的绑定时间⌋
开发者限制特性实现的可能绑定时间，例如规定某特性至少应作为 PreCompileTime 实现。这在特性模型中描述。
此外，有两个面向不同客户的特性选择：一个客户希望使用 PreCompileTime 实现，另一个客户希望使用 PostBuild 解决方案。这在特性选择中描述。⌊()
3 需求（Requirements）
⌈[RS_FMDT_00001] 支持产品线⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 特性模型交换格式应能以一组相关产品的形式表达产品线的基本功能，这些产品可以具有相同或共享的特性。 |
| 理由 | – |
| 用例 | [UC_FMDT_00001]、[UC_FMDT_00002] |
| 依赖 | – |
| 支撑材料 | – |
⌊(UC_FMDT_00001, UC_FMDT_00002)
⌈[RS_FMDT_00002] 特性⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 特性模型交换格式应能以特性的形式表达产品的基本功能。 |
| 理由 | – |
| 用例 | [UC_FMDT_00001]、[UC_FMDT_00002] |
| 依赖 | – |
| 支撑材料 | – |
⌊(UC_FMDT_00001, UC_FMDT_00002)
⌈[RS_FMDT_00003] 特性选择⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 特性模型交换格式应提供特性选择机制，用于定义具体产品的特性集合。 |
| 理由 | – |
| 用例 | [UC_FMDT_00010]、[UC_FMDT_00011] |
| 依赖 | – |
| 支撑材料 | – |
⌊(UC_FMDT_00010, UC_FMDT_00011)
⌈[RS_FMDT_00004] 特性应具有名称⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 特性模型交换格式应能为特性命名并加以描述。 |
| 理由 | – |
| 用例 | [UC_FMDT_00012] |
| 依赖 | [RS_FMDT_00003] |
| 支撑材料 | – |
⌊(UC_FMDT_00012)
⌈[RS_FMDT_00005] 特性分解⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 特性模型交换格式应能将一个特性分解为若干子特性。 |
| 理由 | – |
| 用例 | [UC_FMDT_00003] |
| 依赖 | [RS_FMDT_00003] |
| 支撑材料 | – |
⌊(UC_FMDT_00003)
⌈[RS_FMDT_00006] 子特性的特征⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 子特性应具有不同的特征，例如"Mandatory（强制）"、"Optional（可选）"和"Alternative（互斥）"。 |
| 理由 | – |
| 用例 | [UC_FMDT_00003] |
| 依赖 | [RS_FMDT_00002]、[RS_FMDT_00005] |
| 支撑材料 | – |
⌊(UC_FMDT_00003)
⌈[RS_FMDT_00007] 特性的多重性⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 特性应能表达多重性。这仅与 [UC_FMDT_00013] 中提到的 multipleFeatures 类型组合相关。Mandatory、Optional 和 Alternative 特性没有多重性。 |
| 理由 | – |
| 用例 | [UC_FMDT_00013] |
| 依赖 | [RS_FMDT_00002]、[RS_FMDT_00007] |
| 支撑材料 | – |
⌊(UC_FMDT_00013)
⌈[RS_FMDT_00008] 特性之间的关系⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 特性应能表达与其他特性的不同关系，例如"required（必需）"、"excluded（排除）"和"impacted（影响）"。 |
| 理由 | – |
| 用例 | [UC_FMDT_00004]、[UC_FMDT_00005]、[UC_FMDT_00006] |
| 依赖 | [RS_FMDT_00002]、[RS_FMDT_00005] |
| 支撑材料 | – |
⌊(UC_FMDT_00004, UC_FMDT_00005, UC_FMDT_00006)
⌈[RS_FMDT_00009] 特性的属性⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 特性应能拥有各种属性。 |
| 理由 | – |
| 用例 | [UC_FMDT_00007] |
| 依赖 | [RS_FMDT_00002] |
| 支撑材料 | – |
⌊(UC_FMDT_00007)
⌈[RS_FMDT_00010] 与 AUTOSAR 变体处理的集成⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 特性模型交换格式应与现有 AUTOSAR 变体处理解决方案集成。 |
| 理由 | – |
| 用例 | [UC_FMDT_00014] |
| 依赖 | – |
| 支撑材料 | – |
⌊(UC_FMDT_00014)
⌈[RS_FMDT_00011] 特性模型应可拆分⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 特性模型交换格式应提供将特性模型拆分到若干 ARXML 文件中的手段。 |
| 理由 | – |
| 用例 | [UC_FMDT_00008]、[UC_FMDT_00015] |
| 依赖 | – |
| 支撑材料 | – |
⌊(UC_FMDT_00008, UC_FMDT_00015)
⌈[RS_FMDT_00012] 特性模型的分布式维护⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 特性模型交换格式应提供将维护分发给不同方的手段。 |
| 理由 | – |
| 用例 | [UC_FMDT_00008]、[UC_FMDT_00015] |
| 依赖 | – |
| 支撑材料 | – |
⌊(UC_FMDT_00008, UC_FMDT_00015)
⌈[RS_FMDT_00013] 集成到 AUTOSAR 方法论中⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 特性模型交换格式应能集成到整体 AUTOSAR 方法论中。 |
| 理由 | – |
| 用例 | [UC_FMDT_00001]、[UC_FMDT_00002] |
| 依赖 | – |
| 支撑材料 | – |
⌊(UC_FMDT_00001, UC_FMDT_00002)
⌈[RS_FMDT_00014] 特性模型为可选⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 在符合 AUTOSAR 的开发周期范围内，使用特性模型交换格式是可选的。这类似于 AUTOSAR 变体处理；不使用变体处理的 AUTOSAR 模型依然是有效模型。 |
| 理由 | – |
| 用例 | [UC_FMDT_00009] |
| 依赖 | – |
| 支撑材料 | – |
⌊(UC_FMDT_00009)
⌈[RS_FMDT_00015] 特性可指定绑定时间⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 一个特性可以定义其实现的目标绑定时间。该属性应视为一种提示。 |
| 理由 | – |
| 用例 | [UC_FMDT_00016] |
| 依赖 | – |
| 支撑材料 | – |
⌊(UC_FMDT_00016)
⌈[RS_FMDT_00016] 特性选择可指定绑定时间⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效（valid） |
| 描述 | 一个特性选择可以定义所选绑定时间，进一步细化 [RS_FMDT_00015] 中的目标绑定时间。该属性应视为一种提示。 |
| 理由 | – |
| 用例 | [UC_FMDT_00016] |
| 依赖 | – |
| 支撑材料 | – |
⌊(UC_FMDT_00016)
A 术语表（Glossary）
- Artifact（构件）：一种工作产品定义，提供有形工作产品类型的描述和定义。构件可由其他构件组成 ([2])。在高层级上，构件被表示为单个概念文件。
- AUTOSAR Tool（AUTOSAR 工具）：支持在方法论中定义为 AUTOSAR 任务的一个或多个任务的软件工具。根据所支持的任务，AUTOSAR 工具可作为 authoring tool（创作工具）、converter tool（转换工具）、processor tool（处理工具）或它们的组合（参见单独定义）。
- AUTOSAR Authoring Tool（创作工具）：用于创建和修改 AUTOSAR XML 描述的 AUTOSAR 工具。例：System Description Editor。
- AUTOSAR Converter Tool（转换工具）：通过转换其他 AUTOSAR XML 文件中的信息来创建 AUTOSAR XML 文件的 AUTOSAR 工具。例：ECU Flattener。
- AUTOSAR Definition（AUTOSAR 定义）：可拥有值的参数的定义。可以说参数值是定义的实例（Instances）。但在 AUTOSAR 元模型层次结构中，定义本身也是元模型的实例，因此被视为描述。AUTOSAR 定义示例：
EcucParameterDef、PostBuildVariantCriterion、SwSystemconst。 - AUTOSAR XML Description（AUTOSAR XML 描述）：在 AUTOSAR 中意为"已填充的模板"。事实上，AUTOSAR XML 描述是 AUTOSAR 模型的 XML 表示。AUTOSAR XML 描述可由多个文件组成。每个文件代表一个 AUTOSAR 部分模型（partial model），并应能成功通过 AUTOSAR XML Schema 验证。
- AUTOSAR Meta-Model（AUTOSAR 元模型）：定义用于描述 AUTOSAR 系统的语言的 UML 2.0 模型。AUTOSAR 元模型是 AUTOSAR 模板的 UML 表示。UML 2.0 类图用于描述属性及其相互关系；构造型（Stereotypes）、UML tags 和 OCL（对象约束语言）表达式用于定义特定语义和约束。
- AUTOSAR Meta-Model Tool（AUTOSAR 元模型工具）：用于在 AUTOSAR 元模型上生成不同视图（类表、约束列表、图、XML Schema 等）的工具。
- AUTOSAR Model（AUTOSAR 模型）：AUTOSAR 产品的表示。AUTOSAR 模型按照 AUTOSAR 方法论表示适合预期用途的方面。严格说来，它是 AUTOSAR 元模型的一个实例。AUTOSAR 模型中包含的信息可以是按 AUTOSAR 元模型可表示的任何内容。
- AUTOSAR Partial Model（AUTOSAR 部分模型）：模型的可能分割在元模型中由
atpSplitable标记。一个部分模型在 AUTOSAR XML 描述中由一个文件表示。部分模型无需满足适用于完整 AUTOSAR 模型的所有语义约束。 - AUTOSAR Processor Tool（处理工具）：通过处理 AUTOSAR XML 文件中的信息来创建非 AUTOSAR 文件的 AUTOSAR 工具。例：RTE Generator。
- AUTOSAR Specification Element（AUTOSAR 规范元素）：AUTOSAR 规范中具名的元素。示例：需求、约束、规范条目、元模型中的类或属性、方法论、交付物、方法论活动、模型元素、BSW 模块等。
- AUTOSAR Template（AUTOSAR 模板）："Template"一词在 AUTOSAR 中用于描述各种描述的格式。该术语源于这样的理念：AUTOSAR 定义了一种应填写以描述模型的表单。填写后的表单称为描述（description）。事实上 AUTOSAR 模板现在被定义为元模型。
- AUTOSAR Validation Tool（验证工具）：专门用于检查 AUTOSAR 模型是否符合 profile 所定义规则的 AUTOSAR 工具。
- AUTOSAR XML Schema（AUTOSAR XML 模式）：定义用于交换 AUTOSAR 模型的语言的 W3C XML schema。该 Schema 由 AUTOSAR 元模型派生，定义了 AUTOSAR 数据交换格式。
- Blueprint（蓝图）：一种模型，可通过复制和精细化（refinement）从中派生其他模型。注意与元模型/类型不同，此过程不是实例化。
- Instance（实例）：通常是模型或类型的具体范例。
- Life Cycle（生命周期）：模型元素在其生命周期中经历的开发/演进阶段过程。
- Meta-Model（元模型）：定义模型的构建块。从这个意义上说，元模型代表用于构建模型的语言。
- Meta-Data（元数据）：与数据相关的相关信息，包括作者、版本控制、访问权限、时间戳等。
- Model（模型）：现实的简化表示。模型表示适合于预期目的的各个方面。
- Partial Model（部分模型）：拟在一个特定构件中持久化的模型的一部分。
- Pattern（模式）：在 GST 中：通过应用模型转换以简化元模型定义的方法。这种转换从带注解的模型中创建增强模型。
- Profile Authoring Support Data：用于高效创作 profile 的数据。例如可引用的约束、元类、元属性或其他可复用模型资产（blueprints）的列表。
- Profile Authoring Tool：专注于为数据交换点创作 profile 的专用 AUTOSAR 工具。例如提供从零开始创建 profile、修改已有 profile 或组合已有 profile 的支持。
- Profile Compatibility Checker Tool：专注于检查用于数据交换的 profile 兼容性的专用 AUTOSAR 工具。注意此兼容性检查包括工程师手动兼容性检查以及使用更形式化算法的自动辅助。
- Profile Consistency Checker Tool：专注于检查 profile 一致性的专用 AUTOSAR 工具。
- Property（属性）：对象的结构特征。例如"connector"具有属性"receive port"和"send port"。属性通过
atpVariation标记为可变体。 - Prototype（原型）：一个类型的角色在另一个类型定义内的实现。换言之，一个类型可包含原型，原型又被"Types"所类型化。当该类型被实例化时，每个原型都变成一个实例。
- Type（类型）：提供可在该类型的各种角色中出现的特征。
- Value（值）：分配给"Definition"的特定值。
- Variability（变体性）：系统的变体性是其描述一组变体（variants）的特性。这些变体由特定变体的属性设置和/或选择刻画。例如，此种系统属性选择会以连接的特定"receive port"形式呈现。这通过
atpVariation实现。 - Variant（变体）：系统变体是系统的具体实现，其所有属性都已被设置或选择。该软件系统在该绑定时间方面不再具有变体性。这通过
EvaluatedVariantSet实现。 - Variation Binding（变体绑定）：变体是变体绑定过程的结果，该过程通过为系统的所有属性赋以特定值/选择来解析系统的变体性。这通过
VariationPoint实现。 - Variation Binding Time（变体绑定时间）：变体绑定时间确定方法论中解析由一组可变属性赋予的变体性的步骤。这通过相关属性上的
vh.LatestBindingtime实现。 - Variation Definition Time（变体定义时间）：变体定义时间确定方法论中定义变体点的步骤。
- Variation Point（变体点）：变体点表示一个属性受变体性影响。此外，它与一个条件和一个绑定时间相关联，二者共同定义选择/设置具体变体的系统上下文。这通过
VariationPoint实现。
翻译说明
- 本文档为 AUTOSAR 特性模型交换格式需求（RS_FMDT）的完整中文翻译，包含 16 条用例和 16 条需求，并附完整术语表。
- AUTOSAR 方框符
⌈⌋用于标识用例/需求块的起止。 - 元模型类型名、属性名（如
atpVariation、VariationPoint、EvaluatedVariantSet、atpSplitable、vh.LatestBindingtime）保持英文。 - 特性建模专用术语（如 Mandatory、Optional、Alternative、multipleFeatures、PreCompileTime、PostBuild）首次出现时给出英文原文。
- 用例 ID（UC_FMDT_xxxxx）与需求 ID（RS_FMDT_xxxxx）保持英文。