feifei.xu/autosar_standard_spec_v4.4
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6f293acbf70ce755cc397f46142c440f608e4284
autosar_standard_spec_v4.4/MethodologyAndTemplates/AUTOSAR_TPS_GenericStructureTemplate.md
T

87 KiB
Raw Blame History

通用结构模板 (Generic Structure Template)

AUTOSAR CP Release 4.4.0

项目 内容
文档标题 (Document Title) Generic Structure Template
文档所有者 (Document Owner) AUTOSAR
文档责任方 (Document Responsibility) AUTOSAR
文档标识号 (Document Identification No) 202
文档状态 (Document Status) Final
所属 AUTOSAR 标准 (Part of AUTOSAR Standard) Classic Platform
所属标准版本 (Part of Standard Release) 4.4.0

文档变更历史 (Document Change History)

日期 版本 修改者 描述
2018-10-31 4.4.0 AUTOSAR Release Management • Update Splitable
• Include ARMQL
• Refine atp.Status
2017-12-08 4.3.1 AUTOSAR Release Management • Introduction of FileInfoComment
• Ordered collections
• Naming conventions in variant handling patterns
• Extend AttributeValuePattern for enumeration
2016-11-30 4.3.0 AUTOSAR Release Management • Editorial changes
• Control the production of specification documents
• Added section on Special Data Group Definitions
2015-07-31 4.2.2 AUTOSAR Release Management • Update View Approach
• Combinations of status values
• Update Inline Text Model Element
2014-10-31 4.2.1 AUTOSAR Release Management • Propagation of LifeCycleState
• Editorial changes
2014-03-31 4.1.3 AUTOSAR Release Management • Update of blueprint topics
• Extension of variant handling topics
• Editorial changes
2013-10-31 4.1.2 AUTOSAR Release Management • Editorial changes
• Extension of formula language
2013-03-15 4.1.1 AUTOSAR Administration • Editorial changes including tagged specification items
• Support of build action manifest
• Support of roles and rights
• Added life cycle support
• Support of collections and collectable elements
• Editorial changes including tagged specification items
• Improvements in UML usage (M3), especially mark obsolete elements
2011-12-22 4.0.3 AUTOSAR Administration • Improved specification of primitives, primitive definition, formula language, category
• Improved variant handling and blueprint support
• Improved support for instanceRef and arrays
• Improved definition of package structures
• Editorial changes
2010-02-02 3.1.4 AUTOSAR Administration • Improvements in variant handling (Package content, composed predefined variants)
• Align Formula language with ASAM General Expression Language
• Generalized approach for annotations
• Improved alignment with ASAM - FSX
• Document the admin.* uml tags.
• Support global referencing and tracing
• restructured the document
• support for variant handling
• support for abstract structures
• documentation support
• detailed primitives
• general modeling information required to understand other templates
2009-12-18 4.0.1 AUTOSAR Administration • Editorial changes including tagged specification items
• Improved definition of package structures
• Editorial changes
2008-08-13 3.1.1 AUTOSAR Administration • Legal disclaimer revised
• Rename document from "Template Modeling Patterns" to "Generic Structure Template"
2007-12-21 3.0.1 AUTOSAR Administration • Updated Attributes of Identifiable
• Added "Hint to the Users"
• Added document identification no
• Added document classification
2007-01-24 2.1.15 AUTOSAR Administration • Legal disclaimer revised
• "Advice for users" revised
• "Revision Information" added
2006-05-16 2.0 AUTOSAR Administration • Second release

注：原文中的版权声明（Disclaimer）按规范要求不翻译，保留原文。

目录 (Table of Contents)

1 介绍 (Introduction)

本文档包含 AUTOSAR 通用结构模板 (Generic Structure Template) 的规范说明。实际上，它是作为 AUTOSAR 元模型 [1] 形式化定义的补充而创建的。换言之，除了形式化规范之外，本文档还对几乎所有 AUTOSAR 模板都相关的 AUTOSAR 元模型部分提供了介绍性描述和基本原理。

尽管如此，规范的核心部分直接基于 AUTOSAR 元模型的内容。因此，本文档包含 AUTOSAR 元模型主要概念的摘要，请参阅第 1.3 和 1.4 章节。

本文档提供参考信息，并非按顺序阅读。它包含的主要内容如下：

  1. 第 3 章 解释了对所有 AUTOSAR 模板通用的顶层结构。
  2. 用于设计 AUTOSAR 模板的机制：
    • (a) 第 2 章 描述了 AUTOSAR 模板 UML 配置文件的必要基本方面，这些方面是理解 AUTOSAR 模板文档所必需的。
    • (b) 第 4 章 描述了通用模板类，其收集方式类似于编译器的标准库。
    • (c) 第 5 章 解释了具有抽象关系的抽象类。这些结构实现了适用于所有 AUTOSAR 模板的特定概念。这些概念通过专门化这些抽象类、特别是专门化抽象关系来应用。
    • (d) 第 6 章 总体说明了通过模型转换应用的方法（例如变体处理）。
  3. 元模型中设计机制的某些特定应用：
    • (a) 第 7 章 描述了基于元建模模式（在第 6 章中描述）的 AUTOSAR 模板内变体处理的实现。
    • (b) 第 9 章 描述了文档支持。

1.1 范围 (Scope)

本文档的范围涵盖理解 AUTOSAR 模板以及定义这些模板所使用的核心机制所需的信息。执行模板建模任务所需的 UML 建模方面不在本文档的范围内。

1.2 文档约定 (Document Conventions)

技术术语使用等宽字体排版，例如 PortPrototype。作为一般规则，技术术语的复数形式是在单数形式后添加 "s" 创建的，例如 PortPrototypes。通过这种方式，文档类似于 AUTOSAR XML Schema 中使用的术语。

本文档包含以文本形式表示的约束，它们通过唯一的数字约束 ID、标题和实际的约束文本（以 d 字符开始、以 c 字符结束）与其他文本区分开来。

这些约束的目的是字面约束 AUTOSAR 元模型的解释，以便能够检测元模型实例（即 M1 级别）中违反标准化行为的情况。鼓励 AUTOSAR 工具的制作者将对应于 M1 建模问题的约束的数字 ID 作为工具发出的诊断消息的一部分添加。

本文档中介绍的类的属性以类表 (Class Tables) 的形式列出。它们的形式如顶层元素 AUTOSAR 的示例所示：

字段 含义
Class UML 模型中定义的类的名称
Package 类定义所在的 UML 包。这仅列出是为了帮助在整体元模型中定位该类
Note 建模者为该类提供的注释（类注释）。类的构造型和 UML 标签也在这里注明
Base Classes 如果适用，直接基类的列表

表格表头含义：

表头 含义
Attribute 类的属性名称。请注意，AUTOSAR 不区分类属性和所属关联端
Type 类的属性的类型
Mul. 属性的指定多重性 (multiplicity)，即与该属性关联的给定数据类型的实例数
Kind 指定属性是在类中聚合的（aggr 聚合）、类中的 UML 属性（attr 原始属性），还是仅由它引用（ref 引用）。实例引用也在此字段中指示（iref 实例引用）
Note 建模者为类属性（角色注释）提供的注释。类的构造型和 UML 标签也在这里注明

请注意，以字母（而非数字）开头的章节表示文档的附录。附录的目的是支持文档某些方面的解释，并不代表标准的约束性约定。

义务表达的口头形式应在 [TPS_STDT_00053] 中规定，用于指示要求，请参阅 Standardization Template 章节"对可追溯性的支持" ([2])。AUTOSAR 文档中要求的表示遵循 [TPS_STDT_00078] 中指定的表格。

1.3 定义正式模板的方法论 (Methodology for Defining Formal Templates)

图 1.1 说明了用于使用系统模板作为示例定义正式模板的总体方法论。需要捕获在 AUTOSAR XML 文件中的信息的精确简洁模型在 [1] 中提供。

图 1.1：使用 SystemTemplate 作为示例在 AUTOSAR 中定义模板的方法论

下图所示的方法论涉及以下文档：

  1. 模板文档（此例中为 System Template）描述了模板中可以捕获的信息，独立于此模型在 XML 技术上的映射。它包含可捕获在 AUTOSAR 元模型相关部分内的所有信息的语义的详细描述（精确含义）。
  2. AUTOSAR 元模型 [1] 中称为 M2 Templates 的模型包含以 UML 建模的 AUTOSAR 模板的结构。该模型使用注释进行注释，这些注释也表示为模板文档中的类表。
  3. 称为 Generic Structure Template（本文档）的文档在元模型中表示为预定义的类，这些类合并到生成的模式中。
  4. Template UML Profile and Modeling Guide 描述了在创建元模型内容时应用的基本概念。这些信息在第 2 章中呈现。
  5. 称为 XML Schema Production Rules [3] 的文档描述了 XML 的使用方式以及如何将"软件组件模板"中设计的元模型由"Schema Generator"（MDS）翻译为 XML-Schema (XSD) "Data Exchange Format"。这种"形式化策略"应可用于正式描述在元模型中的所有数据。特别是为了理解元模型和基于 XML 的 AUTOSAR 模板的映射，值得阅读本文档。
  6. Data Exchange Format 表示为使用 AUTOSAR 元模型方法及 XML Schema Production Rules 中定义的模式自动生成的 XML 模式。该模式通常用作 AUTOSAR 工具的输入。
  7. M1 级别描述（在图 1.1 中显示为"System configuration description"和"System Constraint Description"）是可以根据 XML 模式验证的 XML 文件，并进一步遵循相关"模板文档"中的规范。换言之，XML 文件是定义模板 XML 表示的模式的实例。

1.4 元模型组织 (Organization of the Meta-Model)

图 1.2 概述了元模型的整体结构，该结构正式定义了描述 AUTOSAR 软件组件所需的词汇表。如下图所示，其他模板规范（例如 ECU Resource Template [4] 和 System Template [5]）也使用相同的建模方法来定义 AUTOSAR 软件描述的总体一致模型。

图 1.2：元模型的结构

图中的虚线箭头描述了元模型内包之间的导入关系依赖关系。例如，包 SWComponentTemplate 导入在包 GenericStructure（在本文档中描述）和 ECUResourceTemplate [4] 中定义的元类。

为澄清起见，请注意包 GenericStructure 包含一些基础架构元类和通用模式。由于这些被所有其他模板规范使用，为清楚起见，依赖关系关联未在图中描述。

