# 通用结构模板 (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)](#1-介绍-introduction) - [1.1 范围 (Scope)](#11-范围-scope) - [1.2 文档约定 (Document Conventions)](#12-文档约定-document-conventions) - [1.3 定义正式模板的方法论 (Methodology for Defining Formal Templates)](#13-定义正式模板的方法论-methodology-for-defining-formal-templates) - [1.4 元模型组织 (Organization of the Meta-Model)](#14-元模型组织-organization-of-the-meta-model) - [2 AUTOSAR 模板中 UML 的使用 (Usage of UML in AUTOSAR Templates)](#2-autosar-模板中-uml-的使用-usage-of-uml-in-autosar-templates) - [2.1 UML 图 (UML Diagrams)](#21-uml-图-uml-diagrams) - [2.2 AUTOSAR 元模型层次结构 (The AUTOSAR Meta-Model Hierarchy)](#22-autosar-元模型层次结构-the-autosar-meta-model-hierarchy) - [2.3 构造型 (Stereotypes)](#23-构造型-stereotypes) - [2.4 UML 标签 (UML Tags)](#24-uml-标签-uml-tags) - [3 AUTOSAR 顶层结构 (Autosar Top Level Structure)](#3-autosar-顶层结构-autosar-top-level-structure) - [4 通用模板类 (General Template Classes)](#4-通用模板类-general-template-classes) - [4.1 ARObject - 所有类的公共属性](#41-arobject---所有类的公共属性) - [4.2 AUTOSAR 中的包 (Packages in Autosar)](#42-autosar-中的包-packages-in-autosar) - [4.3 Identifiable 与 Referrable](#43-identifiable-与-referrable) - [4.4 管理数据 (Administrative Data)](#44-管理数据-administrative-data) - [4.5 特殊数据 - 扩展机制 (Special Data)](#45-特殊数据---扩展机制-special-data) - [4.6 模型限制类型 (Model Restriction Types)](#46-模型限制类型-model-restriction-types) - [4.7 原始类型 (Primitive Types)](#47-原始类型-primitive-types) - [4.8 公式语言 (Formula Language)](#48-公式语言-formula-language) - [4.9 ARMQL](#49-autosar-模型查询语言-armql) - [4.10-4.13 其他通用类](#410-工程对象-到-413-tagwithoptionalvalue) - [5 抽象结构 (AbstractStructure)](#5-抽象结构-abstractstructure) - [6 元建模模式与模型转换 (Metamodeling Patterns and Model Transformation)](#6-元建模模式与模型转换-metamodeling-patterns-and-model-transformation) - [7 变体处理 (Variant Handling)](#7-变体处理-variant-handling) - [8 Splitable](#8-splitable) - [9 文档支持 (Documentation Support)](#9-文档支持-documentation-support) - [10 构建操作清单 (The Build Action Manifest)](#10-构建操作清单-the-build-action-manifest) - [11 角色与权限 (Roles and Rights)](#11-角色与权限-roles-and-rights) - [12 生命周期支持 (Life Cycle Support)](#12-生命周期支持-life-cycle-support) - [13 集合与可收集元素 (Collections and Collectable Elements)](#13-集合与可收集元素-collections-and-collectable-elements) - [14 映射视图 (Mapping Views)](#14-映射视图-mapping-views) - [A 词汇表 (Glossary)](#a-词汇表-glossary) - [B 约束历史 (Constraint History)](#b-约束历史-constraint-history) - [C 元模型中所有变体点 (All Variation Points in Meta Model)](#c-元模型中所有变体点-all-variation-points-in-meta-model) - [D 本模板中可拆分元素 (Splitable Elements in this Template)](#d-本模板中可拆分元素-splitable-elements-in-this-template) - [E 引用的类表 (Mentioned Class Tables)](#e-引用的类表-mentioned-class-tables) - [F 示例 (Examples)](#f-示例-examples) --- ## 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 runtime 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 文件中的文件信息注释** ```xml ToolA.1.2.3 ... ... ... ``` **类表 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 EN English German demo ``` **类表 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/ |