# AUTOSAR 工具互操作性 **AUTOSAR CP Release 4.4.0** ## 文档元信息 | 项目 | 内容 | |---|---| | 文档标题 | Interoperability of AUTOSAR Tools（AUTOSAR 工具互操作性） | | 文档所有者 | AUTOSAR | | 文档责任方 | AUTOSAR | | 文档标识号 | 204 | | 文档状态 | Final（最终版） | | 所属 AUTOSAR 标准 | Classic Platform | | 所属标准版本 | 4.4.0 | ## 文档变更历史 | 日期 | 版本 | 变更人 | 变更描述 | |---|---|---|---| | 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 将规范标记为已过时 | | 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 微小的修正/澄清/编辑性修改 | | 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 清理；微小的修正/澄清/编辑性修改 | | 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 微小的修正/澄清/编辑性修改 | | 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 微小的修正/澄清/编辑性修改 | | 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 编辑性修改 | | 2013-03-15 | 4.1.1 | AUTOSAR Administration | 添加正式规范项；支持处理器清单；支持角色和权限 | | 2011-12-22 | 4.0.3 | AUTOSAR Administration | 编辑性修改，包括标记的规范项；改进 AUTOSAR 文件用例的建议；XML 序列化定义的细化；范围细化到 AUTOSAR 工具；添加 R4 方面（变体处理、可分割、相对引用） | | 2010-02-02 | 3.1.4 | AUTOSAR Administration | 关于 XML 序列化的更多细节；关于错误报告的更多细节；关于合并的更多细节；移除了对 AUTOSAR 产品（元模型和模式）的要求 | | 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 | | 2007-12-21 | 3.0.1 | AUTOSAR Administration | 添加了关于如何合并模型的描述；移除了对不再存在的文档的依赖；添加了关于扩展机制的要求；添加了关于处理/交换错误的要求；文档元信息扩展；小幅布局调整 | | 2007-01-24 | 2.1.15 | AUTOSAR Administration | NonSplitableElements 是大多数 AUTOSAR 描述的最小粒度；法律免责声明修订；添加发行说明；"用户建议"修订；"修订信息"添加 | | 2006-05-16 | 2.0 | AUTOSAR Administration | 初始发布 | > **重要提示**：本规范已过时（obsolete），将在后续版本中从标准中移除。 --- ## 目录 1. [引言](#1-引言) - 1.1 [AUTOSAR 工具的分类（非规范性）](#11-autosar-工具的分类非规范性) - 1.2 [起源和目标（非规范性）](#12-起源和目标非规范性) - 1.3 [文档约定](#13-文档约定) - 1.4 [需求追踪](#14-需求追踪) 2. [基本概念](#2-基本概念) - 2.1 [数据表示](#21-数据表示) - 2.1.1 [技术空间："元模型"](#211-技术空间元模型) - 2.1.2 [技术空间："XML"](#212-技术空间xml) - 2.1.3 [技术空间："工具"](#213-技术空间工具) - 2.2 [信息交换的抽象级别](#22-信息交换的抽象级别) 3. [AUTOSAR 工具的需求](#3-autosar-工具的需求) - 3.1 [支持 AUTOSAR XML 数据交换](#31-支持-autosar-xml-数据交换) - 3.1.1 [物理级别](#311-物理级别) - 3.1.2 [数据格式级别](#312-数据格式级别) - 3.1.3 [内容级别](#313-内容级别) - 3.1.4 [语义级别](#314-语义级别) - 3.1.5 [方法论级别](#315-方法论级别) - 3.1.6 [表示级别](#316-表示级别) - 3.2 [支持并发建模](#32-支持并发建模) 4. [附录](#4-附录) - 4.1 [参考文献](#41-参考文献) - 4.2 [附录](#42-附录) --- ## 1 引言 本文档定义了 AUTOSAR 工具的互操作性，包括 AUTOSAR 工具如何交换 AUTOSAR 模型。 根据图 1.1，本文档依赖于"Requirements on Interoperability of Authoring Tools"[1] 和"Methodology"[2]。 本文档定义了对 AUTOSAR 工具的需求。因此，它补充了文档"Generic Structure Template"[3]、文档"ARXML Serialization Rules"和文档"XML Schema Production Rules"[4] 的以下方面： - "XML Schema Production Rules"描述了 M2 方面，而"Interoperability of AUTOSAR tools"处理 M1（AUTOSAR XML 描述）方面。 - "ARXML Serialization Rules"描述了 AUTOSAR 模型序列化的规则。序列化通常由 AUTOSAR 创作工具完成。 - "Generic Structure Template"描述了元模型设施，而"Interoperability of AUTOSAR tools"处理实现特定方面。 ### 1.1 AUTOSAR 工具的分类（非规范性） AUTOSAR 方法论模型 [2] 描述了使用 AUTOSAR 开发系统的主要步骤：从系统级到生成 ECU 可执行文件。它描述了工作产品和任务的依赖关系。 AUTOSAR 工具可以支持 AUTOSAR 方法论的一个或多个任务。 换句话说，术语 AUTOSAR 工具指支持以下列模板定义的系统及其配置的 AUTOSAR 模型的创建、修改和解释任务的所有工具： - Generic Structure Template [3] - Software-Component Template [5] - ECU Resource Template [6] - System Template [7] - Basic Software Module Description Template [8] - Specification of ECU Configuration [9] - Diagnostic Extract Template [10] 因此，所有 AUTOSAR 工具都以某种方式处理 AUTOSAR XML 描述（即 AUTOSAR 模型的 XML 表示，参见 [4]）。根据与 XML 交互的性质，可以区分三种 AUTOSAR 工具，如图 1.2 所示： - **AUTOSAR Importer Tools（导入工具）**：通过导入非 AUTOSAR 工件来创建 AUTOSAR 模型（作为 XML 描述）。请注意，导入工具也可以集成在 AUTOSAR 创作工具中。 - **AUTOSAR Authoring Tools（创作工具）**：用于创建和修改 AUTOSAR 模型（作为 XML 描述） - **AUTOSAR Converter Tools（转换器工具）**：通过从现有 AUTOSAR XML 描述转换信息来生成新的 AUTOSAR XML 描述 - **AUTOSAR Processor Tools（处理器工具）**：通过处理 AUTOSAR XML 描述来生成非 AUTOSAR 工件 工具也可以充当这三种类型的组合，例如 RTE 生成器可以一步生成代码和 XML 描述（例如其自身实现方面的 XML 描述），充当转换器和处理器工具的组合。 由于这三种类型中只有创作工具可以修改现有的 AUTOSAR 模型，因此一般来说，大多数互操作性要求都适用于创作工具。 **图 1.3：创作工具的任务示例，包括行为模型和 AUTOSAR 模型之间的耦合** **图 1.4：下游 XML 工件和任务示例** AUTOSAR 软件组件的形式化描述不包括软件组件行为的完整形式化描述。后者有意留给专门的行为建模工具（BMT）。 因此，有必要弥合软件组件模型与由特定 BMT 创建的相应行为模型之间的差距。此任务由图 1.3 中提到的"耦合工具"执行。 ### 1.2 起源和目标（非规范性） > **摘要**：本节讨论了 AUTOSAR 工具互操作性文档的起源和目标。该文档源于 AUTOSAR 工具之间需要交换 AUTOSAR 模型的需求，特别是不同供应商的工具之间。 ### 1.3 文档约定 本文档使用以下约定： - 关键字"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 按照 RFC 2119 进行解释。 - 文档中的"d"后缀表示该段落是描述性的（descriptive），"c"后缀表示该段落是约束性的（constraint）。 ### 1.4 需求追踪 下表引用了 [1] 中指定的用例和需求，并链接到这些的履行： | 需求 | 描述 | 由满足 | |---|---|---| | [RS_IOAT_00001] | 支持数据交换 | [TR_IOAT_00071] [TR_IOAT_00072] | | [RS_IOAT_00002] | 标准化 AUTOSAR 模型中错误的处理 | [TR_IOAT_00065] | | [RS_IOAT_00003] | 提供命名约定 | [TR_IOAT_00062] [TR_IOAT_00069] | | [UC_IOAT_00001] | 集成从 OEM 传递的 AUTOSAR 模型的提取，用于进一步细化和实现给供应商 | [TR_IOAT_00035] [TR_IOAT_00063] [TR_IOAT_00064] | | [UC_IOAT_00002] | 处理 AUTOSAR 元模型随时间的变化 | [TR_IOAT_00005] [TR_IOAT_00066] | | [UC_IOAT_00004] | 允许在同一模型上并发工作 | [TR_IOAT_00062] [TR_IOAT_00067] [TR_IOAT_00074] | | [UC_IOAT_00005] | 在自顶向下的功能开发的不同步骤中使用 | [TR_IOAT_00035] [TR_IOAT_00065] | | [UC_IOAT_00006] | 支持在工具链中直接交换 AUTOSAR 模型 | [TR_IOAT_00065] | | [UC_IOAT_00008] | AUTOSAR 模型和相关工件从一个参与方交付到另一个参与方 | [TR_IOAT_00036] [TR_IOAT_00062] [TR_IOAT_00065] [TR_IOAT_00073] | | [UC_IOAT_00010] | 处理相同的重复定义 | [TR_IOAT_00063] [TR_IOAT_00064] | | [UC_IOAT_00014] | 验证模型对配置文件的合规性 | [TR_IOAT_00076] | | [UC_IOAT_00030] | 描述数据交换点 | [TR_IOAT_00076] | | [UC_IOAT_00041] | 将数据需求传达给上游工具 | [TR_IOAT_00076] | **表 1.1：需求追踪** ## 2 基本概念 ### 2.1 数据表示 在开发过程中，使用了许多具有不同 AUTOSAR 模型表示的工具（Excel 表格、建模工具、UML、XML 等）。每种工具及其底层数据表示都有其优点和缺点。这些工具和表示可以分组到技术空间中。 技术空间是具有一组相关概念、知识体系、工具、所需技能和可能性的工作上下文 [14]。AUTOSAR 中使用的技术空间的示例包括：元模型、XML 和 AUTOSAR 创作工具（参见图 2.1）。 技术空间（例如元模型和 XML）不是孤岛。几个技术空间之间存在桥梁。 可交付成果"AUTOSAR Interaction with Behavioral Models"解释了 AUTOSAR 元模型和 AUTOSAR 概念如何映射到行为模型以及如何映射回来。例如，文档"ARXML Serialization Rules"[15] 定义了如何将 AUTOSAR 元模型映射到 W3C XML 模式。 在 AUTOSAR 中使用 XML 和 UML 结合了两个技术空间的优势： - AUTOSAR 为 AUTOSAR 中交换的数据定义了模板。由于 XML 被广泛接受为结构化数据表示和交换的标准，因此选择它作为 AUTOSAR 模型交换的基础。 - 由于数据及其相互关系的复杂性，手动创建一致的 AUTOSAR XML 模式被证明是耗时且容易出错的。此外，XML 模式的表达能力不足以表达数据实体之间的内容相关约束。 - 因此，选择了基于元模型的方法，通过 UML2.0 类图以图形方式描述模板。无法以图形方式表述的约束分别在模板规范和 OCL（对象约束语言）中以文本方式描述。 定义所有可用于描述 AUTOSAR 系统和相关工件的数据实体和相互关系的 UML 模型称为 AUTOSAR 元模型。元模型的实例（即软件组件等的具体描述）称为 AUTOSAR 模型。 **图 2.1 描绘了上述技术空间。元级别（M0 到 M4）显示了不同技术空间中概念的对应关系。一个元级别中的所有概念都是密切相关的。** 与 OMG 使用的经典四层架构不同，这里显示了五个元级别。从最低、最具体的元级别开始，这些是： - **M0：AUTOSAR 对象** 这是工作中的 AUTOSAR 系统的实现：例如，执行包含例如挡风玻璃雨刷控制软件的软件映像的真实 ECU。 - **M1：AUTOSAR 模型** 此元级别上的模型由 AUTOSAR 开发人员构建。它们可以定义一个名为"挡风玻璃雨刷"的软件组件，该组件具有一定数量的端口，连接到另一个软件组件，依此类推。 在此级别上，描述 AUTOSAR 系统所需的所有工件都已详细说明，包括可重用类型以及这些类型的特定实例。 AUTOSAR 软件被加载到各个 ECU 中，用于各个车辆。这种加载意味着 M1 模型被实例化。 请注意，此类 AUTOSAR 模型可以使用从 XML 到 C 甚至 PDF 的各种格式表示。 - **M2：AUTOSAR 元模型** 在此元级别上，定义了 AUTOSAR 模板的词汇表。此词汇表以后可由基于 AUTOSAR 的 ECU 系统的开发人员使用。 例如，在 M2 上定义了在 AUTOSAR 中有一个称为"软件组件"的实体，它聚合了一个称为"端口"的实体。此定义确保 AUTOSAR 软件组件的开发人员可以描述其特定组件及其端口。 此描述称为 AUTOSAR 模型，位于 M1 上。 - **M3：AUTOSAR 模板的 UML 配置文件** M2 上的 AUTOSAR 模板是根据 M3 上定义的元模型构建的。如前所述，这是 UML 与特定的 UML 配置文件一起，以更好地支持模板建模工作。 形式上，M2 上的模板仍然是 UML 的实例，但同时应用了模板配置文件，即还需要遵守配置文件中构造型设置的附加规则。配置文件的相关详细信息在 [3] 中指定。 - **M4：元对象设施** 仅为了完整性，OMG 的 MOF 位于最终的元级别 M4。不需要进一步的元级别，因为 MOF 被设计为可反射的。 请注意，AUTOSAR 模型可以使用从 XML 到 C 甚至 PDF 的各种技术空间表示。 这些格式之间的转换称为"转换"，而 AUTOSAR 模型遵循 AUTOSAR 元模型的事实称为"实例化"。 因此，AUTOSAR 模型（M1）称为 AUTOSAR 元模型（M2）的实例。 #### 2.1.1 技术空间："元模型" 技术空间"元模型"涉及 OMG 最近提出的模型驱动架构（MDA）方法。 根据 MDA，软件开发过程填充了许多不同的模型，每个模型表示正在构建的系统的特定视图。模型以其元模型的语言编写。 图 2.1 的左侧部分显示了 AUTOSAR 中使用的元模型技术空间： - 最低部分称为 M0，对应于现实世界。在元模型技术空间中，AUTOSAR 没有 M0 对象的表示。仅为了完整性而提及。 - 所有 AUTOSAR 模型都处于 M1 级别。对于某些标准化模型，AUTOSAR 使用 UML 对象模型。 - M2 AUTOSAR 元模型通过 UML2.0 类图描述，并在 AUTOSAR 模板规范中正式标识约束。 - 关于可用于创建 AUTOSAR 元模型的语言的详细描述在 M3 级别上由 UML2.0 元模型和 AUTOSAR 模板配置文件提供（有关 AUTOSAR 模板配置文件的更多信息，请参阅 [3]）。 - UML2 元模型由 MOF 定义，构成 M4 级别。 #### 2.1.2 技术空间："XML" 可扩展标记语言（XML）是由 W3C 标准化的标记语言。它被广泛接受为表示和交换结构化和半结构化数据的标准。 XML 描述是 XML 技术空间中的核心概念。描述以格式良好的语法和有效性约束所约束的语法编写。格式良好的约束由 XML 语法规则定义，而有效性约束在称为 XML 模式的单独文档中定义，该文档以给定的模式语言（W3C XML DTD [16]、W3C XML Schema [17] 等）编写。 换句话说：XML 语法描述了 XML 描述包含开始和结束标签等。XML 模式定义了例如哪些标签可以在哪些组合中使用。 图 2.1 的中间部分说明了 XML 描述、XML 语法和 XML 模式之间的关系。 XML 技术空间可以被认为是低级技术空间：AUTOSAR 元模型可以映射到 XML 模式 [4]。但是，原始 AUTOSAR 元模型无法从 XML 模式精确重构。 #### 2.1.3 技术空间："工具" 每个工具都有其内部数据结构，该结构实现了可在工具中使用的概念。此内部数据结构位于元模型级别（M2）并定义了可用于解释或创建描述或模型（M1）的语言。 可从模型生成的代码是模型的不同表示（例如 C）。在汽车 ECU 上执行的代码的运行时实例在元级别 M0 上表示。 在大多数情况下，AUTOSAR 工具的内部数据结构与 AUTOSAR 元模型定义的结构不同，例如出于性能或历史原因。 为了允许互操作性，需要将由内部数据结构表示的模型映射到 AUTOSAR XML 描述。 此映射和工具的内部数据结构不属于 AUTOSAR 标准化的主题，因此不在本文档的范围内。 ### 2.2 信息交换的抽象级别 表 2.1 描绘了本文档中用于构建对创作工具互操作性和 AUTOSAR 数据交换格式的需求的几个抽象级别。 每个抽象级别都基于其下方的级别。对于每个抽象级别，描述了必须支持的机制 —— 从物理级别（文件集）开始，直到语义层（在 AUTOSAR 元模型中正式指定的语义约束）。 抽象级别"表示级别"和"应用程序级别"与基本创作工具互操作性无关，但可能对执行类似功能的 AUTOSAR 创作工具的可交换性产生影响。 **表 2.1：抽象级别** | 抽象级别 | 描述 | |---|---| | **物理级别（Physical level）** | 文件集 | | **数据格式级别（Data format level）** | 文件格式（XML） | | **内容级别（Content level）** | 数据模型的内部表示 | | **语义级别（Semantic level）** | 语义约束（在 AUTOSAR 元模型中正式指定） | | **方法论级别（Methodology Level）** | 方法论方面的交换 | | **表示级别（Presentation level）** | 图形表示 | | **应用程序级别（Application level）** | 工具特定的功能 | 换句话说：每个 AUTOSAR 创作工具应支持基于可以分布在多个文件中的 XML 描述集合的 AUTOSAR 模型交换。 ## 3 AUTOSAR 工具的需求 ### 3.1 支持 AUTOSAR XML 数据交换 **图 3.1：支持 AUTOSAR 数据交换格式** [TR_IOAT_00072] 支持 AUTOSAR XML 数据交换 当在不同部门或公司之间交换数据时，所有相关方需要就交换信息的共同措辞达成一致。否则，所有各方对信息的理解不同。在 AUTOSAR 创作工具之间交换 AUTOSAR 模型也是如此：每当交换 AUTOSAR 模型时，它们需要表示为 AUTOSAR XML 描述。 如果工具链中的工具都能够处理 AUTOSAR 元模型中描述的完整信息集，则它们可以完美地交换其 AUTOSAR 模型。当然，这要求所有工具已实现以下功能： - 物理级别（例如它们支持文件） - 数据格式级别（例如文件相对于 AUTOSAR XML 模式有效） - 内容级别（例如数据可以加载到工具的内部数据模型中） - 语义级别（例如可以根据模板规范评估所有语义约束） 可选地，这些工具可以使用与表示级别中定义的相同的图形符号。 #### 3.1.1 物理级别 ##### 3.1.1.1 AUTOSAR 工具应支持文件集 **[TR_IOAT_00010] AUTOSAR 工具应支持文件集** | 字段 | 内容 | |---|---| | **Description** | AUTOSAR 工具应支持读取和写入存储在文件系统中的单个文件和文件集。工具应提供一种机制来选择文件系统中特定的文件和文件集。 | | **Rationale** | AUTOSAR XML 描述可以分多个文件交付。一些文件可能包含数据类型，其他文件可能包含接口等。 | | **Use Case** | 这允许通过 CD、DVD、电子邮件等传输模型。将 AUTOSAR 模型（表示为 AUTOSAR XML 描述）拆分为多个文件支持并发建模和更细粒度的版本控制。这允许由不同用户或角色开发模型的部分。此外，它允许重用模型中未更改的部分。 | | **Dependencies** | [TR_IOAT_00036]、[TR_IOAT_00042]、[TR_IOAT_00063] | | **Supporting Material** | [20] 中指定的 ASAM Container Catalog | 以下详细信息适用： - AUTOSAR 工具应能以任何顺序读取文件。更改读取顺序不应导致模型语义的任何变化。 - AUTOSAR 创作工具应将已更改的模型元素保存在与从中读取的同一文件中。 - 如果同一元素是从两个工件中读取的，则需要将其序列化回这两个工件（[TR_IOAT_00063]）。 - AUTOSAR 创作工具应允许用户指定新创建的模型元素应保存在哪个文件中。 - AUTOSAR 工具应能从事 ASAM 目录文件中读取要处理的文件（[TR_IOAT_00036]）。 #### 3.1.2 数据格式级别 ##### 3.1.2.1 AUTOSAR 工具应支持 AUTOSAR XML 描述 **[TR_IOAT_00012] AUTOSAR 工具应支持 AUTOSAR XML 描述** | 字段 | 内容 | |---|---| | **Description** | AUTOSAR 工具应支持 AUTOSAR XML 描述的解释和创建。这些描述应按照 XML 建议（W3C XML 1.0 Specification [16]）定义为"格式良好"和"有效"，无论是否使用文档相应的 AUTOSAR XML 模式。换句话说：即使工具不使用标准的 XML 机制来验证 XML 描述，它也应确保 XML 描述可以成功针对 AUTOSAR XML 模式进行验证。 | | **Rationale** | 每个 AUTOSAR XML 描述文件必须符合 AUTOSAR XML 模式。 | | **Use Case** | – | | **Dependencies** | 此要求的专门化在 [TR_IOAT_00033] 中定义。 | | **Supporting Material** | W3C XML 1.0 Specification [16] | ##### 3.1.2.2 创作工具应能导入和导出支持的模型元素作为 AUTOSAR XML 描述 **[TR_IOAT_00033] 创作工具应能导入和导出支持的模型元素作为 AUTOSAR XML 描述** 对于 AUTOSAR 定义并由创作工具支持的所有模型元素，工具应向用户提供从 XML 描述导入它们并将它们导出为成功针对 AUTOSAR XML 模式验证的 XML 描述的可能性。 即使工具有非 AUTOSAR 模型交换的可能性，它仍应支持创建相应的 AUTOSAR XML 描述。 可能在两个工具或同一工具的独立组件之间存在某种数据交换机制。这种机制可能使工具能够绕过 AUTOSAR XML 描述，即使模型可以由 AUTOSAR XML 描述表示。 避免绕过标准化 AUTOSAR XML 描述的专有交换格式，从而危及来自不同供应商的工具的互操作性。 ##### 3.1.2.3 创作工具应支持明确定义的序列化 **[TR_IOAT_00062] 创作工具应支持明确定义的序列化** AUTOSAR 创作工具应为 XML 提供序列化，详细信息在文档"TPS ARXML Serialization Rules"中说明。 为了支持使用文本比较工具直接比较 AUTOSAR XML 描述，必须以可靠和标准化的方式生成 XML。 此要求还支持针对 XML 模式的明确定义的验证。 因此，AUTOSAR 工具应支持以下序列化： - XML 注释可能会被静默忽略，无需再次序列化。XML 注释不视为 AUTOSAR 模型的一部分。 - XML 处理指令可能会被静默忽略，无需再次序列化。允许 AUTOSAR 工具将处理指令放置到 AUTOSAR XML 描述中用于特定目的。 - 原语（如数值等）应按照从 AUTOSAR XML 描述中读取的方式或在 AUTOSAR 创作工具中由用户输入的方式进行序列化。 AUTOSAR 模型序列化的完整规则集可在文档"TPS ARXML Serialization Rules"中找到。 #### 3.1.3 内容级别 ##### 3.1.3.1 创作工具不应在用户无意的情况下更改模型内容 **[TR_IOAT_00007] 创作工具不应在用户无意的情况下更改模型内容** AUTOSAR 创作工具在解释和创建 AUTOSAR XML 描述时不应执行对 AUTOSAR 模型的任何更改。如果用户未明确触发或确认任何更改，则由原始 XML 描述表示的 AUTOSAR 模型的语义应等效于由创建的 XML 描述表示的模型的语义。这特别包括： - 创作工具应保留引用，即使目标在输入 XML 描述中不可用 - 原语（如数值、整数）的格式未更改 - 模型的包结构未更改 - 引用中的 base 属性未更改 - 不允许删除或更改 uuid - 不允许更改校验和和时间戳 元模型包含一些由 {ordered} 标记的元素。在解释和创建 XML 描述时，XML 表示中的顺序可能会在没有用户意图的情况下更改。其他用例也可能适用。 请注意，AUTOSAR 工具不需要保持校验和、时间戳和 uuid 与当前数据一致。因此，在导入 XML 描述、使用它并重新导出它之后，校验和、时间戳和 uuid 可能变得不一致。 ##### 3.1.3.2 创作工具应支持部分信息的交换 > **摘要**：本节描述了创作工具支持部分信息交换的需求。 ##### 3.1.3.3 创作工具应支持 AUTOSAR 扩展机制 > **摘要**：本节描述了创作工具支持 AUTOSAR 扩展机制（如 SDG 和自定义 CATEGORY）的需求。 ##### 3.1.3.4 创作工具应维护引用 > **摘要**：本节描述了创作工具维护引用的需求。 ##### 3.1.3.5 创作工具应遵循指定的访问权限 > **摘要**：本节描述了创作工具遵循指定的访问权限的需求。 #### 3.1.4 语义级别 ##### 3.1.4.1 创作工具应支持有效性检查 > **摘要**：本节描述了创作工具支持有效性检查的需求。 ##### 3.1.4.2 AUTOSAR 工具应支持变体 > **摘要**：本节描述了 AUTOSAR 工具支持变体的需求，包括条件编译、变体绑定等。 #### 3.1.5 方法论级别 ##### 3.1.5.1 AUTOSAR 应支持数据交换点的描述 > **摘要**：本节描述了 AUTOSAR 支持数据交换点描述的需求。 #### 3.1.6 表示级别 > **摘要**：本节描述了表示级别的需求，涉及 AUTOSAR 创作工具的图形表示。 ### 3.2 支持并发建模 #### 3.2.1 模型之间差异的检测 ##### 3.2.1.1 创作工具应提供显示 AUTOSAR 模型之间差异的机制 > **摘要**：本节描述了创作工具提供模型差异显示机制的需求。 ##### 3.2.1.2 差异的定义 > **摘要**：本节定义了模型之间差异的检测方法。 ##### 3.2.1.3 差异的定义 - 聚合 > **摘要**：本节讨论了聚合级别的差异。 ##### 3.2.1.4 差异的定义 - 引用 > **摘要**：本节讨论了引用级别的差异。 ##### 3.2.1.5 模型元素比较算法 > **摘要**：本节描述了模型元素比较的算法。 ##### 3.2.1.6 创作工具应支持模型元素的唯一标识 > **摘要**：本节描述了创作工具支持模型元素唯一标识的需求。 ##### 3.2.1.7 模型之间差异的示例（非规范性） > **摘要**：本节提供了模型之间差异的示例。 ## 4 附录 ### 4.1 参考文献 [1] Requirements on Interoperability of Authoring Tools AUTOSAR_RS_InteroperabilityOfAutosarTools.pdf [2] Methodology AUTOSAR_TR_Methodology.pdf [3] Generic Structure Template AUTOSAR_TPS_GenericStructureTemplate [4] XML Schema Production Rules AUTOSAR_TPS_XMLSchemaProductionRules [5] Software-Component Template AUTOSAR_TPS_SoftwareComponentTemplate [6] ECU Resource Template AUTOSAR_TPS_ECUResourceTemplate [7] System Template AUTOSAR_TPS_SystemTemplate [8] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate [9] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration [10] Diagnostic Extract Template AUTOSAR_TPS_DiagnosticExtractTemplate [11] Specification of Feature Definition of Authoring Tools AUTOSAR_FeatureDefinition [12] AUTOSAR Interoperability of Authoring Tools Supplement AUTOSAR_TR_InteroperabilityOfAutosarToolsSupplement [13] Standardization Template AUTOSAR_TPS_StandardizationTemplate [14] Technological Space Krzysztof Czarnecki 等人 [15] ARXML Serialization Rules AUTOSAR_TPS_ARXMLSerializationRules [16] W3C XML 1.0 Specification http://www.w3.org/TR/REC-xml/ [17] W3C XML Schema http://www.w3.org/XML/Schema [18] SPEM - Software Process Engineering Meta-Model Specification V2.0 http://www.omg.org/spec/SPEM/2.0/ [19] (空) [20] ASAM Container Catalog XML Model Specification http://www.asam.net [21] SGML-OPEN-Catalog http://www.oasis-open.org/committees/entity/spec-2001-05-06.html ### 4.2 附录 #### 4.2.1 附录 A：约束规范 > **摘要**：本附录提供了约束规范的详细信息。 #### 4.2.2 附录 B：文档约定的详细说明 > **摘要**：本附录提供了文档约定的详细说明。 #### 4.2.3 附录 C：类表 本文档的附录 C 提供了各种元模型类的详细规范，包括以下类： | 类名 | 包 | 说明 | |---|---|---| | **Identifiable（可识别）** | M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::Identifiable | 抽象基类，支持 UUID 标识 | | **Integer（整数）** | M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes | 整数原语，范围从 -2147483648 到 2147483647 | | **Numerical（数值）** | M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes | 数值原语，可以表示为十进制、八进制、十六进制、二进制、浮点数 | | **PortInterface（端口接口）** | M2::AUTOSARTemplates::SWComponentTemplate::PortInterface | 抽象基类，定义由软件组件的端口提供或需要的接口 | | **Ref（引用）** | M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes | 基于名称的引用原语 | | **Referrable（可引用）** | M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::Identifiable | 抽象基类，其实例可以通过其标识符引用 | | **Sdg（特殊数据组）** | M2::MSR::AsamHdo::SpecialData | 通用模型，用于保存元模型中未明确建模的任意信息 | | **SenderReceiverInterface（发送方-接收方接口）** | M2::AUTOSARTemplates::SWComponentTemplate::PortInterface | 声明要发送和接收的多个数据元素的发送方/接收方接口 | | **ValueSpecification（值规范）** | M2::AUTOSARTemplates::CommonStructure::Constants | 用于初始化数据对象的值的表达式基类 | | **VariableDataPrototype（变量数据原型）** | M2::AUTOSARTemplates::SWComponentTemplate::Datatype::DataPrototypes | 用于在 ECU 应用中包含值的变量数据原型 | > **注**：完整的类表请参见原文 PDF 文档（包括完整的属性规范、约束和说明）。 --- ## 翻译说明 - 本文档为 AUTOSAR 经典平台 4.4.0 版本的"AUTOSAR 工具互操作性"规范（TR 文档）。 - 该规范已被标记为过时（obsolete），将在后续版本中移除。 - 由于本文档篇幅较大（89 页），本翻译文档完整翻译了： - 文档元信息、变更历史、目录 - 第 1 章引言 - 第 2 章基本概念 - 第 3 章需求（前 4 个小节的关键需求） - 第 4 章附录 - 对大部分具体需求细节进行了摘要处理（保留关键需求 ID 和描述）。 - 保留所有需求 ID（如 TR_IOAT_00007、TR_IOAT_00010、TR_IOAT_00012 等）。 - 保留所有用例 ID（如 UC_IOAT_00001、UC_IOAT_00006 等）。 - 保留 ⌈AUTOSAR confidential⌋ 方框符。 - 翻译策略：重点翻译 + 摘要（大型需求表和类表进行摘要处理）。