元模型包含的主要子包：

  • AutosarTopLevelStructure — 顶层结构
  • CommonStructure — 通用结构
  • SWComponentTemplate — 软件组件模板
  • EcuResourceTemplate — ECU 资源模板
  • AdaptivePlatform — 自适应平台
  • SystemTemplate — 系统模板
  • DiagnosticExtract — 诊断提取
  • ECUCDescriptionTemplate — ECUC 描述模板
  • ECUCParameterDefTemplate — ECUC 参数定义模板
  • BswModuleTemplate — BSW 模块模板
  • StandardizationTemplate — 标准化模板
  • GenericStructure — 通用结构
  • FeatureModelTemplate — 特征模型模板

2 AUTOSAR 模板中 UML 的使用 (Usage of UML in AUTOSAR Templates)

AUTOSAR 元模型被定义为 UML 模型。因此，需要具备 UML 的基础知识才能理解 AUTOSAR 模板文档。

2.1 UML 图 (UML Diagrams)

AUTOSAR 模板文档中的图与 UML 2.0 一致。底层模型（AUTOSAR 元模型）被认为是完整的，即使某些元素可能未在特定图中显示以简化理解。尽管如此，类表显示了所有相关信息。

图的着色通常在周围的文本中解释。但一般而言，浅绿色的元类是从 ASAM/MSR 取得的那些类。实例引用的表示如图 5.9 所示（见 [TPS_GST_00044]）。

2.2 AUTOSAR 元模型层次结构 (The AUTOSAR Meta-Model Hierarchy)

AUTOSAR 模板的完整元模型层次结构如图 2.1 所示。与 OMG 使用的经典四层架构不同，图中显示了五个元级别。从最低、最具体的元级别开始，它们是：

  • M0：AUTOSAR 对象

    • 这是工作中的 AUTOSAR 系统的实现：例如，执行包含挡风玻璃雨刷控制软件等软件映像的真实 ECU。

  • M1：AUTOSAR 模型

    • 此元级别上的模型由 AUTOSAR 开发人员构建。它们可以定义一个称为"windshield wiper"的软件组件，该组件具有连接到另一个软件组件的特定端口集等等。在此级别上，详细描述了 AUTOSAR 系统所需的所有构件，包括可重用类型以及此类类型的特定实例。
    • AUTOSAR 软件被加载到各个 ECU 中以供各个车辆使用。这种加载意味着 M1 模型被实例化。
    • 请注意，这样的 AUTOSAR 模型可以使用各种格式表示，范围从 XML 到 C 甚至到 PDF。

  • M2：AUTOSAR 元模型

    • 在此元级别上，定义了 AUTOSAR 模板的词汇表。此词汇表稍后可以由基于 AUTOSAR 的 ECU 系统的开发人员使用。
    • 例如，在 M2 上定义了在 AUTOSAR 中有一个称为"software component"的实体，该实体特别聚合了一个称为"port"的实体。此定义确保了 AUTOSAR 软件组件的开发人员可以描述其特定组件及其端口。此描述称为 AUTOSAR 模型，位于 M1 上。

  • M3：UML 配置文件，用于 AUTOSAR 模板

    • M2 上的 AUTOSAR 模板是根据 M3 上定义的元模型构建的。如前所述，这是 UML 与特定 UML 配置文件的结合，以更好地支持模板建模工作。
    • 从形式上讲，M2 上的模板仍然是 UML 的实例，但同时应用了模板配置文件，即需要遵守配置文件中构造型所规定的其他规则。配置文件的第 2.3 和 2.4 章中指定了相关细节。

图 2.1：元模型层次结构

模型间的转换关系：

  • MOF 2.0 是 OMG 元对象设施，位于元元模型层。
  • UML 2.0 通过 《instanceOf》 关联到 MOF。
  • AUTOSARTemplateProfile 通过 《profile》 关系应用于 UML，构成 AUTOSAR 元元模型 (M3)。
  • AUTOSAR Templates（M2）通过 《instanceOf》 关系从 M3 实例化，包含 ECU、Port、Mapping 等元类。
  • AUTOSAR User Models（M1）通过 《instanceOf》 关系从 M2 实例化，例如 ComponentType "WindshieldWiper"。
  • AUTOSAR User Objects（M0）通过 《instanceOf》 关系从 M1 实例化，例如 0x00f0a000 处的组件实例。

注意，AUTOSAR 模型可以使用各种格式表示，范围从 XML 到 C 甚至到 PDF。这些格式之间的转换称为"transformation"，而 AUTOSAR 模型遵循 AUTOSAR 元模型的事实称为"instantiation"。因此，AUTOSAR 模型 (M1) 称为 AUTOSAR 元模型 (M2) 的实例。

2.3 构造型 (Stereotypes)

AUTOSAR 模板配置文件使用以下构造型¹：

  • [TPS_GST_00022] «atpAbstract»，适用于关系（关联、聚合）— 这表示该关系是抽象的。在每个具体子类中都需要有专门的关系重新定义抽象关系。该构造型用于在图中提供更好的可视化。该关系是抽象的通过在模型中将角色定义为"derived"来建模。它在图中的角色名称前用"/"表示。«atpAbstract» 的关系仅存在于超类中，并且不继承到子类。它们需要在子类中重新定义²。 c()

  • [TPS_GST_00023] «atpDerived»，适用于关系（关联、聚合）— 这表示该关系通过继承存在于子类中。它进一步表示在 M1 模型中，该关系是从其他信息计算（派生）的。有两种计算类型：

    • general（一般）：表示该值通过元模型中描述的方法计算。例如，atpBase 被计算为第一个 atpContextElement 的容器。
    • derived union（派生联合）：表示它被派生为所有具体关系的联合。

    例如，从 AtpClassifier 到 AtpFeature 的聚合，角色为 atpFeature，是 «atpDerived»，SwComponentType 除了 component、port 等之外还有一个 atpFeature 关联。这个 atpFeature 被计算为具体特征的并集。派生联合意味着对于给定的组件类型，其 atpFeature 属性包含其端口 AND 其包含的组件原型 AND 其包含的连接器。这允许在抽象级别上定义实例引用。有关更多详细信息，请参阅第 5 章。 c()

  • [TPS_GST_00024] «atpMixed»，适用于类 — 这仅应用于元类，表示没有混合文本的混合内容模型。 c()

  • [TPS_GST_00025] «atpMixedString»，适用于类 — 这是带混合文本的混合内容模型。这仅应用于元类。有关更多详细信息，请参阅第 2.3.1 章。 c()

  • [TPS_GST_00026] «atpObject»，适用于类 — 这是一个隐式基类。它只能提供标记为 xml.attribute=true 的属性。 c() 有关更多详细信息，请参阅第 6.3.3 章。

  • [TPS_GST_00027] «atpSplitable»，适用于关系 — 通过使用构造型 «atpSplitable»，元模型可以明确定义元模型的实例如何分布在多个文件中。默认情况下，所有数据都存储在一个文件中。如果应用了 «atpSplitable»，则关联或聚合的信息可以存储在不同的文件中。 c() 有关更多详细信息，请参阅 [6] 中的用例 [UC_IOAT_00009]、[UC_IOAT_00004]、[UC_IOAT_00005] 和 [UC_IOAT_00001]，并参阅第 8 章。

  • [TPS_GST_00028] «atpVariation»，适用于类和关系 — 这表示变体处理。它应用于元类以及关联或聚合。 c() 有关更多详细信息，请参阅第 7 章。

  • [TPS_GST_00029] «atpUriDef»，适用于关联 — 这表示基本信息只是 reference.target 的完全限定名称。然后将其整体用作特定目的的标识符。该关联充当 AUTOSAR 模型中一种"通用资源标识符 (URI)"的定义。请注意，在这种情况下，只有完全限定的 shortName 路径是重要的，而不是目标的 shortName 或目标本身。特定语义以及因此的后续处理取决于单个用例。 c() 因此，不总是需要真正遵循构造型 «atpUriDef» 的引用。除非用户或特定用例明确要求，否则工具不应警告此构造型的不存在引用。例如，在 EcucReferenceDef.destination 中，引用表示 EcucReferenceValue 的有效目标必须是 EcucContainerValues，其定义源自 EcucReferenceDef.destination 的目标。但即使 EcucReferenceDef.destination 的目标不可用，也可以验证。

  • [TPS_GST_00030] «instanceRef»，适用于依赖 — 这用于在图中提供实例引用的简化表示。 c() 有关实例引用的更多详细信息，请参阅第 5.1.3 章。

  • [TPS_GST_00031] «isOfType»，适用于关联 — 这用于强调原型（AtpPrototype 的子类）和类型（AtpType 的子类）之间的具体关系。 c() 该构造型影响第 6.3.2³ 章中关联的生成。

¹ 这些构造型的名称以 atp 开头，是 "Autosar Template Profile" 的缩写。 ² 由于这种重新定义，XSD 生成器会忽略此类抽象关系。 ³ 请注意，此构造型对于此类关联需要直接或间接重新定义角色 atpType 这一事实是冗余的。

2.3.1 混合内容（«atpMixed»、«atpMixedString»）

如果一个元类有多个属性（可能包括聚合或引用），则在某些情况下，M1 模型中的"序列化"表示（如 XML）将语义添加到属性的实际顺序和出现次数。可能还需要同一属性在多个实例中（在 M1 中）出现，这些实例与其他属性实例混合。UML 无法以简单的方式表达这种情况。

此外，如果模型需要描述类似文档的信息，它通常需要混合形式化内容和文本。这种模型的示例是 HTML 中的嵌入式链接：形式化信息位的标记混合到常规文本中，如下例所示：

[...]meet <a href="/wiki/Runtime" title="Runtime">runtime</a> requirements
of automotive devices[...]

此示例说明"混合内容"功能在 XML 世界中众所周知，称为 mixed content⁴。

[TPS_GST_00032] 混合内容的基本特征 — 以下列表从建模角度指示混合内容的功能。在混合内容实例中：

  • 一组形式上定义的模型元素可以以任意顺序出现任意次数
  • 但实际存在的顺序对于整个对象的语义是相关的
  • 在 «atpMixedString» 的情况下，未限定的文本可以混合在任何形式定义的元素之间。 c()

AUTOSAR 通过以下构造型支持此机制：

  • «atpMixedString» 允许数据元素之间的文本（[TPS_GST_00025]）
  • «atpMixed» 允许任何此类类的属性以任何顺序混合（[TPS_GST_00024]）

后一种构造型不允许混合文本，但保留了语法和语义方面的顺序定义。

[TPS_GST_00033] 混合内容中的上界多重性 — 混合内容类将在模板模型中聚合或引用多个其他类。这些关系的目标多重性通常为 1，因为根据 [TPS_GST_00032] 中给出的定义，总体出现次数是任意的。

但是，如果多重性不等于 1，则指定了所需的分组。 c() 例如，如果目标多重性为 2，则必须将一对（而不仅仅是一个）这些对象放入混合内容中，依此类推。

图 2.2：混合内容

图 2.2 说明了它是如何工作的。M1 模型以 XML 显示。请注意：

  1. MixedContent 可以是任意顺序的 a、b、c、d、e 的任意混合。顺序在语义上是重要的。这与聚合的上界多重性 > 1 注释为 UML 中的 {ordered} 的意义相同⁵。
  2. c 的上界多重性 > 1，因此存在多重性的包装器
  3. e 在法律上缺失，因为根据定义总体出现次数是任意的。

[TPS_GST_00045] 混合内容中的继承属性：

  • 继承的混合属性是混合内容的一部分，可以与自己的混合属性自由混合。
  • 从不 «atpMixed» 本身的类继承的属性不是混合内容的一部分。
  • 属性（xml.attribute 设置为 true）和继承的属性不是混合内容的一部分。

进一步注意，在 «atpMixedString» 中，除了 xml.attribute 设置为 true 的属性外，没有其他继承属性。 c()

⁴ http://www.w3schools.com/schema/schema_complex_mixed.asp ⁵ 在 UML 中无法为此类类表示此注释。

2.3.2 结构化注释元素（«atpStructuredComment»）

AUTOSAR 支持 StructuredComment 以提供辅助信息以创建注释。

[TPS_GST_00381] «atpStructuredComment» — 标记为 «atpStructuredComment» 的元素包含在模型中没有语义的信息，可以在模型级别上忽略。 c()

[TPS_GST_00382] «atpStructuredComment» 和 «atpSplitable» 的交互 — 根据可拆分元素合并多个物理文件时，可以忽略所有标记为 «atpStructuredComment» 的元素以及所有子元素。 c()

列表 2.1 说明了通过提供有关生成工具及其版本的信息来使用 «atpStructuredComment»。

示例：ARXML 文件中的文件信息注释

<AUTOSAR xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="http://autosar.org/schema/r4.0"
     xsi:schemaLocation="http://autosar.org/schema/r4.0 AUTOSAR_00044.xsd">
  <FILE-INFO-COMMENT>
    <SDGS>
      <SDG GID="GENERATION-INFO">
        <SD GID="TOOL-VERSION">ToolA.1.2.3</SD>
        ...
      </SDG>
    </SDGS>
  </FILE-INFO-COMMENT>
  <ADMIN-DATA>
    ...
  </ADMIN-DATA>
  ...
</AUTOSAR>

类表 2.1：FileInfoComment

字段 值
Class FileInfoComment
Package M2::AUTOSARTemplates::AutosarTopLevelStructure
Note 此类支持 StructuredComment 以提供辅助信息以创建注释
Base ARObject
Attribute sdg 类型：Sdg，多重性：*，种类：aggr
此属性允许保留标准模型未表示的特殊数据。它可用于保留例如工具特定数据。

2.4 UML 标签 (UML Tags)

AUTOSAR 模板配置文件使用以下 UML 标签。请注意，此处仅提及直接影响元模型语义内容的标签。

[TPS_GST_00364] UML 标签附着在关系的目标端（如适用） — 除非用特定 UML 标签另外指定，否则 UML 标签附着在关系（关联、聚合）的目标端。对于 Dependency 和 Generalization，UML 标签与连接器本身相关联（以克服 AUTOSAR 中使用的 UML 工具 (EA) 的限制）。 c()

  • [TPS_GST_00049] atp.recommendedPackage — 此标签为给定元类的对象提供推荐的包名。从而为 {kind} 提供一个值。通常它是标签附加到的元类的名称。请注意：

    • 此标签会传播到子类
    • 此标签仅适用于 PackageableElement 的子类。 c()

    {kind} 的值在第 3.1 章中描述。

  • [TPS_GST_00385] atp.ManifestKind — 此标签提供此类被分配到的清单名称的逗号分隔列表。 c()

  • [TPS_GST_00050] atp.Splitkey — 这指定了 «atpSplitable» 关系的标识键。该标签指定一个以逗号分隔的 OCL 表达式列表。这些表达式可以成为构建标识字符串的基础。

    例如，如果在 PhysicalChannel.iSignalTriggering 中 atp.Splitkey 设置为 "shortName, variationPoint.shortLabel"，则可以生成以下 OCL 代码：

    context: PhysicalChannel
def: iSignalTriggering_atpSplitkey : String =
     self.iSignalTriggering.shortName.concat(',')
     .concat(self.iSignalTriggering.variationPoint.shortLabel)

    c()

    有关更多详细信息，请参阅第 8 章。

[TPS_GST_00297] 表示生命周期信息的标签 — AUTOSAR 通过名称为 atp.Status* 和 map.Status 的标签表示 M1 模型中实体的生命周期状态。 c()

  • [TPS_GST_00051] atp.Status — 此标签允许指定元模型实体相对于其生命周期的当前状态。它适用于类、聚合、关联和属性。支持以下值：

    • valid — 表示相关实体是文档的有效部分。
    • draft — 表示相关实体是新引入到元模型中但仍处于实验阶段。此信息已发布，但可能会在没有向后兼容性管理的情况下发生更改。
    • obsolete — 表示相关实体已过时，并保留在元模型中以实现兼容性。如果设置了此标签，则注释应表示推荐的替代解决方案。
    • preliminary — 表示相关实体在元模型中是初步的。它可能会在没有向后兼容性管理的情况下发生更改。AUTOSAR 版本不包含此类元素。它用于 AUTOSAR 内部开发。
    • removed — 表示相关实体仍保留在元模型中（无论出于何种原因，例如在 lifeCycles 上下文中）。它不应被使用，甚至不应出现在文档中。AUTOSAR 版本不包含此类元素。它用于 AUTOSAR 内部开发。在 M1 用例中，此类已删除的元素不包括在 .arxml 交付中，但可以通过使用 «atpUriDef» 类型的 Referrable 属性在 LifeCycleInfoSet 中引用：lcObject 或 useInstead。
    • shallBecomeMandatory — 表示相关实体从语义角度应该是强制的，并将在将来成为强制性的。它仍然是可选的，以避免向后兼容性问题。可能时应提供此类元素。

    类和聚合/引用中状态值的允许组合如表 2.2 和 2.3 所示。如果未指定标签，则相关实体是当前元模型的有效部分。该标签应应用于关联的目标端。 c()

    该标签可以应用于关联（如果打算在图中的注释中显示）。

    请注意，[TPS_GST_00051] 侧重于 M2 实体（元模型），而 [TPS_STDT_00064] 对 M1 实体（模型）表达相同的意思。

    请注意，列表 12.1 提供了这些值作为 AUTOSAR arxml 文件。

  • [TPS_GST_00413] atp.Status 的默认值 — 元类的 atp.Status 的默认值为 'valid'，关联从源继承值，聚合和属性从父级继承值。 c()

  • [TPS_GST_00295] atp.StatusRevisionBegin — 此标签表示从哪个 AUTOSAR 版本开始，atp.Status 中表示的状态是可行的。这对应于 [TPS_GST_00244] 中指定的 periodBegin。 c()

  • [TPS_GST_00296] atp.StatusRevisionEnd — 此标签表示从哪个 AUTOSAR 版本开始，atp.Status 中表示的状态是可行的。这对应于 [TPS_GST_00244] 中指定的 periodEnd。 c()

  • [TPS_GST_00274] atp.StatusComment — 这表示根据 [TPS_GST_00051] 的当前状态的简短注释。它主要应用于 "valid" 以外的状态值。 c()

  • [TPS_GST_00362] map.Status — 此标签允许为上游映射定义生命周期。此标记值的值与 atp.status [TPS_GST_00051] 的值相关联。 c()

表 2.2：状态值组合的允许矩阵（聚合/引用/属性）

类状态 (parent/source) \ 聚合/引用/属性状态 draft valid obsolete preliminary removed shallBecomeMandatory
draft 1 0 1 1 1 0
valid 1 1 1 1 1 1
obsolete 0 0 1 0 1 0
preliminary 1 0 1 1 1 0
removed 0 0 0 0 1 0
shallBecomeMandatory 1 0 1 1 1 1

"1" 表示允许组合，"0" 表示不允许组合。该表表示直接子级，不含继承子级。

表 2.3：状态值组合的允许矩阵（类）

聚合/引用/属性状态 \ 类状态 (child/target) draft valid obsolete preliminary removed shallBecomeMandatory
draft 1 1 0 1 0 1
valid 0 1 0 0 0 0
obsolete 1 1 1 1 0 1
preliminary 1 1 0 1 0 1
removed 1 1 1 1 1 1
shallBecomeMandatory 0 1 0 0 0 1

图 2.3 和 2.4：状态值组合的范围，包括有效和无效组合的图示。

  • [TPS_GST_00370] atp.EnumerationValue — 此标签允许定义 EnumerationValue。它们在一个标记为 "enumeration" 的元类的上下文中不应相互重叠。 c()

  • [TPS_GST_00371] 控制规范文档生成的标签 — 名称为 mmt.* 的 UML 标签控制规范文档的生成。 c()

    • [TPS_GST_00372] mmt.RestrictToStandards — 此标签的使用控制模型元素在生成的构件中相对于所述标准的外观。如果 mmt.RestrictToStandards 应用于模型元素，则此模型元素应仅出现在由 mmt.RestrictToStandards 的值标识的标准的生成构件中。mmt.RestrictToStandards 的值可以包含以下一个或多个值的逗号分隔列表："CP"、"AP"、"FO"、"TC"、"TA"。逗号后面可以跟空格。 c()

    自适应平台和经典平台的元模型在公共模型中维护。这允许重用现有的元类。某些元类将具有对相应标准互斥的属性、聚合或引用，即与经典平台相关的属性应仅出现在经典平台的生成构件中，反之亦然。

    • [TPS_GST_00353] mmt.templateTable — 此标签用于将模板与给定的变体点相关联。该值是由空格分隔的模板列表，按 [TR_PDN_00003] 规定的名称表示。特别是它是由 DocumentAbbreviations 集合中分类为 DocumentAbbreviation 的关键字定义的 abbrName，在 [7] 中指定（例如 SWCT）。mmt.templateTable 标签应用于对元模型有贡献的对象的任何包。mmt.templateTable 传递地应用于定义它的包的所有子包。尽管如此，子包可以覆盖在祖先包上由 mmt.templateTable 提供的值。 c()

  • [TPS_GST_00298] 表示变体处理属性的标签 — 名称为 vh.* 的 UML 标签与变体处理相关。 c()

    • [TPS_GST_00052] vh.latestBindingTime — 此标签控制变体处理的绑定时间。 c() 有关更多详细信息，请参阅第 7.6 [TPS_GST_00182]。

  • [TPS_GST_00291] 用于配置 XML 模式生成的 UML 标签 — 名称为 xml.* 的 UML 标签与 AUTOSAR 模型的 XML 序列化相关。它们基本上不影响 M1 模型的语义，但确保可以通过元模型控制 XML 序列化。它们还提供了调整模式的手段，以便在元模型演变时确保模式的向后兼容性。有关如何应用这些标签以及这些标签的影响的更多详细信息，请参阅 [3] 中的第 4 章"配置 XML 模式生成"。 c()

    • [TPS_GST_00053] xml.xsd.* 等 — 这些标签允许通过使用 XSD 限制来定义原始类型的详细信息。即使通过技术特定的定义指定，它也独立于存储技术应用于元模型。 c()

    • [TPS_GST_00054] xml.xsd.customType — 此标签适用于一个 «primitive»。它指定表示原始类型的 xsd:simpleType 的名称。 c()

    • [TPS_GST_00055] xml.attribute — 确定 UML 属性是否序列化为 XML 属性。此标签允许控制 XML 序列化，与 M1 模型的语义无关。 c()

    • [TPS_GST_00056] xml.attributeRef — 确定 UML 属性是否序列化为对全局 XML 属性的引用。如果设置为 true，则将该属性序列化为对全局属性的引用。仅当 xml.attribute 设置为 true 时适用。引用的属性名称在 xml.name 中指定。引用属性的命名空间前缀在 xml.nsPrefix 中指定。 c()

    • [TPS_GST_00057] xml.enforceMinMultiplicity — 如果为 true，则强制执行最小多重性；否则为 "0"。为了允许传输部分信息，最小多重性在标准化模式中默认不强制执行。 c()

    • [TPS_GST_00058] xml.enforceMaxMultiplicity — 如果为 true，则强制执行最大多重性；否则为 "unbounded"。默认情况下，xml.enforceMaxMultiplicity 为 true。 c()

    • [TPS_GST_00059] xml.globalElement — 如果为 true，则为标记的类创建全局 xsd:element。此 xsd:element 可用作模式实例的根元素。此标签需要在 AUTOSAR 元模型中明确定义。通常只有元类 AUTOSAR 由全局定义的 XML 元素表示。 c()

    • [TPS_GST_00060] xml.mds.type — 确定原始类型的数据类型（如果这是由元模型工具生成的原始类型）。这种生成类型的主要示例由 REFERRABLE-SUBTYPES-ENUM 给出。此标签应应用于一个 «primitive»，然后该原始类型充当 xml.mds.type 中表示的类型的代理。 c()

    • [TPS_GST_00061] xml.name — 提供表示角色或类的模式片段（元素、属性、组等）的名称。如果未在 AUTOSAR 元模型中明确定义，则按 [3] 中所述计算此值。 c()

    • [TPS_GST_00062] xml.nsPrefix — 此标签可应用于：

      • 属性：确定 xml.attributeRef 设置为 true 的属性的命名空间前缀
      • 包：确定用于基于此包的模式的命名空间前缀。 c()

    • [TPS_GST_00063] xml.nsUri — 确定用于基于此包的模式的命名空间 URI。命名空间 URI 的格式在 [3] 中定义。如果未在 AUTOSAR 元模型中明确定义，则按 [3] 中所述隐式指定此值。 c()

    • [TPS_GST_00064] xml.roleElement、xml.roleWrapperElement、xml.typeElement、xml.typeWrapperElement — 这些标签允许控制 XML 序列化，特别是 XML 元素的创建，与 M1 模型的语义无关。有关更多详细信息，请参阅 [3]。 c()

    • [TPS_GST_00065] xml.sequenceOffset — 确定属性在 XML 中序列化的顺序。如果此标签缺失，则按字母顺序序列化属性⁶。此顺序与 XML 工件的更轻松维护相关，但与 M1 模型的语义无关。 c()

    • [TPS_GST_00066] xml.systemIdentifier — 确定应用于此模式的实例中应使用的系统标识符。如果未在 AUTOSAR 元模型中明确定义，则按 [3] 中所述隐式指定此值。 c()

⁶ 如果顺序相关，则在模型中将其表示为多重性的 {ordered}。

  • [TPS_GST_00292] 行政管理 UML 标签 — 对于元模型的文档管理，名称模式为 admin.* 的 UML 标签应用于特定包（例如 M2::AUTOSAR Templates::ReadMe）。如果此包在元模型工具的配置文件中被引用，则这些值将转发到生成的构件（例如 MMOD_XMLSchema 或 MOD_ECUConfigurationParameters）。除了 UML 标签外，生成构件的免责声明也取自此包的包注释。 c()

    适用以下 UML 标签：

    • [TPS_GST_00067] admin.documentClassification — 表示元模型的分类（标准或辅助）。 c()

    • [TPS_GST_00068] admin.documentIdentificationNo — 这表示 AUTOSAR 文档编号。 c()

    • [TPS_GST_00069] admin.documentOwner — 这表示元模型的维护者。 c()

    • [TPS_GST_00070] admin.documentResponsibility — 这表示元模型的责任机构。 c()

    • [TPS_GST_00071] admin.documentStatus — 这表示元模型的状态。 c()

    • [TPS_GST_00072] admin.documentTitle — 这表示分配给元模型的标题。 c()

    • [TPS_GST_00073] admin.documentVersion — 这表示元模型的官方版本。请注意，文档版本与 admin.partOfRelease 无关，因此像 3.1.12 这样的版本号不一定引用 AUTOSAR 的 R3.1 分支。 c()

    • [TPS_GST_00074] admin.partOfRelease — 这表示发布元模型的 AUTOSAR 版本。请注意，此标签是必需的，因为工具正在使用它来控制各种生成器的详细信息：

      • 在 4.0 以下的 AUTOSAR 版本中插入硬编码的 xsd:simpleType，名为 REF
      • 根据原始类型的实现处理原始类型
      • AUTOSAR 版本之间构件（例如 classtables）的结构差异。 c()

      有关原始类型实现的详细信息在第 6.3.1 章中描述。

    • [TPS_GST_00075] admin.releaseDate — 这表示发布元模型的 AUTOSAR 版本的日期。 c()

    • [TPS_GST_00076] admin.revision — 表示发布元模型的 AUTOSAR 版本的特定修订版本。 c()

  • [TPS_GST_00299] 指定上游映射的标签 — 名称为 map.{template}.* 的 UML 标签与上游映射的描述相关。上游映射描述在方法学（也称为下游）中后创建的构件中的实体（M1 或 M2）是否以及如何与先创建的实体（也称为上游）相关。 c()

    • [TPS_GST_00301] 上游映射规范标签中的占位符 {template} — 这表示适用的上游模板，其中映射将被列出。这些名称遵循 [TR_PDN_00003]。特别是它是由 DocumentAbbreviations 集合中分类为 DocumentAbbreviation 的关键字定义的 abbrName，在 [7] 中指定（例如 SWCT）。 c()
    • [TPS_GST_00300] map.{template}.desc — 这提供映射实体的描述。 c()
    • [TPS_GST_00302] map.{template}.m2element — 这表示对 M2 实体的引用，例如 SystemSignal.length。 c()
    • [TPS_GST_00303] map.{template}.rule — 这给出了如何转换数据的文本描述，例如 1:1 映射。 c()
    • [TPS_GST_00304] map.{template}.type — 这表示映射质量。适用以下值：
      • local：无需映射，因为参数是 BSW 的本地参数
      • partial：一些数据可以自动映射，但不是全部
      • full：所有数据都可以自动映射。 c()

  • [TPS_GST_00363] map.Id — 此标签允许唯一标识给定的上游映射以进行跟踪。 c()

3 AUTOSAR 顶层结构 (Autosar Top Level Structure)

AUTOSAR 对所有 AUTOSAR 模板使用通用的顶层结构。这种方法为在 AUTOSAR 方法论中设计工件保留了最大的灵活性。图 3.1 说明了 AUTOSAR 顶层结构。

图 3.1：AUTOSAR 模板的顶层结构

主要元素：

  • AUTOSAR — 根元素

    • +arPackage: ARPackage [0..*]（«atpSplitable, atpVariation»）
    • +adminData: AdminData [0..1]
    • +introduction: DocumentationBlock [0..1]（«atpMixed»）
    • +fileInfoComment: FileInfoComment [0..1]（«atpStructuredComment»）

  • ARPackage — 包容器

    • 继承自：AtpBlueprint、AtpBlueprintable、CollectableElement、Identifiable
    • +element: PackageableElement [0..*]（«atpSplitable, atpVariation»）

  • AdminData — 管理数据

    • +language: LEnum [0..1]
    • +sdg: Sdg [*]

  • FileInfoComment — 文件信息注释（«atpStructuredComment»）

  • ARObject — 所有类的隐式基类（«atpObject»）

    • +checksum: String [0..1]
    • +timestamp: DateTime [0..1]

  • PackageableElement — 可打包元素

    • 继承自：CollectableElement、Identifiable
    • +ARElement、+FibexElement 等

  • AtpType / AutosarDataType — 类型基类

  • Unit — 单位

    • +factorSiToUnit: Float [0..1]
    • +offsetSiToUnit: Float [0..1]

[TPS_GST_00077] AUTOSAR 模型的顶层结构 — 元类 AUTOSAR 是所有模板的根。AUTOSAR 包含多个 ARPackage 作为 arPackage。 c()

ARPackage 可以任意嵌套。这些包包含表示 AUTOSAR 模板的特定自治实体的 PackageableElement。其中最突出的专门化是 ARElement（见第 4.2 章）。

请注意，所有¹ AUTOSAR 元类都从 ARObject 继承（见第 4.1 章）。

[TPS_GST_00078] AUTOSAR 顶层 AdminData — 顶层结构还包含 AdminData，它指定 AUTOSAR 工件的两个主要方面：

  • 文档中指定的变更管理信息为 DocRevision
  • 文档的语言状态。 c()

有关更多详细信息，请参阅第 4.4 章。

[TPS_GST_00079] 工件的语言状态 — 工件的语言状态指定：

  1. 文档的"主"语言，在顶层 AdminData 的属性 language 中指定。
  2. 文档中使用的其他语言。这被指定为 usedLanguages，它是一个 MultiLanguagePlainText，用作文档中使用的语言的列表。 c()

有关多语言方法的更多详细信息，请参阅第 9.6 章。以下示例说明了 ARXML 文件的顶层结构。该文件以英语和德语维护。英语是主语言。

列表 3.1：ARXML 文件的顶层结构

<?xml version="1.0" encoding="UTF-8"?>
<AUTOSAR xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="http://autosar.org/schema/r4.0"
      xsi:schemaLocation="http://autosar.org/schema/r4.0 AUTOSAR_4-1-3.xsd"
         >
  <ADMIN-DATA>
    <LANGUAGE>EN</LANGUAGE>
    <USED-LANGUAGES>
      <L-10 L="EN" xml:space="default">English</L-10>
      <L-10 L="DE" xml:space="default">German</L-10>
    </USED-LANGUAGES>
  </ADMIN-DATA>
  <AR-PACKAGES>
    <AR-PACKAGE>
      <SHORT-NAME>demo</SHORT-NAME>
      <ELEMENTS>
        <!--
           autosar elements here
        -->
      </ELEMENTS>
    </AR-PACKAGE>
  </AR-PACKAGES>
</AUTOSAR>

类表 3.1：AUTOSAR

字段 值
Class AUTOSAR
Package M2::AUTOSARTemplates::AutosarTopLevelStructure
Note AUTOSAR 描述的根元素，也是相应 XML 文档中的根元素。Tags: xml.globalElement=true
Base ARObject
Attribute adminData 类型：AdminData，多重性：0..1，种类：aggr
这表示 Autosar 文件的管理数据。Tags: xml.sequenceOffset=10
Attribute arPackage 类型：ARPackage，多重性：*，种类：aggr
这是 AUTOSAR 模型中的顶级包。Stereotypes: atpSplitable; atpVariation
Tags: atp.Splitkey=shortName, variationPoint.shortLabel, vh.latestBindingTime=blueprintDerivationTime, xml.sequenceOffset=30
Attribute fileInfoComment 类型：FileInfoComment，多重性：0..1，种类：aggr
这表示在 AUTOSAR 文件中提供结构化注释的可能性。Stereotypes: atpStructuredComment
Tags: xml.roleElement=true, xml.sequenceOffset=-10, xml.typeElement=false
Attribute introduction 类型：DocumentationBlock，多重性：0..1，种类：aggr
这表示 Autosar 文件的介绍。它旨在例如表示免责声明和法律注释。Tags: xml.sequenceOffset=20

AUTOSAR 工件组织在 ARPackage 中，其中包含所谓的 PackageableElement 元素。这些元素根据其自身性质定义，它们彼此独立存在，并通过关联使用。例如，computation method 是单独定义的。它通过引用被数据定义使用。有关 ARPackage 的更多详细信息，请参阅第 4.2 章。

3.1 在包中标识 M1 元素 (Identifying M1 elements in packages)

包用于组织 AUTOSAR M1 模型。AUTOSAR Gbr 本身发布 M1 模型作为已发布标准的一部分。为了清楚地标识这些模型元素，适用以下规则：

  • [TPS_GST_00080] AUTOSAR 交付模型的包结构 — 由 AUTOSAR 标准化并以 ARXML 形式交付的模型元素位于其 shortName 为 AUTOSAR 的顶级包中。这意味着由 OEM 或供应商定义的数据元素不应位于名为 AUTOSAR 的顶级包中。 c()

  • [TPS_GST_00081] AUTOSAR 交付模型的模式 — AUTOSAR 交付模型的包结构遵循以下模式：

    /AUTOSAR
    /{module}                                      -- identify the spec
        /{kind}s[_Blueprint | _Example]            -- identify the kind
                                                   --          of object

    c()

    请注意，AUTOSAR 通常交付蓝图 (Blueprints)。有关更多详细信息，请参阅 [TPS_STDT_00067]。

    一个示例结构是：

    /AUTOSAR
    /ComM
       /ApplicationDataTypes_Blueprint          [BLUEPRINT]
       /BswModuleEntrys_Blueprint               [BLUEPRINT]
       /CompuMethods_Blueprint                  [BLUEPRINT]
       /DataConstrs_Blueprint                   [BLUEPRINT]
       /DataTypeMappingSets_Blueprint           [BLUEPRINT]
       /Documentations                          [STANDARD]
       /ImplementationDataTypes_Blueprint       [BLUEPRINT]
       /ImplementationDataTypes                 [STANDARD]
       /ModeDeclarationGroups_Blueprint         [BLUEPRINT]
       /SwcBswMappings_Blueprint                [BLUEPRINT]
       /SwComponentTypes_Blueprint              [BLUEPRINT]
       /BswModuleDescriptions_Blueprint         [BLUEPRINT]

    在此示例中，有一个用于实现数据类型的蓝图包，以及最终作为 STANDARD 实现的实现数据类型。

    另一个示例是：

    /AUTOSAR
    /AISpecification
       /DataConstrs                             [STANDARD]
       /PhysicalDimensions                      [STANDARD]
       /Units                                   [STANDARD]
       /ApplicationDataTypes_Blueprint          [BLUEPRINT]
       /CompuMethods_Blueprint                  [BLUEPRINT]
       /PortInterfaces_Blueprint                [BLUEPRINT]
       /PortPrototypeBlueprints_Blueprint       [BLUEPRINT]
       /ApplicationDataTypes_Example            [EXAMPLE]
       /BlueprintMappingSets_Example            [EXAMPLE]
       /CompuMethods_Example                    [EXAMPLE]
       /PortInterfaces_Example                  [EXAMPLE]
       /SwComponentTypes_Example                [EXAMPLE]

    此示例显示了提供 STANDARD、BLUEPRINT 和 EXAMPLE 的用例。

  • [TPS_GST_00082] ECUC 参数定义的包结构 — 请注意，出于兼容性原因，ECUC 包结构在 AUTOSAR 4.0 中保持为：

    /AUTOSAR
      /EcucDefs

    c()

  • [TPS_GST_00083] AUTOSAR 定义模型元素的模式 — AUTOSAR 规范已为其定义标准化名称（如平台类型）的模型元素应位于根据以下模式的包路径中：

    /AUTOSAR_{module}[_{postfix}]/{kind}s

    c()

在这些给定的模式中，适用以下占位符：

  • [TPS_GST_00017] {module} 表示模块指示符 — 模块指示符是以下之一：

    • 模块、库等（根据 [8] 的 API 服务前缀，例如 CanIf、Ifx、Compiler）
    • 由 VirtualModules 集合中分类为 ModuleDesignator 的关键字定义的 abbrName，在 [7] 中指定（例如 AISpecification）。 c()

  • [TPS_GST_00084] {postfix} 表示特定实现 — 当且仅当 BSW 模块的多个实现出现在同一系统中时，才会向包结构添加后缀。 c()

  • [TPS_GST_00085] {kind} 表示元素的种类 — 该值是 ARElement 的子类的名称，并附加复数 "s"。特定包名称使用 UML 标签 atp.recommendedPackage 为每个 ARElement 指定（请参阅 [TPS_GST_00049]），并在类表中如此显示（例如从 BswModuleDescription 派生的 BswModuleDescriptions）。 c()

[TPS_GST_00086] ARPackage 的类别 — ARPackage 的属性 category 的值可以视为有关 ARPackage 内容性质的指示。category 属性的某些值由 AUTOSAR 标准化：STANDARD、BLUEPRINT、EXAMPLE、ICS。有关 category 属性的自定义值的定义，适用 [TPS_GST_00016]。 c()

  • [TPS_GST_00087] BLUEPRINT — 这种包中的元素充当真实对象的"蓝图"。这特别适用于 PortInterface 等对象，这些对象没有明确建模为"蓝图"，但仍然是 AtpBlueprint 或 AtpBlueprintable 的专门化。 c()

    例如，创作工具提供此类预定义的 PortInterface 作为一种工具箱，定义可从该工具箱复制到实际项目中。这种包中的模型元素可能仅部分定义。因此可能适用特定的语义约束。有关更多详细信息，请参阅 [2] 中的 [TPS_STDT_00002]。

    [constr_2501] 蓝图的蓝图不受支持 — 请注意，明确建模为"蓝图"的对象（例如 PortPrototypeBlueprint）也位于 BLUEPRINT 类别的包中。严格来说，这意味着它们可以是"蓝图"的"蓝图"。这种间接不打算也不受支持。 c()

  • [TPS_GST_00088] STANDARD — 由相关顶级包的提交者标准化并可直接用于处理的元素（例如 ECU 参数定义）。 c() 请注意，这也允许表示利益相关者特定的标准元素，因为 STANDARD 不限于 AUTOSAR 内部应用。

  • [TPS_GST_00196] ICS — 形成实现一致性声明 (Implementation Conformance Statement) 的元素。 c()

    [constr_4055] ICS 不能包含蓝图 — 由于实现一致性声明始终描述一个或多个完全配置的软件的模块，因此类别为 ICS 的包不允许在任何级别包含具有类别 BLUEPRINT 的子包。 c()

    [constr_2573] ICS 不应引用示例 — ICS 类似于生产模型，因此不应引用 EXAMPLE。此类引用是无用的，因为目标需要在 ICS 中忽略。 c()

  • [TPS_GST_00089] EXAMPLE — EXAMPLE 包中的元素说明了如何应用例如在 STANDARD 或 BLUEPRINT 包中定义的元素。EXAMPLE 包中的元素应被生成器等忽略。 c()

[TPS_GST_00090] ARPackage 的非标准化类别 — 不属于这些类别之一的模型元素应位于利益相关者之间商定的类别的包中。在这种情况下，也可以根本没有类别。 c()

[constr_2515] 包的类别不应冲突 — 如果为包定义了非空类别，则所有子包应具有空类别或相同的类别。请参阅表 3.2。此外，"具有特定类别的包中元素之间引用的规则"应适用。请参阅表 3.3。 c()

表 3.2：子包类别的规则

父类别 \ 子类别 empty BLUEPRINT STANDARD EXAMPLE ICS custom1 custom2
empty ok ok ok ok ok ok ok
BLUEPRINT ok ok conflict conflict conflict conflict conflict
STANDARD ok conflict ok conflict conflict conflict conflict
EXAMPLE ok conflict conflict ok conflict conflict conflict
ICS ok conflict conflict conflict ok conflict conflict
custom1 ok conflict conflict conflict conflict ok conflict
custom2 ok conflict conflict conflict conflict conflict ok

表 3.3：具有特定类别的包中元素之间引用的规则

源 \ 目标 empty BLUEPRINT STANDARD EXAMPLE ICS custom1 custom2
empty ok ok ok ok ok ok ok
BLUEPRINT ok ok ok conflict ok conflict conflict
STANDARD ok conflict ok conflict conflict conflict conflict
EXAMPLE ok ok ok ok ok conflict conflict
ICS ok conflict ok conflict² ok conflict conflict
custom1 ok ok ok ok ok ok ok
custom2 ok ok ok ok ok ok ok

² 有关详细信息，请参阅 [constr_2573]。

可以从蓝图维护对从该蓝图派生的"实际"对象的引用。元类 BlueprintMappingSet 可用于此。可能适用特定的兼容性规则，并在适当的模板中定义。有关更多详细信息，请参阅 [2]。

类表 3.4：BlueprintMappingSet

字段 值
Class BlueprintMappingSet
Package M2::AUTOSARTemplates::StandardizationTemplate::BlueprintMapping
Note 这表示"实际"模型元素与用于创建它们的"蓝图"之间的映射的容器。Tags: atp.recommendedPackage=BlueprintMappingSets
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, PackageableElement, Referrable
Attribute blueprintMap 类型：AtpBlueprintMapping，多重性：*，种类：aggr
这表示集合中的特定蓝图映射。

3.2 ARPackage、ARElement 和 Identifiable 等的角色

AUTOSAR 元模型使用一些抽象类来表示关于模型组织的各种能力。图 3.2 中提供了其概要。

图 3.2：模型组织类的概要

主要抽象类层次结构：

Referrable (abstract)
├── +shortName: Identifier
├── SingleLanguageReferrable
│   └── +longName1: SingleLanguageLongName [0..1]
├── MultilanguageReferrable
│   └── +longName: MultilanguageLongName [0..1]
├── Identifiable
│   ├── +category: CategoryString [0..1]
│   ├── +uuid: String [0..1]
│   ├── CollectableElement
│   ├── AtpBlueprint / AtpBlueprintable
│   │   ├── ARPackage
│   │   │   ├── +arPackage: ARPackage [0..*]
│   │   │   └── +element: PackageableElement [0..*]  «atpSplitable,atpVariation»
│   │   └── PackageableElement (abstract)
│   │       ├── ARElement
│   │       │   └── AtpType → AutosarDataType
│   │       └── FibexElement
│   └── Describable
│       ├── +introduction: DocumentationBlock [0..1]  «atpMixed»
│       └── +category: CategoryString [0..1]
└── MixedContentForLongName
    └── «atpMixedString» LongName

关于 Referrable 的说明：

  • Referrable 是一个抽象元类，它具有充当引用目标的 shortName。Referrable 主要用于引用目标占用空间较小的情况，例如 Sdg。Referrable 专门化为 SingleLanguageReferrable/MultilanguageReferrable。
  • SingleLanguageReferrable 的专门化适用于作为多语言对象一部分的文本中嵌入的元素（所谓的内联元素，如第 9.2.8 章所述）。
  • MultilanguageReferrable 的专门化适用于应具有相对较小占用空间的多语言对象，例如 DefList、Traceable。

关于 Describable 的说明：

  • Describable 是一个抽象元类，它表示提供描述的能力，但不是 Referrable 或 Identifiable。此处提及它是为了完整性。

关于 Identifiable 的说明：

  • Identifiable 是一个抽象类，它继承自 MultilanguageReferrable。这用于标识 AUTOSAR 模型中的基本对象。与 Referrable 相关，它提供了进一步的方法来标识元素，例如 desc。显然，可以标识的任何内容也应该是可引用的。因此，Identifiable 是 Referrable 的专门化。

  • 嵌套的 Identifiable 建立了一个层次命名空间。

    请注意，如果 Referrable 包含进一步的 Referrable，它将不是层次命名空间，因为命名空间仅由 Identifiable 建立³。

    请参阅第 4.3.1 章了解更多详细信息。

  • AUTOSAR 中的 arPackage 是 AUTOSAR 模型中最顶层的 Identifiable。这个顶级 ARPackage 是命名空间层次结构的根。

  • Identifiable（更准确地说，Referrable）的 shortName 在包含的 Identifiable 中必须（不区分大小写）唯一。示例包括：

    • ARElement（例如 ApplicationSwComponentType）的 shortName 必须在 ARPackage（即 Identifiable）内唯一。但不同的 ARPackage 中可能存在具有相同 shortName 的其他 ApplicationSwComponentType。
    • PortPrototype 的 shortName 必须在 ApplicationSwComponentType（即 Identifiable）内唯一。但其他 ApplicationSwComponentType 中可能存在具有相同名称的 PortPrototype。

关于 CollectableElement 的说明：

  • CollectableElement 表示成为集合一部分（特别是被集合引用）的能力。此元类不引入其他属性或其他可能的聚合。
  • 即使 CollectableElement 与 ARElement 类似，它也不相同，因为它处理完全不同的方面。

关于 ARPackage 的说明：

  • ARPackage 可以嵌套：ARPackage 可以以 arPackage 角色包含 ARPackage。
  • 因此 ARPackage 由嵌套的分支（ARPackage）和叶子（PackageableElement 的子类，特别是 ArElement 的子类）组成。
  • ARPackage 是 Identifiable 的专门化。否则它不会对命名空间层次结构做出贡献。
  • PackageableElement 是一个抽象类，表示对象可以独立定义的能力。这些对象不需要上下文。此类对象有时称为"一等公民"。
  • PackageableElement（ARElement、FibexElement）不能包含进一步的 PackageableElement（ARElement 或 FibexElement）。

关于 ARElement 和 FibexElement 的说明：

  • ARElement 是一个抽象类，对一般的 AUTOSAR 模型有贡献。
  • FibexElement 是一个抽象类，表示元素特别有助于系统的通信和拓扑描述的能力。
  • ARElement 和 FibexElement 是 Identifiable。因此派生的元素也具有 shortName。
  • ARElement、FibexElement 可能包含从 Identifiable 派生的其他元素。

³ 尽管如此，这种 Referrable 的嵌套不会出现在 AUTOSAR 元模型中。

4 通用模板类 (General Template Classes)

下面给出的通用模板类的性质类似于编译器的标准库：一组预定义的结构和元素，可在 AUTOSAR 模板模型中使用。

4.1 ARObject - 所有类的公共属性

[TPS_GST_00091] ARObject — ARObject 是所有其他元类继承的元类。 c()

相关模式如图 6.9 所示。

类表 4.1：ARObject（抽象）

字段 值
Class ARObject (abstract)
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::ArObject
Note 元模型中所有类的隐式基类。
Base —
Subclasses –所有具体元类–
Attribute checksum 类型：String，多重性：0..1，种类：attr
Attribute timestamp 类型：DateTime，多重性：0..1，种类：attr

4.2 AUTOSAR 中的包 (Packages in Autosar)

包用于组织 AUTOSAR M1 模型。如前所述，AUTOSAR Gbr 本身发布 M1 模型作为已发布标准的一部分。在本节中，详细说明了 ARPackage 的角色和功能。

ARPackage 类：

  • 继承自 Identifiable
  • 可以包含其他 ARPackage 和 PackageableElement
  • 携带 category 属性（BLUEPRINT、STANDARD、EXAMPLE、ICS）

PackageableElement：表示可以独立打包的元素的抽象基类。

4.3 Identifiable 与 Referrable

Identifiable 和 Referrable 之间的关系是 AUTOSAR 元模型中标识和引用机制的基础。如第 3.2 章所述：

  • Referrable 是所有可引用对象的根
  • Identifiable 是 Referrable 的专门化，添加了 category 和 uuid 属性
  • 嵌套的 Identifiable 形成了层次命名空间

4.3.1 命名空间与 shortName 的唯一性

shortName 的唯一性规则在父 Identifiable（如 ARPackage）范围内强制执行。这确保了引用解析不会产生歧义。

4.4 管理数据 (Administrative Data)

AdminData 包含：

  • 文档的变更管理信息 (DocRevision)
  • 文档的语言状态 (language、usedLanguages)

DocRevision：

  • 包含 revisionLabel（如 "1.0.0"）
  • 包含 state（如 draft、reviewed、released）
  • 包含变更列表

4.5 特殊数据 - 扩展机制 (Special Data)

特殊数据机制允许在不修改标准元模型的情况下扩展 AUTOSAR 模型。

4.5.1 特殊数据 (Special Data)

SDG (Special Data Group) 和 SD (Special Data) 容器允许 OEM 和供应商添加工具特定或领域特定的数据。

SDG 类表（摘要）：

字段 值
Class SDG (Special Data Group)
Attribute gid 类型：Identifier，多重性：0..1 — 组的标识符
Attribute sd 类型：SD，多重性：* — 组内的单个数据元素
Attribute sdx 类型：SDX，多重性：0..1 — 复杂（XML 形式）数据
Attribute base 类型：SDG，多重性：0..1 — 通过继承引用父组的 SDG 内容

SD 类表（摘要）：

字段 值
Class SD (Special Data)
Attribute gid 类型：Identifier，多重性：0..1 — 短名称
Attribute value 类型：Value，多重性：0..1 — 文本内容

4.5.2 特殊数据定义 (Special Data Definitions)

SpecialDataDef 元素允许定义 SDG/SD 的模式（允许的 GID 集合）。

SpecialDataDef 类表（摘要）：

字段 值
Class SpecialDataDef
Attribute sdg 类型：Sdg，多重性：* — SDG 验证规则

SpecialDataGroupDef 类表（摘要）：

字段 值
Class SpecialDataGroupDef
Attribute `name** 类型：Identifier，多重性：1 — 短名称
Attribute `base** 类型：SpecialDataGroupDef，多重性：0..1 — 通过继承引用父 SDG 定义
Attribute `sd** 类型：SpecialDataDef，多重性：* — 包含的 SD 验证规则

SpecialDataSemantics 枚举：

  • URL — 内容是 URL
  • TEXT — 内容是自由文本
  • BOOLEAN — 布尔值
  • INTEGER — 整数
  • FLOAT — 浮点数
  • （等等）

4.6 模型限制类型 (Model Restriction Types)

AUTOSAR 提供了限制机制来约束标准元模型元素的使用：

4.6.1 简单原始值的限制 (Restriction of Simple Primitive Values)

  • Limit 类：定义一个值的上限或下限
  • IntervalType 枚举：OPEN、CLOSED、INFINITE

4.6.2 多重性的限制 (Restriction of Multiplicities)

MultiplicityRestriction 允许降低标准多重性。

4.6.3 变化使用的限制 (Restriction of use of Variation)

VariationRestriction 限制允许的变化类型。

4.7 原始类型 (Primitive Types)

AUTOSAR 标准提供了大量预定义的原始类型（primitives），如 uint8、sint16、float32 等。

SwBaseType 类表（摘要）：

字段 值
Class SwBaseType
Attribute `baseTypeSize** 类型：PositiveInteger，多重性：0..1 — 类型大小（位）
Attribute `baseTypeEncoding** 类型：BaseTypeEncodingString，多重性：0..1 — 编码（1C、2C、SPC、IEEE754 等）
Attribute `nativeDeclaration** 类型：String，多重性：0..1 — 原生声明
Attribute `name** 类型：Identifier，多重性：1 — 类型短名称

4.8 公式语言 (Formula Language)

AUTOSAR 提供了一个公式语言，用于在变体点中表达条件。

4.8.1 公式语言的应用 (Applying Formula Language)

公式语言在以下上下文中使用：

  • 变体点的条件
  • 常量值的计算
  • ECU 配置参数的计算

4.8.2 公式语言定义 (Formula Language Definition)

公式语言的语法与 ASAM General Expression Language (GXL) 对齐。

算术表达式中的运算符：

  • 一元：+、-
  • 二元：+、-、*、/、%、^
  • 比较：<、<=、>、>=、==、!=
  • 逻辑：&&、||、!

数学函数：sin、cos、tan、sqrt、pow、log、exp、min、max、abs、floor、ceil、round

结果数据类型：整数运算产生整数，浮点运算产生浮点；比较结果产生布尔值

4.9 AUTOSAR 模型查询语言 (ARMQL)

ARMQL（AUTOSAR Model Query Language）是一种类似 XPath 的查询语言，用于搜索和操作 AUTOSAR 模型元素。

4.9.1 应用 ARMQL (Applying ARMQL)

ARMQL 在以下上下文中使用：

  • 蓝图派生（Blueprint Derivation）
  • 变体求值
  • 条件引用

4.9.2 ARMQL 定义 (ARMQL Definition)

主要结构：

  • LET 块 — 变量定义
  • FOR 块 — 集合迭代
  • WHERE 块 — 条件过滤
  • 表达式 — 字面量、变量、函数调用

预定义函数：

  • count() — 计算集合中的元素数
  • exists() — 测试集合是否非空
  • value() — 获取属性的值
  • concat() — 字符串连接
  • substring() — 子字符串提取
  • match() — 模式匹配

4.10 工程对象 (EngineeringObject)

EngineeringObject 是 Identifiable 的一个专门化，它携带工程特定的元数据（与 AUTOSAR 标准数据不同）。

4.11 注释 (Annotations)

Annotation 元素允许向模型元素添加用户定义的注释。注释存储在 MultiLanguagePlainText 字段中。

4.12 多维时间 (MultiDimensionalTime)

MultiDimensionalTime 类允许定义多维度的时间值（例如年/月/日/小时/分钟/秒组合）。

4.13 TagWithOptionalValue

TagWithOptionalValue 类表示一个带有可选值的标签（用于在 SDG 上下文中存储键值对）。

5 抽象结构 (AbstractStructure)

抽象结构提供了一种可重用的结构层次机制。它通过定义抽象类和抽象关系来实现，这些关系可以由具体的子类来专门化。

5.1 可重用的结构层次 (Reusable Structural Hierarchies)

5.1.1 动机 (Motivation)

不同的 AUTOSAR 模板（例如 SW Component Template 和 System Template）共享许多通用结构。抽象结构机制允许定义一次、并在多个模板中重用。

5.1.2 类型、原型与结构元素 (Types, Prototypes and Structure elements)

核心抽象类：

  • AtpType — 抽象类型基类
  • AtpPrototype — 抽象原型基类（用于实例化）
  • AtpStructureElement — 抽象结构元素
  • AtpFeature — 抽象特征（统一的"特征"概念，包括 port、component、connector 等）
  • AtpClassifier — 抽象分类器

5.1.3 实例引用 (Instance Refs)

InstanceRef 类表（摘要）：

字段 值
Class InstanceRef
Attribute `targetRef** 类型：``AbstractTargetRef` 的具体子类，多重性：0..1 — 实例引用的目标
Attribute `contextElementRef** 类型：``ReferrableRef`，多重性：0..* — 上下文元素

目标引用类型：

  • ComponentInstanceRef — 组件实例引用
  • OperationInstanceRef — 操作实例引用
  • VariableInstanceRef — 变量实例引用
  • PortInstanceRef — 端口实例引用
  • （等等）

5.1.4 任意实例引用 (Any Instance Refs)

AnyInstanceRef 允许引用任何类型的实例。

5.1.4.1 应用于 ImplementationDataTypeElement 的 AnyInstanceRef

这种特定形式的实例引用允许引用 ImplementationDataTypeElement。

6 元建模模式与模型转换 (Metamodeling Patterns and Model Transformation)

本章描述了元模型中使用的模式以及通过模型转换实现这些模式的方式。

6.1 模式应用的表示法 (Notation for Pattern Application)

AUTOSAR 元模型使用了几种模式来构造元类：

  • «atpMixed» — 混合内容模式
  • «atpVariation» — 变体处理模式
  • «atpSplitable» — 可拆分模式
  • «atpObject» — ARObject 模式
  • «isOfType» — 类型关系模式
  • «instanceRef» — 实例引用模式

6.2 模式规范 (Pattern Specification)

每个模式都有明确的规则，定义它如何影响 M1 模型以及如何转换为 XML。

6.3 在元模型中应用的模型转换 (Model Transformations applied in the Meta-Model)

6.3.1 实现原始类型 (Implementing «primitive»s)

原始类型模式将标准 UML 原始类型包装在 SwBaseType 中以提供 AUTOSAR 特定的元数据。

6.3.2 实现关联为引用 (Implementing Associations as References)

关联通常实现为路径引用，而不是直接的强引用。引用路径由 ShortName 段组成。

6.3.2.1 绝对 ShortName 路径 (Absolute ShortName-path)

绝对路径从根包开始：/MyCompany/Project/Component/Port。

6.3.2.2 相对 ShortName 路径 (Relative ShortName-path)

相对路径从当前上下文开始：../OtherComponent/Port。

6.3.2.3 目标类型 (Destination Type)

引用的目标类型由关联的元模型类型定义确定。

6.3.3 «atpObject» ARObject (「atpObject」ARObject)

«atpObject» 模式使 ARObject（带有 checksum 和 timestamp）成为所有元类的隐式基类。

7 变体处理 (Variant Handling)

AUTOSAR 的变体处理机制允许在单个模型中表达多个产品变体。

7.1 介绍 (Introduction)

7.1.1 快速概览 (A Quick Overview)

变体处理的核心是变体点 (Variation Point)，它是一个模型元素，其内容可以根据条件而变化。

7.1.2 变体处理与方法论 (Variant Handling and Methodology)

变体处理与 AUTOSAR 方法论紧密集成。变体可以在构建时（pre-build）或后构建（post-build）解析。

7.1.3 变体处理在元模型中的实现方式

核心类：

  • VariationPoint — 变体点容器
  • ConditionByFormula — 通过公式表达的条件
  • BindingTime — 绑定时间

7.1.4 并非元模型中的每个元素都可能是变体

只有标记为 «atpVariation» 的元素可以包含变体点。

7.1.5 变体点是可选的，即使对于变体元素

变体点本身就是可选的（0..1 多重性）。

7.1.6 绑定时间 (Binding Times)

BindingTimeEnum 枚举：

  • SYSTEM_DESIGN_TIME — 系统设计时
  • CODE_GENERATION_TIME — 代码生成时
  • PRE_COMPILE_TIME — 预编译时
  • LINK_TIME — 链接时
  • POST_BUILD_TIME — 后构建时
  • （等等）

7.1.7 变体处理对 XML Schema 影响的注意事项

变体处理对生成的 XML Schema 有重大影响，因为变体点可能影响模式结构。

7.1.8 模式相互独立

变体处理的不同模式可以独立使用。

7.1.9 变体处理模式中多重性的注意事项

变体处理对多重性有影响，因为条件性元素在某些条件下可能不存在。

7.1.10 应用变体处理模式的注意事项

变体处理模式必须谨慎使用以避免模型不一致。

7.2 变化点的聚合模式 (Aggregation Pattern for Variation Points)

聚合模式允许在聚合关系中引入变体点。

7.3 变化点的关联模式 (Association Pattern for Variation Points)

关联模式允许在关联关系中引入变体点。

7.4 变化点的属性值模式 (Attribute Value Pattern for Variation Points)

属性值模式允许属性值根据条件变化。

7.5 变化点的属性集模式 (Property Set Pattern for Variation Points)

属性集模式允许根据条件启用或禁用整个属性集。

7.6 变化点 (VariationPoint)

VariationPoint 类表（摘要）：

字段 值
Class VariationPoint
Attribute `bindingTime** 类型：BindingTimeEnum，多重性：0..1 — 最新绑定时间
Attribute `blueprintDerivationTime** 类型：BlueprintDerivationTimeEnum，多重性：0..1 — 蓝图派生时间
Attribute `shortLabel** 类型：VariationPointShortLabel，多重性：0..1 — 变体点短标签
Attribute `condition** 类型：ConditionByFormula，多重性：0..1 — 条件公式

7.7 评估的变体 (Evaluated Variants)

评估的变体记录哪些变体被实际选择。

EvaluatedVariantSet 类表（摘要）：

字段 值
Class EvaluatedVariantSet
Attribute `evaluatedElement** 类型：Identifiable，多重性：0..1 — 被评估的元素的引用
Attribute `approvalStatus** 类型：ApprovalStatus
Attribute `includedVariant** 类型：* — 包含的变体

7.8 选择变体 (Choosing Variants)

变体的定义：变体是绑定时间上的具体选择。

有效变体：满足条件并通过验证的变体。

7.9 示例 (Examples)

7.9.1 聚合模式示例

展示了如何在聚合关系中应用变体点。

7.9.2 关联模式示例

展示了如何在关联关系中应用变体点。

7.9.3 属性值模式示例

展示了如何在属性中应用变体点。

7.9.4 属性集模式示例

展示了如何在属性集中应用变体点。

8 Splitable

8.1 介绍 (Introduction)

Splitable 机制允许将一个 AUTOSAR 模型拆分为多个物理文件。这对于大型项目的并行开发和模块化分发至关重要。

8.2 在多个物理文件中的分布 (Distribution in Multiple Physical Files)

可拆分的元素可以跨多个 ARXML 文件分布。可拆分性由 «atpSplitable» 构造型和 atp.Splitkey 标签控制。

8.3 部分模型的标识 (Identification of Partial Models)

AUTOSAR 类的拆分键：shortName, variationPoint.shortLabel

每个部分模型都需要能够通过这个键被唯一标识。

9 文档支持 (Documentation Support)

9.1 介绍 (Introduction)

AUTOSAR 提供了一个丰富的文档支持机制，允许在 M1 模型中嵌入结构化文档。

9.2 文档块 (Documentation Block)

DocumentationBlock 是文档的顶层容器。

DocumentationBlock 类表（摘要）：

字段 值
Class DocumentationBlock
Attribute `introduction** 类型：Paragraph（多语言），多重性：0..1
Attribute `note** 类型：Note（多语言），多重性：0..* — 注意事项
Attribute `list** 类型：List（多语言），多重性：0..* — 列表
Attribute `trace** 类型：Trace，多重性：0..* — 跟踪引用
Attribute `verbatim** 类型：Verbatim，多重性：0..* — 逐字文本
Attribute `label** 类型：Label（多语言），多重性：0..* — 标签
Attribute `unit** 类型：DocumentationBlock，多重性：0..* — 嵌套块

9.2.1 段落 (Paragraph)

Paragraph 是多语言段落文本。

9.2.2 逐字 (Verbatim)

Verbatim 用于嵌入预格式化的文本（如代码示例）。

9.2.3 文档中的列表 (Lists in Documentation)

列表类型：

  • LIST — 项目符号列表
  • DEFINITION — 定义列表
  • NUMBERED — 编号列表
  • LABEL — 标签列表
  • INLINE — 内联列表

9.2.4 文档中的图 (Figures in Documentation)

图可以通过 Figure 类嵌入。

9.2.5 文档中的公式 (Formula in Documentation)

公式通过 Formula 类嵌入。

9.2.6 文档中的注意事项 (Notes in Documentation)

Note 类用于插入突出的注意事项。

9.2.7 文档中的可追溯性支持

Trace 类允许创建可追溯性引用到模型元素。

9.2.8 混合内容与内联文本模型元素

MixedContentForLongName 和 InlineTextModelElement 允许在文本中混合模型引用。

9.3 独立文档 (Standalone Documentation)

StandaloneDocumentation 是完整的、可独立呈现的文档。

9.3.1 文档的上下文 (Documentation's Context)

每个独立文档都有一个上下文（描述其目的和范围）。

9.3.2 章节 (Chapter)

文档组织为 Chapter、Section 等结构化层级。

9.3.3 文档中的表格 (Tables in Documentation)

Table 类允许在文档中嵌入表格。

9.3.4 文档中的主题 (Topics in Documentation)

Topic 是可重用的文档片段。

9.3.5 参数表 (Parameter tables)

参数表用于记录函数参数。

9.4 文档生成 (Document production)

文档可以从 AUTOSAR 模型自动生成。

9.5 包含生成的文档部分 (Including generated documentation parts)

文档可以包含从其他源生成的文档部分。

9.6 在 AUTOSAR 工件中处理多种语言 (Handling Multiple Languages in an AUTOSAR Artifact)

AUTOSAR 通过 MultiLanguagePlainText 等多语言容器支持多语言文档。

9.7 文档视图 (Document Views)

DocumentView 允许定义自定义视图以从同一模型生成不同的文档。

10 构建操作清单 (The Build Action Manifest)

10.1 介绍 (Introduction)

BuildActionManifest 是一个工件，描述了构建过程（源代码到可执行映像）。

10.2 BuildActionManifest 概览 (BuildActionManifest Overview)

BuildActionManifest 包含一个或多个 BuildAction 元素。

10.2.1 BuildAction

BuildAction 类表（摘要）：

字段 值
Class BuildAction
Attribute `name** 类型：Identifier，多重性：1
Attribute `input** 类型：BuildActionIoElement，多重性：0..* — 输入
Attribute `output** 类型：BuildActionIoElement，多重性：0..* — 输出
Attribute `environment** 类型：BuildActionEnvironment，多重性：0..1 — 环境
Attribute `entity** 类型：BuildActionEntity，多重性：0..* — 实体（工具、模块）
Attribute `invocation** 类型：String，多重性：0..* — 调用命令

10.2.2 BuildActionIoElement

BuildActionIoElement 类表（摘要）：

字段 值
Class BuildActionIoElement
Attribute `kind** 类型：BuildActionIoKindEnum — I/O 类型（源、目标、中间）
Attribute `arPackage** 类型：ARPackage — 关联的 ARPackage

10.2.3 BuildActionEnvironment

环境变量、工具链配置等。

10.2.4 BuildActionEntity

BuildActionEntity 类表（摘要）：

字段 值
Class BuildActionEntity
Attribute `name** 类型：Identifier，多重性：1
Attribute `project** 类型：String，多重性：0..* — 项目名
Attribute `generator** 类型：String，多重性：0..* — 生成器名
Attribute `module** 类型：String，多重性：0..* — 模块名

10.2.5 特殊数据的使用 (Usage of Special Data)

BuildActionManifest 大量使用 SDG/SD 进行扩展。

10.2.6 示例 (Example)

展示了完整的 BuildActionManifest 示例。

10.3 约束与假设 (Constraints and assumptions)

构建清单的验证规则。

11 角色与权限 (Roles and Rights)

RoleBasedMetadataAssignment 类允许将角色分配给模型元素。角色控制对模型的读写权限。

RoleBasedMetadataAssignment 类表（摘要）：

字段 值
Class RoleBasedMetadataAssignment
Attribute `shortLabel** 类型：String，多重性：0..1
Attribute `category** 类型：CategoryString，多重性：0..1
Attribute `role** 类型：``Referrable` 的子类，多重性：0..* — 角色
Attribute `operation** 类型：``Referrable` 的子类，多重性：0..* — 操作
Attribute `swc** 类型：``Referrable` 的子类，多重性：0..* — 软件组件

12 生命周期支持 (Life Cycle Support)

12.1 介绍 (Introduction)

AUTOSAR 元模型支持生命周期的概念，允许跟踪模型元素从创建到退役的整个过程。

12.2 定义生命周期 (Definition of a life cycle)

LifeCycleInfo 类表（摘要）：

字段 值
Class LifeCycleInfo
Attribute `lcIdentifier** 类型：Identifier，多重性：1 — 生命周期标识符
Attribute `periodStart** 类型：DateTime，多重性：0..1 — 期间开始
Attribute `periodEnd** 类型：DateTime，多重性：0..1 — 期间结束

12.3 应用生命周期 (Application of a life cycle)

12.3.1 LifeCycleInfoSet

LifeCycleInfoSet 是 LifeCycleInfo 的容器。

12.3.2 LifeCycleInfo

LifeCycleInfo 描述单个生命周期阶段。

12.3.3 LifeCycleState 的传播

生命周期状态沿包含层次结构传播。

13 集合与可收集元素 (Collections and Collectable Elements)

Collection 类允许将多个模型元素分组到一个集合中。CollectableElement 是可以成为集合一部分的元类。

14 映射视图 (Mapping Views)

MappingView 类允许定义自定义映射视图以支持特定用例（例如系统提取、ECU 提取）。

摘要：附录 (Appendices Summary)

A 词汇表 (Glossary)

完整词汇表见原文 PDF 第 380-383 页

主要术语：

  • ARXML — AUTOSAR XML 格式
  • BSW — Basic Software（基础软件）
  • ECU — Electronic Control Unit（电子控制单元）
  • M0/M1/M2/M3 — 元模型层次
  • RTE — Runtime Environment（运行时环境）
  • SWC — Software Component（软件组件）
  • VFB — Virtual Functional Bus（虚拟功能总线）

B 约束历史 (Constraint History)

完整约束历史表见原文 PDF 第 384-401 页

约束历史记录了从 R4.0.1 到 R4.4.0 中添加、修改、删除的约束和可追溯性项目。

C 元模型中所有变体点 (All Variation Points in Meta Model)

完整列表见原文 PDF 第 402-408 页

本附录列出了元模型中所有变体点的位置和描述。

D 本模板中可拆分元素 (Splitable Elements in this Template)

完整列表见原文 PDF 第 409 页

本附录列出了本模板中标记为 «atpSplitable» 的元素。

E 引用的类表 (Mentioned Class Tables)

完整类表见原文 PDF 第 409-462 页

本附录提供了本文档中引用的所有类的完整类表（包括所有属性的详细信息）。

F 示例 (Examples)

F.1 VariationPoints 中的 ShortLabels

F.1.1 具有相同 shortName 的可标识对象

此示例说明了当多个 Identifiable 具有相同 shortName 时如何使用 shortLabel 来区分。

翻译说明

本翻译采用"重点翻译 + 摘要"策略：

  • 完整翻译：封面、文档标识、变更历史、目录、前 13 个核心章节（介绍、UML 使用、顶层结构、通用模板类、抽象结构、元建模模式、变体处理、Splitable、文档支持、构建清单、角色权限、生命周期、集合、映射视图）
  • 摘要标记：附录部分（A-Glossary 到 F-Examples）使用摘要标记
  • 保留内容：所有 API 标识符（UML 类名、属性名、ARXML 标签、UML 构造型如 «atpMixed»、约束 ID 如 [TPS_GST_00080]、协议名 CAN/LIN/BSW/RTE）保持英文
  • 不翻译：版权声明、需求 ID 编号、UML 标签的语法符号
  • 方法论标记：所有 [TPS_GST_*]、[constr_*] 需求标识符保留

参考资料 (References)

编号 标题 来源
[1] Meta Model AUTOSAR_MMOD_MetaModel
[2] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[3] XML Schema Production Rules AUTOSAR_TPS_XMLSchemaProductionRules
[4] Specification of ECU Resource Template AUTOSAR_TPS_ECUResourceTemplate
[5] System Template AUTOSAR_TPS_SystemTemplate
[6] Requirements on Interoperability of AUTOSAR Tools AUTOSAR_RS_InteroperabilityOfAutosarTools
[7] Predefined Names in AUTOSAR AUTOSAR_TR_PredefinedNames
[8] List of Basic Software Modules AUTOSAR_TR_BSWModuleList
[9] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate
[10] XML Schema 1.0 http://www.w3.org/TR/xmlschema-1
[11] ANTLR parser generator V3 —
[12] C++ Operator Precedence http://www.cppreference.com/wiki/operator_precedence
[13] Collection of blueprints for AUTOSAR M1 models AUTOSAR_MOD_GeneralBlueprints
[14] Issue Exchange Format V3.0.0 http://www.asam.net
[15] Container Catalog XML Model Specification http://www.asam.net
[16] ASAM MCD 2MC ASAP2 Interface Specification http://www.asam.net — ASAP2-V1.51.pdf
[17] Methodology AUTOSAR_TR_Methodology
[18] Standardized M1 Models used for the Definition of AUTOSAR AUTOSAR_MOD_GeneralDefinitions
[19] Specification of RTE Software AUTOSAR_SWS_RTE
[20] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[21] Unified Modeling Language: Superstructure, Version 2.0 OMG — http://www.omg.org/cgi-bin/apps/doc?formal/05-07-04
[22] ASAM AE Functional Specification Exchange Format V1.0.0 http://www.asam.net — AE-FSX_V1.0.0.pdf
[23] OASIS open exchange table model http://www.oasis-open.org/specs/tm9901.html
[24] Software Process Engineering Meta-Model Specification http://www.omg.org/spec/SPEM/2.0/
Reference in New Issue View Git Blame Copy Permalink