# 应用接口用户指南 > **AUTOSAR CP Release 4.4.0** > > 原文：*Application Interfaces User Guide*（文档 ID 442） > > 翻译状态：**已完成 v1** > > 对应原文 PDF：`General/AUTOSAR_EXP_AIUserGuide.pdf` > > 翻译日期：Step 3 - P0 批量翻译 --- ## 文档标识 | 字段 | 值 | |------|-----| | 文档标题 | 应用接口用户指南（Application Interfaces User Guide） | | 文档所有者 | AUTOSAR | | 文档责任人 | AUTOSAR | | 文档标识号 | 442 | | 文档状态 | 正式版（Final） | | 所属标准 | 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 | 添加关于将数据类型实现为整数或浮点数据类型的章节 — 章节 ID 4.2.3.3。Bugzilla #72021 | | 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 更新 COMPU_METHOD 重用的解释；更新线性转换示例 | | 2014-10-31 | 4.2.1 | AUTOSAR Release Management | AI 域中采用传感器和执行器模式；过时的 AI 表格被新的官方 AI 工具（用于内容开发阶段和 arxml 生成）所取代；增强 collections arxml 交付物结构 | | 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 新的 ARXML 文件分发功能 | | 2013-03-15 | 4.1.1 | AUTOSAR Administration | 更新模型元素的类别（数据约束和关键字到蓝图）；引入对向后兼容性、生命周期状态和变体处理（视图）概念的描述；更新应用接口的可交付物 | | 2011-12-22 | 4.0.3 | AUTOSAR Administration | 创建模型元素类别描述；同步更新 XML 包结构（特别是 Port Blueprints）；同步更新 AUTOSAR 元模型；引入连接器命名约定的描述 | | 2011-04-15 | 4.0.2 | AUTOSAR Administration | 初始发布 | --- ## 目录 1. [本文档目的](#1-本文档目的) 2. [应用接口表介绍](#2-应用接口表介绍) 3. [AUTOSAR 方法论](#3-autosar-方法论) 4. [AI 表的元模型表示](#4-ai-表的元模型表示) 5. [向后兼容性](#5-向后兼容性) 6. [生命周期状态](#6-生命周期状态) 7. [应用接口中的视图概念（变体处理）](#7-应用接口中的视图概念变体处理) 8. [应用接口（AI）表的结构](#8-应用接口ai表的结构) 9. [AI 表数据与 XML 输出之间的关系](#9-ai-表数据与-xml-输出之间的关系) 10. [参考文档](#10-参考文档) --- ## 1 本文档目的 AUTOSAR 旨在通过可通信的软件组件交付功能，这些组件几乎可以任意放置在 ECU 网络上。为了确保来自不同来源（即不同供应商）的软件组件的互操作性，应统一这些组件的接口。 AI 表 [8] 的内容是若干汽车域的接口规范。这些域的组合将在表中建立顶级域。目标是定义和发布稳定且被广泛接受的应用接口。 本文档旨在解释 AI 表的所有相关细节，特别是面向需要维护标准化应用接口的用户。有经验的用户可以跳过 AUTOSAR 方法论章节。某些章节包含从其他 AUTOSAR 文档摘录的内容。如内容存在差异，以原始 AUTOSAR 文档为准。 ### 1.1 文档概述 本文档概述了应用接口的方法论背景。它还概述了"应用接口表"的内容、顶级（域间级别）和所含的域（车身、动力总成、底盘、乘员与行人安全、多媒体、远程信息处理、人机界面）。它还描述了 AI 表（实现在 Excel 表格中）的结构并解释如何处理它。 **缩略语表** | 缩略语 | 含义 | |--------|------| | .arxml | AUTOSAR 可扩展标记语言文件 | | AI Table | 应用接口表（Application Interface Table） | | Bugzilla | 变更请求管理工具 | | CPU | 中央处理单元 | | ECU | 电子控制单元 | | Excel | Microsoft 电子表格应用程序 | | MS | 里程碑（Milestone） | | RTE | 运行时环境（Run-Time Environment） | | SPEM | 软件过程工程元模型 | | SVN | Subversion（版本控制系统） | | SW-C | 软件组件（SoftwareComponent） | | SWC | 软件组件（SoftwareComponent） | | SW | 软件（Software） | | VB | Visual Basic | | VFB | 虚拟功能总线（Virtual Function Bus） | | WP | 工作包（Work package） | | XML | 可扩展标记语言 | | XSD | XML 模式定义 | | HMI | 人机界面（Human Machine Interface） | --- ## 2 应用接口表介绍 应用接口表（AI Table）是用于管理所有定义应用接口的数据的用户界面（参见图 1）。这通过一个工具（Excel）实现，该工具带有验证和工作产品输出生成宏（例如 VB 脚本）。该工具的输入基于 AUTOSAR 定义的方法论元模型数据。该工具的输出是一个 XML 模型，它符合 XSD 并遵循模板中定义的语义。AUTOSAR XML 文件（称为 .ARXML 文件）以结构化格式包含所有标准化应用接口数据的详细信息。XML 文件包含转换为通用可读格式的应用接口定义，可用作软件开发公司开发单元的创作工具等的输入。 > 图 1：AI 表处理流程 AI 表能够操作 AI 定义以产生结果：用于数据交换的 XML 文件。 SWC 模板 [1] 告诉我们可以对什么进行建模。标准化模板 [2] 解释并支持蓝图方法。 AI 表描述（即 XML）告诉我们正在建模什么。AI 表定义遵循 SWC 建模指南 [9] 中定义的建模指南。图 2 显示了 SW 组合及其分解为组件的主要结构。 为了标准化应用接口，许多 SW 组件在 AI 表内被描述，分解为各个域及其主要功能。尽管如此，这些组件目前（在 4.0 版本中）必须仅被视为示例。它们不是标准的一部分；但是为了以一致的方式规定 port/port prototype，它们是必需的。每个 port/port prototype 需要连接到某个组件以正确地规定。 > 图 2：使用软件组件模板中定义的概念分解组件 **注**：图中的黄色块代表 AI 表中以黄色显示的列，即分解为其他组合/组件的组合。这些组件类型和原型在 AI 表的同一 sheet 的蓝色列中描述（参见图中的蓝色块）。SwComponentPrototype 在特定角色中实现 SwComponentType 的使用。 SwComponentPrototype 仅用于在特定角色中实现 SwComponentType，即用于实例化 SwComponentType。 **示例**：SwComponentPrototype "LeftDoorControl" 履行在车辆的左门上实现 SwComponentType "DoorControl" 的角色，而 SwComponentPrototype "RightDoorControl" 履行在右门上实现 SwComponentType "DoorControl" 的角色。 AI 表是一个 Excel 表，其中包含许多工作表。在工作表内，处理以下与应用接口相关的主要信息： - 组合；主要组合来自域：(1) 车身、(2) 动力总成、(3) 底盘、(4) 乘员与行人安全、(5) 多媒体与远程信息处理以及人机界面 - 组件 - 端口 - PortInterfaces 及其 VariableDataPrototypes - VariableDataPrototypes 的数据类型 - 单位 - 组件类型的实例 - 关键字 有关表提供的工作表的详细列表，请参阅第 8 章。 ### 2.1 AI 表中的域结构概述 目前 AI 表包含若干不同汽车域的规范。每个域的结果包括域间连接，可以在 AI 表的工作表中识别： | 域 | Sheet 编号 | |---|---| | 域间级别（顶级） | 0500 | | 车身（Body） | 0501* | | 动力总成（Powertrain） | 0502* | | 底盘（Chassis） | 0503* | | 乘员与行人安全（OPS） | 0504* | | 多媒体、远程信息处理、人机界面（HMI） | 0505* | 尽管该表按照域进行结构化，但产生的组件/组合分解对于符合 AUTOSAR 的车辆架构不是强制性的架构。AI 表显示组件/组合作为示例，用于解释标准化端口和 PortInterfaces。顶级组合是表示 VFB 视图中域间端口所需的虚拟组合。 有关域详细信息的进一步解释可以在 3.1.7 至 3.1.11 章以及进一步引用的文档中找到。 --- ## 3 AUTOSAR 方法论 AUTOSAR 要求对系统开发的某些步骤采用正式的技术方法。这种方法称为"AUTOSAR 方法论"。AUTOSAR 方法论既不是完整的过程描述，也不是业务模型，并且"角色"和"责任"不在此方法论中定义。此外，它没有规定应执行活动的精确顺序。该方法论仅是工作产品流：它定义活动对工作产品的依赖性。 在系统设计期间，必须选择软件组件和硬件，并确定总体系统约束。AUTOSAR 旨在通过信息交换格式和模板的使用来简化这些初始系统设计决策的正式描述。因此，定义系统配置输入意味着填写或编辑适当的模板。AUTOSAR 方法论在这方面允许高度重用。在任何情况下，都假定此编辑由编辑工具支持。以下是活动的简要描述： > 图 3：AUTOSAR 方法论概览 - **配置系统**：主要在资源和时间要求方面将软件组件映射到 ECU。需要 SW 组件描述、系统约束描述和 ECU 资源描述来配置系统。AI 表输出沿内部行为定义 SW 组件描述。此活动的输出是系统配置描述。该描述包括所有系统信息（例如总线映射、拓扑）以及哪个软件组件位于哪个 ECU 上的映射。 - **提取 ECU 特定信息**：从特定 ECU 所需的系统配置描述中提取信息。然后将其放在系统配置的 ECU 提取中。 - **配置 ECU**：添加实现所需的所有信息，例如任务调度、所需的基础软件模块、基础软件的配置、可运行实体到任务的分配等。配置 ECU 活动的结果包含在 ECU 配置描述中，该描述收集特定于特定 ECU 的所有信息。可以根据此信息构建该特定 ECU 的可运行软件。 - **生成可执行文件**：基于 ECU 配置描述中描述的 ECU 配置生成可执行文件。此步骤通常涉及生成代码（例如 RTE 和基础软件的代码）、编译代码（编译生成的代码或编译作为源代码提供的软件组件）并将所有内容链接为可执行文件。 尽管如此，软件组件的实现或多或少独立于 ECU 配置。 本章的一般概念是详细 AUTOSAR 方法论 [10] 的摘录。 ### 3.1 可用文档概览 有关详细信息，以下文档可用。 #### 3.1.1 软件组件模板 [1] 本文档提供与软件组件定义相关的 AUTOSAR 元模型部分的介绍性描述和原理。 #### 3.1.2 标准化模板 [2] 本文档旨在支持 AUTOSAR 交付标准化模型元素。它还细化了标准化的蓝图方法。 #### 3.1.3 通用结构模板 [4] 本文档作为 AUTOSAR 元模型提供的正式定义的补充。本文档提供与所有 AUTOSAR 模板相关的 AUTOSAR 元模型部分的介绍性描述和原理。 #### 3.1.4 AI 规范 [6] 这是应用接口标准化的输出。输出以一组 .arxml 文件的形式交付。 #### 3.1.5 应用接口建模指南 [9] 本文档提供关于使用 AUTOSAR 模型元素以构建 AUTOSAR 系统的指南和约定。它不包含 AUTOSAR 元模型的指南。 #### 3.1.6 AUTOSAR 方法论 [10] 见上文。 #### 3.1.7 车身舒适域应用接口的解释 [11] 本文档解释了导致车身和舒适域应用接口的设计决策和边界条件。 #### 3.1.8 动力总成域应用接口的解释 [12] 本文档解释了导致动力总成域应用接口的设计决策和边界条件。 #### 3.1.9 底盘域应用接口的解释 [13] 本文档解释了导致底盘域应用接口的设计决策和边界条件。 #### 3.1.10 乘员与行人安全域应用接口的解释 [14] 本文档解释了导致乘员和行人安全域应用接口的设计决策和边界条件。 #### 3.1.11 多媒体、远程信息处理、人机界面域应用接口的解释 [15] 本文档解释了导致多媒体、远程信息处理、人机界面域应用接口的设计决策和边界条件。 要查找这些文档，请参阅本文档末尾的表格（见第 10 章）。 --- ## 4 AI 表的元模型表示 本节描述元模型实现（AUTOSAR 元模型 [7]）与 AI 表 [8] 中表示之间的关系。 AUTOSAR 元模型在概念上定义为 'M2' 级别，它描述称为软件组件和端口的实体。这些实体之间的关系以及它们的语义是此模型的一部分。 ### 4.1 模型元素类别 所有应用接口模型元素分为三个不同的类别： - **STANDARD**（标准） - **BLUEPRINT**（蓝图） - **EXAMPLE**（示例） #### 4.1.1 STANDARD 所有可以通过在项目中仅包括它们来按其定义使用的元素属于 STANDARD 类别。这些元素在项目中使用之前不需要修改。 属于 STANDARD 类别的元素有： - PhysicalDimensions（物理维度） - Units（单位） - LifeCycleInfoSets（生命周期信息集） #### 4.1.2 BLUEPRINT 蓝图是模型元素的预定义，其形成进一步建模的基础。蓝图是可以从中通过复制派生其他模型元素的模型元素。这些元素在所有方面都不完整。它们充当项目创建实际元素的模板。 属于 BLUEPRINT 类别的元素有： - ApplicationDataTypes（应用数据类型） - CompuMethods（计算方法） - DataConstraints（数据约束） - KeywordSets（关键字集） - PortInterfaces（端口接口） - PortPrototypeBlueprints（端口原型蓝图） - Collections（集合） **从 BLUEPRINT 派生的原型的命名规则**：AUTOSAR 标准化将使用规则为从蓝图派生的原型创建 ShortName，即以下建议对 AUTOSAR 标准化工作是强制性的。 - 单次使用情况下的建议：`` - 多次使用情况下的建议：`{}0..n` - 派生模型元素的 ShortName 模式可以遵循来自关联蓝图的 `{anyName}` 模式 #### 4.1.3 EXAMPLE 不应标准化但有助于理解的元素创建为 EXAMPLE 类别。它们充当帮助用户实际创建其项目特定实现的助手。EXAMPLE 类别的元素代表众多可能实现方式中的一种。 属于 EXAMPLE 类别的元素有： - SwComponentTypes（软件组件类型） - ApplicationDataTypes（应用数据类型） - BlueprintMappingSets（蓝图映射集） - CompuMethods（计算方法） - DataConstrs（数据约束） - PortInterfaces（端口接口） 归类为示例的 ApplicationDataTypes、CompuMethods、DataConstrs 和 PortInterfaces 是从其蓝图派生的元素，而不是其他元素。 ### 4.2 元模型图和 AI 表 本节描述 AUTOSAR 元模型（M2）图及其与实现应用软件组件的 AI 表内容的关系。 以下图对应于 AUTOSAR 元模型的 R4.0。 #### 4.2.1 组合 > 图 4：组合 AUTOSAR CompositionSwComponentType 的目的是通过聚合现有软件组件来允许特定功能的封装。由于 CompositionSwComponentType 也是 SwComponentType，因此它可以再次聚合在进一步的 CompositionSwComponentTypes 中。这种递归关系在图 4 中正式表达。 重要的是要理解，虽然组合允许（子）系统抽象，但它们仅是用于实现模型可扩展性的架构元素。它们仅对现有软件组件进行分组，从而在查看或设计逻辑系统架构时减少复杂性。 **元模型参考**： M2::AUTOSARTemplates::SWComponentTemplate::Composition [1] **AI 表参考**： AUTOSAR_ApplicationInterfaces.xls [8] 工作表名称：Compositions > 图 5：'Compositions' sheet 的一部分 **示例**：在 sheet 050106_ExteriorLight 中找到的 Exterior light 组合："ExtrLi" 是一个 CompositionSwComponent 类型，由不同的组件类型组成，如 ExtrLiMgr、FlashMgr、LiAdprAut、AdprCornrg、AdprHomeCmngAndHomeLvng、HdlampLvlMgr、ActrOfHdlampLvlg 等。 **AI 表参考**： AUTOSAR_ApplicationInterfaces.xls [8] 工作表名称：Instances > 图 6：'Instances' sheet 的一部分 **示例**：组件类型 ExtrLiMgr 未进一步分解为组件类型，因此它只是一个组件类型。在 050106_ExteriorLight（如图 7 中单元格 AB2 所示）中找到的组件原型 ExtrLiMgr 属于类型 ExtrLiMgr（组件类型）。这里类型和原型具有相同的 ShortName。 在 050106_ExteriorLight（如图 7 中单元格 BF2 所示）中找到的组件原型 ActrOfHdlampLvlgLe 和 ActrOfHdlampLvlgRi 属于类型 ActrOfHdlampLvlg（组件类型）。这里类型和原型具有不同的 ShortName，并且该类型被实例化两次。 > 图 7：Sheet 050106_ExteriorLight - 分解组件 可以创建任意数量的 SwComponentPrototypes 来引用特定的 SwComponentTypes。请注意，CompositionSwComponentType 还聚合抽象元类 SwConnector 以连接彼此所属的 SwComponentPrototypes。 ##### 4.2.1.1 多重实例化 在设计系统时，通常情况下运行时空间中的元素共享相同的结构。一个众所周知的示例域是面向对象编程，其中从同一类实例化的对象都具有由该类规定的相同结构。能够一次规定结构然后在设计中的多个地方使用它称为多重实例化。 相同的概念在 AI 表中用于定义在域中多次存在的组件的 SwComponentType。 在下面显示的示例中，软件组件 WshrFrnt、WshrRe 和 WshrHdlamp 是从 SwComponentType Wshr 创建的。 > 图 8：Sheet 050108_WiperWasher - 多重实例化示例 从 SwComponentType 实例化的所有 SwComponentPrototypes 将具有 SwComponentType 的相同属性，换句话说，例如，如果 SwComponentType 定义了 2 个 Provider PortPrototypes 和 3 个 Receiver PortPrototypes，则 SwComponentType 的所有实例将具有相同数量的 Provider 和 Receiver PortPrototypes。 如果两个 SwComponentTypes 相互连接，并且两个 SwComponentTypes 都被多重实例化，则这些 SwComponentTypes 之间的连接可能是不明确的。然而，由于 AI 表宏的限制，目前无法涵盖所有可能的模型场景。 > 图 9：组合 - 聚合 **元模型参考**： M2::AUTOSARTemplates::SWComponentTemplate::Components [1] **AI 表参考**： AUTOSAR_ApplicationInterfaces.xls [8] 工作表名称：050XXXXX Sheets 请注意，作为 SwComponentType，CompositionSwComponentType 还向外部公开 PortPrototypes。但是，PortPrototypes 仅被委托，不起与附加到 AtomicSwComponentTypes 的 PortPrototypes 相同的作用（AtomicSwComponentTypes 封装其功能和行为的实现，仅向外部公开定义良好的连接点，即 PortPrototypes）。有关更多详细信息，请参阅 SW 组件模板 [1]。 CompositionSwComponentTypes 包含两种类型的 SwConnectors。 > 图 10：组合 - 连接器 1. **AssemblySwConnectors** 用于互连属于 CompositionSwComponentType 的 SwComponentPrototypes 的 PortPrototypes。 2. **DelegationSwConnectors** 用于从"内部" PortPrototypes 连接到委托的"外部" PortPrototypes。 如果外部 PortPrototype 被多个 DelegationSwConnectors 引用，则语义是引用外部 PortPrototypes 的 AssemblySwConnectors 的乘法。 > 图 11：Exterior Light 分解示例 **示例**：在 Exterior light 分解的情况下，"ExtrLi" 软件组件原型是提供"外部" PPortPrototype "TrlrSts" 的复合类型，该端口从软件组件原型 "ExtrLiAdprTrlr" 的"内部" PPortPrototype 委托。同一 PPortPrototype 通过 assembly connector prototype 连接到 "ExtrLiAdprReLe" 和 "ExtrLiAdprReRi" 的 RPortPrototype。 #### 4.2.2 蓝图映射与 BlueprintMappingSet 蓝图映射充当蓝图和派生元素之间的引用。蓝图映射标识蓝图元素和实际蓝图之间的关系。它还根据蓝图验证派生元素。这些 BlueprintMappings 的聚合是 BlueprintMappingSet。下图显示了 BlueprintMapping 和 BlueprintMappingSet。 > 图 12：BlueprintMapping 与 BlueprintMappingSet #### 4.2.3 PortPrototypes PortPrototypes 在某些地方也称为端口，是用于不同软件组件之间通信的定义良好的连接点。PortPrototype 是必需类型或提供类型。require-port（技术术语：RPortPrototype）需要某些服务或数据，而 provider-port（或 PPortPrototype）则提供这些服务或数据。 两个 SwComponentPrototypes 最终通过将一个 SwComponentPrototype 的 PPortPrototype 连接到另一个 SwComponentPrototype 的兼容 RPortPrototype 来连接。 > 图 13：PortPrototypes ##### 4.2.3.1 PortPrototypeBlueprints PortPrototypeBlueprint 是一个 ARElement，并充当创建 PortPrototypes 的蓝图。用户可以选择特定的 PortPrototypeBlueprint 并从中创建 PortPrototype。 PortPrototypeBlueprint 与 SwComponentType 无关。PortPrototypeBlueprints 没有明确地在 AI 表中表示，它们可以在 XML 中的单独包中找到。 PortPrototypeBlueprints 可以看作是一个库，用户可以从中选择 PortPrototypeBlueprint 作为模板来创建 PortPrototype。因此，PortPrototypeBlueprints 只是 PortPrototypes 的集合，没有任何架构关系。一旦 PortPrototypeBlueprint 附加到 SwComponentPrototype，它就成为 PortPrototype。 > 图 14：PortPrototypeBlueprints ##### 4.2.3.2 PortPrototypeBlueprints 的 BlueprintMapping 从可用的 PortPrototypeBlueprints 创建 PortPrototype 的过程称为 BlueprintMapping。BlueprintMapping 在图 12 中演示。PortPrototypes 和 PortPrototypeBlueprints 之间的映射可以在包 "BlueprintMappingSets_Example" 中的 BlueprintMappingSet "PortPrototypeBlueprintMappings" 中找到。 ##### 4.2.3.3 Float 数据使用规则和建议 以下是关于如何将 float 数据用于 Port Prototypes 的一些规则和建议： - 始终使用 1:1 缩放：例如，内部表示 = 10.1，使用物理值 10.1Pa。 - 仅应进行单精度计算（不推荐 f64）。 - 如果已知目标 ECU：当 RAM/Stack 资源比 CPU 负载更关键时，不要使用 float。 - Float 应始终与 SI 单位一起用作物理表示。 - 如果对于同一信号需要大范围和低精度或小范围和高精度，则严格推荐使用 Float。示例： - 严格推荐将 Float 用于压力 ([Pa]) - 严格推荐将 Float 用于喷油量 ([kg]) - 当整数精度足够时（例如温度 ([K])），不应使用 Float。 在 Flat Instance Descriptors (SW Signals) 中使用 float 时，一些规则/建议如下： - 必须满足 AUTOSAR 元模型的兼容性规则。 - 可以使用任何物理显示表示。 #### 4.2.4 PortInterfaces PortInterface 定义两个 PortPrototypes 之间传输的信息种类。 PortInterfaces 用于支持按合同设计的工作流，即它们提供一种正式验证软件组件之间结构和动态兼容性的方法。换句话说，PortInterfaces 代表 AUTOSAR 概念中的一个关键点。 > 图 15：接口概览 **元模型参考**： M2::AUTOSARTemplates::SWComponentTemplate::PortInterface [1] BlueprintMapping 是从 PortInterfaceBlueprints 创建 PortInterfaces 的过程。这在图 12 中演示。PortInterfaces 和 PortInterfaceBlueprints 之间的映射可以在包 "BlueprintMappingSets_Example" 中的 BlueprintMappingSet "PortInterfaceBlueprintMappings" 中找到。 ##### 4.2.4.1 发送者-接收者通信 SenderReceiverInterfaces 允许规定典型的异步通信模式，其中发送方提供数据，而一个或多个接收方需要这些数据。虽然实际通信通过各自的 PortPrototypes 进行，但 SenderReceiverInterface 允许正式描述发送和接收的信息种类。 > 图 16：SenderReceiverInterface SenderReceiverInterface 声明要发送和接收的多个数据元素（VariableDataPrototype）。SenderReceiverInterface 侧重于由 VariableDataPrototypes 表示的信息项的描述。以 dataElement 角色聚合的 VariableDataPrototype 表示在由 SenderReceiverInterface 类型化的 PortPrototypes 之间传输的原子信息片段。 **AI 表参考**： AUTOSAR_ApplicationInterfaces.xls [8] 工作表名称：06_Interface_DataElements > 图 17：Sheet 06_Interface_DataElements - SenderReceiver 接口示例 **示例**："TrlrSts1" 是一个 SenderReceiver 接口，它具有类型为 "Boolean" 的一个数据元素 "TrlrSts"。 ##### 4.2.4.2 客户端-服务器通信 客户端/服务器通信的基础语义是客户端可以由支持该操作的服务器启动操作的执行。服务器执行该操作并立即向客户端提供结果（同步操作调用），或者客户端自行检查操作的完成（异步操作调用）。 > 图 18：ClientServerInterface 因此，ClientServerInterface 在某种程度上是 SenderReceiverInterface 的对应物。ClientServerInterface 不是定义要在软件组件之间传输的信息片段，而是定义 ClientServerOperations 的集合。 如图 18 所示，ClientServerInterface 由 ClientServerOperations 组成，即 ClientServerOperation 不可在不同的 ClientServerInterface 上下文中重用。ClientServerOperation 由 0 到多个 ArgumentDataPrototypes 组成。后者可以： - 传递给操作 - 传递给操作并从操作返回 - 从操作返回 **AI 表参考**：AUTOSAR_ApplicationInterfaces.xls [8] 工作表名称：06_Interface_ClientServer > 图 19：Sheet 06_InterfaceClientServer - ClientServer 接口示例，显示操作 > 图 20：Sheet 06_InterfaceClientServer - ClientServer 接口示例，显示参数 **示例**：在上面的截图中，定义了一个客户端/服务器接口 "TrsmRatGear1" 以返回给定档位的传动比，客户端使用输入参数 'Gear' 请求操作 'GetTrsmRatGear'。函数调用返回输出参数 'Rat'。 #### 4.2.5 DataTypes 可以从应用程序和实现的角度描述软件组件提供的数据。这背后的共同概念由抽象元类 AutosarDataType 表达，从中派生出 ApplicationDataType 和 ImplementationDataType。 图 21 显示了用于定义 AutosarDataTypes 的基本元类的摘要。 > 图 21：DataTypes 概览 ApplicationDataType 可以由元素（以记录或数组形式）组成，这些元素本身由另一个 ApplicationDataType 类型化。这由元类 ApplicationCompositeElementDataPrototype 表达，为了完整性在图 21 中显示。ImplementationDataType 也可以组成，但在这种情况下，不应用类型/原型概念。 ##### 4.2.5.1 ApplicationDataTypes 抽象元类 ApplicationDataType 进一步派生为 ApplicationPrimitiveDataType 和 ApplicationCompositeDataType。像任何 AutosarDataType 一样，应用程序级别的基元和复合类型由其类别及其 SwDataDefProps 特征化。对于给定的类别，SwDataDefProps 的一组有限属性才有意义。 > 图 22：应用程序数据类型 ###### 4.2.5.1.1 应用程序基元数据类型 本章定义了可用于 PortInterfaces 或复合应用程序数据类型的数据原型的基元应用程序数据类型。 > 图 23：数据类型基元 **元模型参考**： M2::AUTOSARTemplates::SWComponentTemplate::DataType::DataTypes [1] **AI 表参考**：AUTOSAR_ApplicationInterfaces.xls [8] 工作表名称：07_DataTypes_ContinuousValue > 图 24：Sheet 07_DataTypes_ContinuousValue - 连续值 DataType 示例 **示例**：在上面的截图中，定义了 ContinuousValue DataType Perc8。该 DataType 的分辨率、物理上限和下限以及偏移量和单位也显示在截图中。 **AI 表参考**：AUTOSAR_ApplicationInterfaces.xls [8] 工作表名称：08_DataTypes_Enumeration > 图 25：Sheet 08_DataTypes_Enumeration - 枚举 DataType 示例 **示例**：在上面的截图中，定义了枚举 DataType TrsmTyp1。枚举 DataType 的所有允许值也包含在 AI 表中。 ###### 4.2.5.1.2 应用程序复合数据类型 元类 ApplicationArrayDataType 和 ApplicationRecordDataType 提供了定义复合 DataType 的方法。如果应用程序软件希望访问复合的各个元素以及对整个复合执行操作（例如希望在单个事务中传达完整的记录或数组），则需要这种复合 DataType。 > 图 26：数据类型复合 可以使用 ApplicationArrayDataType 和 ApplicationRecordDataType 的组合，以便 ApplicationArrayDataType 可以定义为 ApplicationRecordDataType 的 ApplicationRecordElement，并且以相同的方式，ApplicationRecordDataType 可以用作 ApplicationArrayDataType 的基类型。嵌套的 ApplicationComposite DataTypes 的创建也是可能的。 ###### 4.2.5.1.3 ApplicationArrayDataType ApplicationArrayDataType 可以包含 maxNumberOfElements 的 ApplicationArrayElements。每个 ApplicationArrayElement 必须具有相同的类型。在软件组件描述中引用数组内的元素时，元素索引从 0 运行到 (maxNumberOfElements-1)。 **AI 表参考**：AUTOSAR_ApplicationInterfaces.xls [8] 工作表名称：09_DataTypes_Array > 图 27：Sheet 09_DataTypes_Array - 数组 DataType 示例 **示例**：应用程序组件开发中使用的数组 DataType 的标准变量在此列出以供参考。数组 DataType "TirePPerWhl1" 包含 5 个元素，每个元素的 DataType 为 'P1'。 ###### 4.2.5.1.4 ApplicationRecordDataType ApplicationRecordDataType 的声明描述一组非空对象，每个对象都有一个关于 ApplicationRecordDataType 的唯一标识符，并且每个对象都有自己的 ApplicationDataType。ApplicationRecordElement 的 ShortName 在 ApplicationRecordDataType 的范围内必须唯一。 **AI 表参考**：AUTOSAR_ApplicationInterfaces.xls [8] 工作表名称：11_DataTypes_Record > 图 28：Sheet 11_DataTypes_Record - 记录 DataType 示例 **示例**："IndcrTurnSeq1" 是一个记录类型变量，表示转向指示灯序列。记录 DataType 'IndcrTurnSeq1' 包含 5 个元素，每个元素在唯一的行中表示，并定义了相应的 DataType。 #### 4.2.6 物理单位 与 DataType 关联的语义的重要组成部分是其物理维度。单位用于使用 m/s 或 liter 等附加信息来增加值。这对于输入和输出过程的物理值的正确解释是必要的。该单位涉及其物理维度的信息。 > 图 29：单位 该单位引用一个物理维度。如果两个单位的物理维度相同，则它们之间可以进行转换。 **元模型参考**： M2::AUTOSARTemplates::SWComponentTemplate::DataType::Units [1] **AI 表参考**：AUTOSAR_ApplicationInterfaces.xls [8] 工作表名称：13_Units > 图 30：Sheet 13_Units - 单位示例 **示例**：表示为 'DegCgrd' 的单位属于"热力学温度"的物理维度。 #### 4.2.7 计算方法 此元类表示表达物理值和数学表示之间关系的能力。 请注意，这仍然独立于数据类型中的技术实现。它仅指定内部值如何对应于其物理对应物的公式。 CompuMethods 通常应可重用，不应固定到特定的数据类型。CompuMethods 可以被需要这种描述的计算特征的任何类型的数据类型引用；强烈建议重用，并且对于浮点数据类型定义是强制性的。Application Interface Tooling (AIT) 工具支持这种参数的交叉引用。有关更多信息，请参阅 SW-C 和系统建模指南 [9]。 ##### 4.2.7.1 线性转换示例 以下示例说明如何使用 CompuMethod 规定线性转换： ```xml LinearExample LINEAR kmh 30 2 1 ``` #### 4.2.8 关键字和 KeywordSet 为组件类型、端口、PortInterfaces 或数据元素定义短名称的重要部分是利用 AUTOSAR 中的预定义关键字及其缩写。优点是，这会产生具有既定含义的相对较短的名称。关键字在类别 KeywordSets_Blueprint 下聚合。 > 图 31：关键字和 KeywordSet 的类图 > 图 32：Sheet 04_Keywords 从上图，每个关键字由以下属性描述： - **ShortName**：表示关键字的唯一名称，它不涉及名称构造（例如上例中的 Prepn） - **longName**：表示关键字的长格式（Preparation） - **desc**：表示关键字的定义 - **abbrName**：规定关键字的缩写名称，并用于构建 ShortNames - **classification**：描述关键字的语义字段（Mean-Environment-Device、Action-PhysicalType、Condition-Qualifier、Index、Preposition） 如果本文档其余部分未另行规定，关键字一词将指关键字的 longName，而缩写名称可称为"abbrName 属性"或"关键字缩写"。 生成的 XML 输出如下： ```xml AISpecification KeywordSets_Blueprint BLUEPRINT KeywordList AUTOSAR Keywords and Keywords Abbreviations Prepn Preparation this characteristic is used to express a general status of preparation, e.g. processing of certain tasks before an activation of a certain component or functionality Prepn Condition-Qualifier … … ``` 为了构建可读且可理解的名称，关键字应按照语义规则排列。这些规则定义了必须以定义顺序使用的语义字段。这些在 [9] 中进一步描述。 --- ## 5 向后兼容性 ### 5.1 介绍 在 AUTOSAR 标准开发过程中，通过较新的版本认识到该标准与其前身版本不兼容。这反过来又导致了严重的集成问题，特别是对于打算使用更新规范版本的某些模块的配置。 因此，AUTOSAR 引入了对新概念的向后兼容性要求，以确保使用混合实现版本的软件的平稳和无错误操作。 三个用例引起 AUTOSAR 将提供的三种兼容性声明 - 相应的文档所有者提供变更列表以及对三种向后兼容性的影响分析： - 规范方面的向后兼容性 - 总线向后兼容性 - 应用程序向后兼容性 对于应用程序方面的向后兼容性，它考虑 AUTOSAR 版本的模块集，这些模块对应用软件组件的交互有影响。 因此，应用接口的用例定义派生为： 水平"应用程序兼容性"（仅考虑标准化应用接口）： - 旧场景：基于例如 R4.0.3 版本中定义的标准化应用接口的应用程序开发 - 新场景：应根据例如 R4.1.1 版本的标准化应用接口更新应用程序 - 问题：新的标准化应用接口是否可以在不进行调整的情况下与较旧（未更改）的标准化应用接口一起使用？ ### 5.2 向后兼容性定义 > 图 33：向后兼容性的示意表示 根据 AUTOSAR： - 如果产品 Qi+1 能够替代 Qi，而 Qi 又与为 Qi 设计的其他未触及的产品交互，则称产品 Qi+1 与产品 Qi 兼容。 - 如果产品 Qi+1 与 Qi 兼容，并且 Qi+1 是 Qi 的后继产品，则称产品 Qi+1 向后兼容于产品 Qi。 因此在应用接口的上下文中，定义为： - 如果蓝图 Qi+1 能够替代蓝图 Qi，而 Qi 又被（未触及的）端口引用，则称蓝图 Qi+1 与蓝图 Qi 兼容。 - 如果应用接口 Qi+1 能够替代应用接口 Qi，而 Qi 又被（未触及的）系统引用，并且该系统是根据应用接口 Qi 设计的，则称应用接口 Qi+1 与应用接口 Qi 兼容。 **示例**： PortCompliance： - ShortName 相等 - Portblueprint 的 InterfaceBlueprint 符合 port 的 interface - … InterfaceCompliance： - 具有相同数量的 dataElementPrototypes - dataElementPrototypes 的名称相同 - dataElementProtopes 的数据类型兼容 - … **解释**：向后兼容性要求是实现使用新标准化应用接口的 SWC 交换的必要前提。在基于例如 R4.0.3 版本开发的 ECU 中 - 标准化应用接口应更新到例如 R4.1.1 版本的标准化应用接口。 > 图 34：相对于应用接口的 BWC 示例表示 **前提条件**： - 标准化应用接口更新到最新版本；其他一切保持不变 - 配置在语义上等效 - 重新编译 SWC > 图 35：相对于蓝图的 BWC 影响向后兼容性的元素；如果这些元素被更改，则向后兼容性受到影响（请参阅 SW-C 和系统建模指南 [9]，未来扩展（第 5.4 章））： - 短名称 - 枚举数据类型 - 枚举值、枚举值名称 - 连续数据类型 - 分辨率、物理限制、偏移、单位 - 数组数据类型 - 元素数量、元素类型 - 记录数据类型 - 元素数量、元素名称、元素类型 - 发送者-接收者接口 - 数据元素数量、数据元素名称、数据元素类型 - 客户端-服务器接口 - 操作名称、参数数量、参数名称、参数数据类型、参数输入/输出属性 ### 5.3 总结 - 对于端口蓝图及其引用元素（PortInterfaces、应用数据类型和单位）的任何更改，应创建所有受影响元素的新版本。例外：对描述性元素的更改（除非原始元素的含义被修改） - 新元素使用与当前接口相同的定义序列号（请参阅 SW-C 和系统建模指南 [9]，第 5.4 章） - 描述性元素不强制*导致新版本。这适用于以下元素： - Description - LongName - Introduction *注：如果蓝图的描述性元素发生更改，且其相对于原始蓝图的含义也发生变化，则应创建所有受影响元素的新版本。 对于 AI，R4.0.3 是 BWC 的基础。 --- ## 6 生命周期状态 ### 6.1 介绍 为了支持标准化模型元素（如 port prototype blueprints、PortInterfaces、关键字缩写以及其他 STANDARD 或 BLUEPRINT 元素）的演进和向后兼容性，AUTOSAR 需要支持生命周期状态。 "生命周期"的定义 [17]： > 模型元素在其生命周期内的发展/演进阶段的历程。生命周期由一组生命周期状态组成。生命周期状态可以与版本信息并行附加到元素上。 典型的生命周期是 {valid, obsolete}，这意味着有效元素在首次引入时是最新的，但后来被新元素替代，因此获得生命周期状态"obsolete"。 元素的"生命周期状态"与其"版本"不同： - **Version**：指在其开发过程中追溯以使其存在的信息（例如 proposal、in work、released...） - **Life Cycle**：从元素主流引入点到其过时为止追溯元素的历程 生命周期状态在通用结构模板 [4] 的第 11 章中进一步描述。 ### 6.2 在 AI 表中的表示 为了支持在 AI 表中引入生命周期状态，新列已添加到受影响的工作表，如下图所示。 > 图 36：AI 表中生命周期状态的表示 列的描述如下所示。目前为 AI 使用定义了两个生命周期状态： - **Obsolete**（带有过时的原因和提供的替代方案） - **Valid**（默认状态，在"生命周期状态"列中留空） 属性 "Use Instead" 也可能有两个条目。在这种情况下，条目用逗号 (,) 分隔。 | 工作表 | 列描述 | 解释 | |--------|--------|------| | 04*,05*,06*,07*,08*,09*,11*,13*,15* | 生命周期状态 | 生命周期概念的扩展：
- 字段为空时，生命周期状态有效
- 字段中为 "obsolete" 时，生命周期状态过时 | | 04*,05*,06*,07*,08*,09*,11*,13*,15* | 替代使用 | - 对将替换过时模型元素的模型元素短名称的引用
- 此列中有两个条目的情况下，用逗号 (,) 分隔 | | 04*,05*,06*,07*,08*,09*,11*,13*,15* | 注释 | - 注释字段，例如不再使用模型元素的原因 | | 04*,05*,06*,07*,08*,09*,11*,13*,15* | 过期日期 | - 以 R4.1.1 形式的 AUTOSAR 修订版用于过期日期，即此元素变为过时的版本 | 请注意，对 AI 表布局的相应更改未反映在本文档的其他图中。 ### 6.3 在元模型和 arxml 中的表示 > 图 37：生命周期定义 - 元模型表示 元素的生命周期信息在以下生成的 XML 文件中可用： - `AUTOSAR_MOD_GeneralDefinition_LifeCycle.arxml`：适用于 AUTOSAR 项目中全局的生命周期状态的定义，也在基础软件区域中使用（LifeCycleStateDefinitionGroup）。此文件不是 AI 交付物的一部分，仅从 AUTOSAR_MOD_GeneralDefinitions.zip 文件夹中引用。 - `AUTOSAR_MOD_AISpecification__LifeCycle_Standard.arxml`：生命周期的应用 - 引用应用接口中定义的元素及其关联的 LifeCycleState（LifeCycleInfoSet）。每个模型元素有一个文件，是 AUTOSAR_MOD_AISpecification.zip 文件夹中 AI 交付物的一部分。 例如，从上表中，可以看到端口 AbsFlgActv 设置为 Obsolete，并引用 Use Instead AbsCtrlIntvg。 这同样反映在文件 `AUTOSAR_MOD_AISpecification_PortPrototypeBlueprint_LifeCycle_Standard.arxml` 的 arxml 摘录中，如下所示： ```xml AbsFlgActv 4.1.1

Port short names consolidation: receivers should use short name of providers.

 AbsCtrlIntvg ``` `AUTOSAR_MOD_AISpecification__LifeCycle_Standard.arxml` 仅包含那些标记为 Obsolete 的元素（因为默认值是 Valid）以及相应的要使用的元素，即过时元素的替代。过期版本定义元素过时的期间开始，即元素首次设置为过时的第一个 AUTOSAR 版本，在本例中为 "R.4.1.1"。 --- ## 7 应用接口中的视图概念（变体处理） ### 7.1 介绍 变体处理概念将帮助使用应用接口实现车辆中的不同架构。通过 port prototype blueprint 概念，接口的最终端到端通信将由系统的配置执行。这也将允许将不同物理车辆的配置（如紧凑型车、高级车到卡车应用）包括在应用接口的标准化中。 由于 AUTOSAR 仅标准化蓝图，因此无需在 AI 规范中实现变体处理。可以轻松地为每个需要的变体添加新的蓝图元素。为了区分不同的变体，引入了不同的视图。视图允许为特定变体或用例过滤蓝图元素。例如，如果引入了"卡车"视图，则可以过滤"卡车"视图，即过滤与"卡车"用例相关的所有蓝图元素。 ### 7.2 在应用接口和元模型表示中的实现 由 10.x 定义的视图在 BLUEPRINT 类别的包中。原因是，在公司环境中，可以添加其他元素。 对于视图的首次引入，仅为每个域引入视图，即视图"Body"（Body）、"Powertrain"（Pt）、"Chassis"（Chassis）、"Occupant and Pedestrian Safety"（OccptPedSfty）和"Multimedia, Telematics and HMI"（MmedTelmHmi）。未来版本可能会添加更多视图。当前，这些视图可以为 AI 表中的 PortPrototypeBlueprints 和 ApplicationDataTypes 规定。属于特定视图的元素用括号中的术语标记，例如在 AI 表工作表中的"Views"列下，如下所示。在设置过滤器时，可以看到相应的元素集合。 > 图 38：AI 表中视图的表示 此外，也可以为单个模型元素分配"多个视图"。例如，在上图中，我们看到单个模型元素 (BodyPitchAgAbsltEstimd) 被分配了两个视图（Chassis 和 Pt），分别用'逗号'分隔。 请注意，对 AI 表布局的相应更改未反映在本文档的其他图中。 对于某些用例，需要建立元素集合。此类集合与包正交。因此，集合驻留在包中，但通过与所收集元素的关联来建立，如下图所示。但是，对于应用接口，仅使用此方法的一个子集，更多详细信息可以在 [4] 中看到。 不同的视图将以集合形式规定，类别为 SET，元素角色为 PART_OF_SUBSET。 > 图 39：元模型中集合的表示 将规定两个集合来定义视图，一个使用 autoCollect=REF-ALL，另一个使用 autoCollect=REF-NONE。 - **REF-ALL** 表示此集合将自动包括所有引用的模型元素。这些元素不列在集合内。 - **REF-NONE** 表示此集合不包括任何引用的模型元素。这意味着只有集合中列出的元素才属于它。 对于生成的 XML，两个生成的集合将定义相应的内容。参考下面的 XML 摘录： 使用 autoCollect=REF-ALL 的集合包含一个 PortPrototypeBlueprint（AbsCtrlIntvg）。这意味着引用的模型元素（如 PortInterface、ApplicationDataType、CompuMethod 和 Unit）也属于此集合。 使用 autoCollect=REF-NONE 的集合包含一个 PortPrototypeBlueprint（AbsCtrlIntvg）以及集合内的引用模型元素，如 PortInterface、ApplicationDataType、CompuMethod 和 Unit。 对于 AI 表内视图的规定，在一张工作表（例如提供方）上标记 PortPrototypeBlueprint 就足够了。这意味着即使未在接收方侧标记，它也将属于该视图。同样，可以在不同的工作表上规定两个不同的视图。XML 生成将考虑所有规定的视图。 ```xml EN English AUTOSAR AUTOSAR AISpecification Collections_Blueprint BLUEPRINT ChassisRefAll SET REF-ALL PART_OF_SUBSET AbsCtrlIntvg …… Chassis SET REF-NONE PART_OF_SUBSET AbsCtrlIntvg AbsCtrlIntvg1 CtrlSts1 CtrlSts1 NoUnit NoDimension CtrlSts1 …… ``` --- ## 8 应用接口（AI）表的结构 AI 表在 [8] 中引用。 ### 8.1 AI 表的主要工作表 AI 表的 02_General_Purposes 中可以找到工作表的简要概述。以下部分详细解释了结构，并带有图形表示。AI 表的基本工作表如下所列；完整列表可在 8.2 小节中引用。 这些是与修改 AI 表内容以标准化应用接口相关的工作表，不考虑管理工作表。管理工作表包含一致性检查的结果，由宏自动填充。执行一致性检查宏后，用户可能必须检查这些工作表。 | 工作表编号 | 内容 | |------------|------| | 04_Keywords | 关键字定义 | | 05… compositions, components | 组合和组件及其端口的定义 | | 06_Interface_DataElements | 发送者/接收者接口的定义 | | 06_Interface_ClientServer | ClientServerInterface | | 07_DataTypes_ContinuousValue | 连续值 DataTypes 的定义 | | 08_DataTypes_Enumeration | 枚举 DataTypes 的定义 | | 09_DataTypes_Array | 数组 DataTypes 的定义 | | 11_DataTypes_Record | 记录 DataTypes 的定义 | | 13_Units | 单位的定义 | | 15_Redirected_Ports | 重定向端口的定义 | 在以下部分中，详细解释了工作表的所有主要类别。 **注**：以下各节中显示的所有图形和截图仅为示例，可能与 AI 表内容不完全匹配。 #### 8.1.1 Sheet 04_Keywords AI 表的 "04_Keywords" 工作表包含关键字及其缩写。列 "Short Name"、"Long Name"、"Abbr Name" 和 "Description" 用于定义关键字（例如 Accept）、关键字缩写（例如 Acpt），这些在 AUTOSAR 中通常达成一致。这些定义的关键字缩写用于定义 AI 表中标准化元模型元素（例如 Port、PortInterface）的短名称。关键字工作表如图 40 所示。 > 图 40：Sheet 04_Keywords - 关键字示例 在某些情况下，可以观察到关键字根据使用上下文具有多个含义。例如，关键字的 Abbr Name 相同的情况，例如"At"可以用作"Preposition"或"Automatic Transmission"，如下图所示。这样的关键字条目被重复，其中创建两个单独的条目具有相同的 Abbr Name，并基于用法更新相应的短名称和分类。关键字的描述和分类区分其用法和含义。 > 图 41：Sheet 04_Keywords - 关键字的多种含义 #### 8.1.2 Sheet 05_TopLevel TopLevel 工作表包含域间 PortPrototypes 和 PortInterface 连接矩阵。每个条目的 PortInterface 短名称、port 短名称、port 长名称、port 描述分别存在于具有标题 "PortInterface ShortName"、"ShortName of Port"、"Long name of Port" 和 "Description of port" 的列中。在这些列之后，存在管理列（启动 WP 和 Milestone 1）和一致性检查结果矩阵列（有关一致性检查的理解，请参阅 AI 表中的 sheet 102_User_Documentation）。在管理列之后，'transmissionAcknowledgement Timeout' 和 'canInvalidate' 列中提供了与通信相关的信息。'TransmissionAcknowledgement Timeout' 列规定在报告错误或允许冗余情况下重新发送值之前的秒数。'canInvalidate' 列提供组件是否可以主动使数据无效的状态。'TransmissionAcknowledgement Timeout' 和 'canInvalidate' 不会在生成的 XML 文件中创建。 > ¹ AI 表中可见的数据质量始终基于从步骤号和里程碑组合而来的质量指示符，例如 SxMSy（其中 x 可以是 0、1、2、3…，y 可以是 1、2、3、4）。在审查后或对模型元素进行任何修改后，始终需要手动更改 Milestones 字段。PortInterface 的里程碑不能高于 DataType 的里程碑。同样，port 的里程碑不能高于 PortInterface 的里程碑。 灰色标记的"一致性检查"列之后，存在黄色标记的"TopLvl"列。此黄色标记的列在此工作表中没有功能意义。每个域在以下列中表示。组合组合类型的短名称（例如 Body）和组合组合原型的短名称（例如 Body）在每个域列的单独行中提及。 每个域列包含 5 个子列： - Provider port（标题为 "P"） - Receiver port（标题为 "R"） - 端口的存在（标题为 "core cond opt"） - 初始值（标题为 IV） - 描述（标题为 components specific description） 对于 PortInterface 及其相应端口的每个条目，在 'P' 或 'R' 列中根据需要用 'X' 建立域间链接（数据交换连接）。 "core cond opt" 列定义为表示相应 Port 是属于 SWC 核心功能（Core）还是仅以条件形式存在（Cond）。但是，此信息在 ARXML 生成中被忽略。 'IV' 列用于在发送组件尚未初始化的情况下指定初始值。如果发送方还规定了 init 值，则将使用接收方的值。此信息不会在宏生成的 XML 文件中创建。 'components specific description' 用于为将考虑用于 XML 文件中 PortPrototype 的 description/introduction [Refer [1]] 属性的端口指定任何附加注释。 根据 AUTOSAR 定义，应有一个唯一的提供方，因此每个条目仅在 "P" 列中标记一个 "X"。由于数据可以被多个端口接收，因此每个条目的多个 "R" 列可以标记为 "X"。 在某些用例中，工作表中的 P 或 R 列可能直接具有写入单元格的端口短名称，而不是 'X'。如果不同域中端口的短名称不相同，或者由于组件的多重实例化建模，可能会发生这种情况。 对于每个端口，使用数据元素（对于 SenderReceiver 接口）或操作的参数（对于 Client-Server 接口）定义其相应的 PortInterface。其定义和规范的详细信息可作为接口定义的一部分在 sheet 06_Interface_DataElements 和 06_Interface_ClientServer 中获得。 下图显示了域间接口定义，为简单起见，仅显示两个域 "Body" 和 "Pt"。 > 图 42：Sheet 0500_TopLevel - AI 表域间接口定义 > 图 43：Sheet 06_Interface_DataElements - 接口规范 > 图 44：Sheet 07_DataTypes_ContinuousValue - ContinuousValue DataType 定义 > 图 45：Sheet 13_Units - 单位定义 在上面的图中，AI 表中的接口分配信息流由红色矩形框显示。 在标准化的理想情况下，不应有任何开放端口，但在 AI 表的当前版本中，某些连接保持打开状态。因此，在"TopLevel"中允许开放端口，尽管这不是理想情况。开放端口是那些可以仅定义为提供方"P"或仅定义为接收方"R"的端口，并且在跨域 SWC 之间没有建立封闭连接。 #### 8.1.3 Sheets 050xxxxx 这些工作表内容与"TopLevel"工作表中解释的内容非常相似。对于每个域，存在格式为 "050x_" 的工作表（例如 0501_Body），其中包含域内 SoftwareComposition 数据交换矩阵。遵循第一个工作表，域可以有几个工作表 "050xy_"（例如 050101_CentralLocking）将具有子组合/SW 组件数据交换矩阵。对于所有域，工作表命名和组织按照上面通过示例解释的方式排列。 下图是"Body"域工作表示例，此处为简单起见仅显示有限信息。 下图显示了"Body"域组合工作表。 > 图 46：Sheet 0501_Body - Body 域组合工作表 每个域的第一个工作表表示该域的顶级接口矩阵。域的相应工作表包含有关每个 SW 组合/组件的端口和 PortInterface 连接矩阵的信息。 每个工作表包含以下信息：PortInterface 短名称、port 短名称、port 长名称、port 描述分别存在于具有标题 "PortInterface ShortName"、"ShortName of Port"、"Long name of Port" 和 "Description of port" 的列中。在这些列之后，存在管理列和一致性检查结果矩阵列（有关一致性检查的理解，请参阅 AI 表中的 sheet 102_User_Documentation）。在标题行中，组件/组合类型的每个域 ShortName 和组件/组合原型的 ShortName 在不同的列中提及，具体取决于组件/组合的数量。 对于 PortInterface 及其相应端口的每个条目，根据需要在 'P' 或 'R' 列中用 'X' 建立域间链接（数据交换连接）。根据 AUTOSAR 定义，应有一个唯一的提供方，因此每个条目仅在 "P" 列中标记一个 "X"。由于数据可以被多个端口接收，因此每个条目的多个 "R" 列可以标记为 "X"。 "core cond opt" 列定义为表示相应 Port 是属于 SWC 核心功能（Core）还是仅以条件形式存在（Cond）。但是，此信息在 ARXML 生成中被忽略。 'IV' 列用于在发送组件尚未初始化的情况下指定初始值。如果发送方还规定了 init 值，则将使用接收方的值。此信息不会在宏生成的 XML 文件中创建。 'components specific description' 用于为将考虑用于 XML 模型中 PortPrototype 的 description/introduction [Refer [1]] 属性的端口指定任何附加注释。 在某些用例中，工作表中的 P 或 R 列可能直接具有写入单元格的端口短名称，而不是 'X'。如果不同域中端口的短名称不相同，或者由于组件的多重实例化建模，可能会发生这种情况。 对于每个端口，使用数据元素（对于 SenderReceiver 接口）或操作的参数（对于 Client-Server 接口）定义其相应的 PortInterface。其定义和规范的详细信息可作为接口定义的一部分在 sheet 06_Interface_DataElements 和 06_Interface_ClientServer 中获得。 有关跨其他工作表的数据信息流的示例图在第 8.1.2 章中提供。 #### 8.1.4 Sheet 06_Interfaces_DataElements (SenderReceiverInterface) 此工作簿工作表包含在任何 05xx 域/组合工作表中引用的所有 SenderReceiverinterfaces。每个 Sender-Receiver 接口可以在所有 05xx 域/组合工作表中多次使用。一个接口也可以用于不同的端口。 在此工作表中，每个接口的 PortInterface ShortName 和 PortInterface longname 分别存在于具有标题 "SenderReceiverInterface ShortName" 和 "Long Name" 的列中。在这些列之后，存在管理数据列和"Description"列。"Description" 列包含 PortInterface 的描述。对于每个接口，必须规定至少一个数据元素（Variable Data Prototype）。也允许规定多个数据元素。目前在当前 AI 表中最多使用 6 个数据元素，但如果需要，可以添加更多数据元素。每个数据元素在单独的列中具有数据元素名称、DataType、数据元素的描述、排队信息和信号质量信息，分别具有标题 "Name"、"Type"、"Description"、"Queuing" 和 "Signal Qualifier"。'Queuing' 列指示必须在接收方侧处理 DataElement 的方式。TRUE：元素以 FIFO 数据结构添加到队列中；FALSE：应用 last is best 语义。此信息尚未在 XML 模型中导出，目前未使用。'Signal Qualifier' 列提供有关信号质量及其表示的附加信息。此信息尚未在 XML 模型中导出，其使用仍在讨论中。每个数据元素的数据类型可以是连续值或枚举或数组或记录 DataTypes，这些分别在 worksheet "07_DataTypes_ContinuousValue"、"08_DataTypes_Enumeration"、"09_DataTypes_Array"、"11_DataTypes_Record" 中定义。 此外，此工作表具有带灰色标题的列，这些列用于一致性检查结果。 下图显示了接口工作表 06_Interfaces_DataElements 和 DataType 工作表（例如 07_DataTypes_ContinuousValue）之间的数据信息流，用红色矩形框标记。 > 图 47：Sheet 06_Interface_DataElements - AI 表 Sender-Receiver 接口规范 > 图 48：Sheet 07_DataTypes_ContinuousValue - AI 表 ContinuousValue DataType 定义 > 图 49：Sheet 13_Units - 单位定义 由于 PortInterfaces 旨在支持可重用性，因此建议将已定义的 SenderReceiver PortInterfaces 重用于要传输相同种类信息的 PortPrototypes。 图 50 演示了 PortInterfaces 的可重用性。在下面显示的示例中，PortInterface BodyRollAg1 由 PortPrototypes BodyRollAgAbsltEstimd、BodyRollAgRelEstimd 和 BodyRollAgRelMeasd 使用。这些 PortPrototypes 由 SW-Component Esc 接收。PortPrototypes BodyRollAgAbsltEstimd 和 BodyRollAgRelEstimd 由 SW-Component Susp 提供，PortPrototype BodyRollAgRelEstimd 由 SW-Component ChassisSnsr 提供。 > 图 50：PortInterface 可重用性示例 与 PortInterfaces 类似，建议重用已定义的 DataType。 > 图 51：DataTypes 的可重用性 请注意，SW-C 和系统建模指南 [9] 中定义了一些规则，例如 NR044 和 NR048，以便实现 DataType 的可重用性。 #### 8.1.5 Sheet 06_Interface_ClientServer 此工作表包含在任何 05xx 复合组合/分解组合工作表中引用的所有 ClientServer 接口。每个已定义的 ClientServer 接口可以在所有 05xx 域/组合工作表中多次使用。一个接口也可以用于不同的端口。 在此工作表中，每个接口的 PortInterface 短名称和 PortInterface 长名称分别存在于具有标题 "ClientServerInterface ShortName" 和 "Long Name" 的列中。在这些列之后，存在管理数据列和"Description"列。"Description" 列包含 PortInterface 的描述。在这些列之后，定义了 ClientServer 接口的操作名称。这包含信息、操作短名称、操作长名称和操作描述，分别在具有标题 "ShortName"、"Long Name" 和 "Description" 的单独列中定义。一个接口由多个操作组成，这些操作将在不同的行中规定。对于每个操作，允许指定任意数量的参数。为简化当前状态下的 AI 表，任何已定义的接口最多可以指定三个参数。每个参数在单独的列中具有参数短名称、参数长名称、参数描述、参数 DataType、参数的类型（输入、输出和输入以及输出），分别具有标题 "ArgumentName ShortName"、"Long Name"、"Description"、"DataType" 和 "IN/OUT/INOUT"。每个元素的数据类型可以是连续值或枚举或数组或记录类型，这些分别在 worksheet "07_DataTypes_ContinuousValue"、"08_DataTypes_Enumeration"、"09_DataTypes_Array"、"11_DataTypes_Record" 中定义。 此外，此工作表包含带灰色标题的列，这些列用于一致性检查结果。 下图显示了接口工作表 06_Interface_ClientServer 和 DataType 工作表之间的数据信息流，用红色矩形框标记。 > 图 52：Sheet 06_Interface_ClientServer - AI 表 ClientServer 接口规范 > 图 53：Sheet 07_DataTypes_ContinuousValue - AI 表 ContinuousValue DataType 定义 DataType Nr4 的单位为 'NoUnit'，表示为 '-'。DataType Nr4 只是一个数字，不表示任何物理量，因此没有单位。 > 图 54：Sheet 13_Units - AI 表单位定义 由于 PortInterfaces 旨在支持可重用性，因此建议将已定义的 ClientServer PortInterfaces 重用于要传输相同种类信息的 PortPrototypes。 #### 8.1.6 Sheet 07_DataTypes_ContinuousValue 此工作表将具有不同分辨率的 DataTypes，可在任何 06xx 工作表中定义的任何 PortInterfaces 或复杂 DataTypes 中使用。 在此工作表中，每个 DataType 定义条目的 Data 类型短名称、Data 类型长名称和 DataType 描述分别存在于具有标题 "Short Name"、"Long Name" 和 "Description" 的列中。在管理数据列之后，定义 DataTypes 的分辨率和范围详细信息。这些列将具有关于最小位数要求、分辨率、物理下限和上限、偏移值和物理单位的信息，分别具有标题 "Minimal Bits Size recommended"、"Resolution"、"Physical Lower Limit"、"Physical Upper Limit"、"Offset" 和 "Unit"。Minimal Bits Size recommended 由宏根据分辨率、物理下限、上限和偏移值列中提供的输入计算。Units 列利用由 "Unit Display Name" 引用的工作表 "13_Units" 中定义的物理单位。 此外，还有一列 "Is float"，用于标记是否建议将 DataType 用作 float 数据类型。在这种情况下，此 DataType 在此列中标记为 "x"。 此外，此工作表包含带灰色标题的列，这些列用于一致性检查结果。 图 52 和图 53 显示了从接口到 DataTypes_ContinuousValue 的数据信息流。 #### 8.1.7 Sheet 08_DataTypes_Enumeration 此工作表包含用于在任何 06xx 工作表中定义的 PortInterfaces 和复杂 DataTypes 中使用的具有值的枚举 DataTypes。 在此工作表中，每个枚举 DataType 定义条目的枚举 (enum) Data 类型短名称、Enum Data 类型长名称和 enum DataType 描述分别存在于具有标题 "Data Type Name"、"Long Name" 和 "Description" 的列中。在管理数据列之后，每个枚举所需最小位数的信息、枚举元素的值和名称以及注释在具有标题 "Minimal Number of Bits"、"value"、"name" 和 "comment" 的单独列中定义。每个 enum DataType 所需的最小位大小由宏计算，并将该值放在第一个枚举元素行中。每个枚举数据元素的值在单独的行中定义，因此多行属于每个枚举 DataType 定义。 如果枚举数据类型定义的第一行在列 "is boolean" 中包含 "X"，则生成器将把类别 "BOOLEAN" 分配给数据类型。否则，将使用类别 "VALUE"。任何标记为 "is boolean" 的数据类型必须恰好由两行定义组成，包含值 0 和 1 的字面量定义。 此外，此工作表包含带灰色标题的列，这些列用于一致性检查结果。 下图显示了接口工作表和 enum DataType 工作表之间的数据信息流，用红色矩形框标记。 > 图 55：Sheet 06_Interface_DataElements - AI 表 SenderReceiver 接口规范 > 图 56：Sheet 08_DataTypes_Enumeration - AI 表非布尔枚举 DataType 定义 > 图 57：06_Interface_DataElements - AI 表 SenderReceiver 接口与布尔类型枚举 DataType > 图 58：Sheet 08_DataTypes_Enumeration - AI 表布尔枚举 DataType 定义 #### 8.1.8 Sheet 09_DataTypes_Array 此工作表包含要在任何 06xx 工作表中定义的 PortInterfaces 和复杂 DataTypes 中使用的数组 DataTypes。 在此工作表中，每个数组 DataType 定义条目的数组 DataType 短名称、数组 DataType 长名称和数组 DataType 描述分别存在于具有标题 "Data Type Name"、"Long Name" 和 "Description" 的列中。在管理数据列之后，数组元素 DataType 短名称和数组大小的信息在具有标题 "Type Name" 和 "Number of Elements" 的单独列中定义。数组的类型名称可以在 worksheet 07_DataTypes_ContinuousValue、08_DataTypes_Enumeration、09_DataTypes_Array 和 11_DataTypes_Record 之一中找到。 此外，此工作表包含带灰色标题的列，这些列用于一致性检查结果。 下图显示了从接口工作表 06_Interfaces_DataElements 到数组 DataType 工作表的数据信息流，用红色矩形框标记。 > 图 59：Sheet 06_Interface_DataElements - AI 表 Sender-Receiver 接口规范 > 图 60：Sheet 09_DataTypes_Array - AI 表数组 DataType 定义 > 图 61：Sheet 07_DataTypes_ContinuousValue - AI 表 ContinuousValue DataType 定义 > 图 62：Sheet 13_Units - 单位定义 #### 8.1.9 Sheet 11_DataTypes_Record 此工作表包含记录 DataTypes，其中每个记录元素/条目可能具有不同的（子）DataTypes。这些类似于 "C" 语言结构体类型。这些记录 DataTypes 定义为在任何 06xx 工作表中定义的 PortInterfaces 和复杂 DataTypes 中使用。 在此工作表中，每个记录 DataType 定义条目的记录 DataType 短名称、记录 DataType 长名称和记录 DataType 描述分别存在于具有标题 "Record Type Name"、"Long Name" 和 "Description" 的列中。在管理数据列之后，关于已定义 DataType 中记录数据元素的数量、记录元素的名称、记录元素的（子）DataType 以及每个元素的注释的信息在具有标题 "Number of element"、"Name"、"Type Name" 和 "Comment" 的列中定义。记录 DataTypes 用于存储不同 DataType 的多个值。记录 DataTypes 可以具有一个或多个记录元素，每个记录元素将具有不同的 ShortName，并且可能具有不同的（子）DataTypes。对于每个记录 DataType，第一行将在具有标题 "Number of element" 的列中具有定义的元素数量。每个记录元素在单独的行中定义。记录元素（子）DataType 定义短名称可以在以下 worksheet 之一中找到：07_DataTypes_ContinuousValue、08_DataTypes_Enumeration、09_DataTypes_Array 和 11_DataTypes_Record。 此外，此工作表包含带灰色标题的列，这些列用于一致性检查结果。 下图显示了从接口工作表 06_Interfaces_DataElements 到记录 DataType 工作表的数据信息流，用红色矩形框标记。 > 图 63：Sheet 06_Interface_DataElements - AI 表 Sender-Receiver 接口规范 > 图 64：Sheet 11_DataTypes_Record - AI 表记录 DataType 定义 > 图 65：Sheet 08_DataTypes_Enumeration - AI 表枚举 DataType 定义 #### 8.1.10 Sheet 13_Units 在此工作表中，定义了用于规定连续 DataTypes 的单位。单位由单位显示名称引用。 在此工作表中，每个物理单位条目的物理单位短名称、物理单位长名称、物理单位描述和物理单位显示名称分别存在于具有标题 "Unit Name (short name)"、"Long Name"、"Unit Display Name" 和 "Description" 的列中。在这些列之后，存在 Physical Dimension 列表列。国际单位制的七个基本量在 E 到 K 列之间表示。用于单位的因子和偏移在 L 和 M 列中提及。之后，存在管理数据列和带灰色标题的列，这些列用于一致性检查结果。 > 图 66：Sheet 06_Interface_DataElements - AI 表 SenderReceiverInterfaces 规范 > 图 67：Sheet 07_DataTypes_ContinuousValue - 带单位的 ContinuousValue DataType > 图 68：Sheet 13_Units - 单位定义 #### 8.1.11 Sheet 15_Redirected_Ports 此工作表用于为在一个 05 工作表中指定的连接矩阵中已重命名/重定向的端口提供 PortPrototypeBlueprint 定义。 如上所述，对于任何给定的组件原型，可以通过在连接矩阵中指定新的端口短名称而不是在 "P" 或 "R" 字段中使用 "X" 来本地重命名或重定向行开头给出的端口名称。在这种情况下，通常在行中前几列中规定的 long name 和 description 对于为重命名端口生成的 PortPrototypeBlueprint 将不正确。 为了获得这些端口的完整定义，它们可以在另一个 05 组合工作表的上下文中更详细地定义；或者它们可以通过在 worksheet 15_Redirected_Ports 中添加条目以通用（即与组合类型无关）方式定义。 当宏 "Update and Check" 检测到这样一个重定向/重命名端口没有适当的定义时，它将在 Sheet 15 中创建一个新条目。但是，它将使 "long name" 和 "description" 的条目留空；这些需要由人工用户填写。在条目完成之前，生成器将在连续运行中发出错误消息信号。 如果一个端口被多次定义，即其中一个 05 工作表包含可用的端口定义，或者同一端口在 sheet 15 中被多次定义，生成器将标记错误消息 "redundant port def. for redirected port" 或 "unused def. of redirected port"。然后用户应从 Sheet 15 中删除重复的条目以删除错误。 > 图 69：Sheet 15_Redirected_Ports ### 8.2 AI 表的所有工作表的完整列表 | # | 标题 | 内容 | |---|------|------| | 1 | 01_History | 表的更改历史 | | 2 | 02_General Purposes | 包含与工作表相关的列标题列表；提供解释以便在表中添加或更改数据集 | | 3 | 04_Keywords | 同意的关键字及其缩写以及使用上下文描述列表 | | 4 | 0500_TopLevel | 顶级组合包含与主要域组合的域间端口原型相关的信息（例如 Body、Powertrain） | | 5 | 0501_Body | (1) 车身域组合 | | 6 | 050101_CentralLocking | 中央锁定组件 | | 7 | 050102_InteriorLight | 内部灯组件 | | 8 | 050103_MirrorAdjustment | 后视镜调整组件 | | 9 | 050104_MirrorTinting | 后视镜着色组件 | | 10 | 050105_SeatAdjustment | 座椅调整组件 | | 11 | 05010501_Seat | 座椅组件 | | 12 | 0501050101_SeatAxis | 座椅轴组件 | | 13 | 050106_ExteriorLight | 外部灯组件 | | 14 | 050107_WindowControl | 车窗控制组件 | | 15 | 050108_WiperWasher | 雨刷洗涤器组件 | | 16 | 05010801_NozzleHeater | 喷嘴加热器组件 | | 17 | 05010802_Wiper | 雨刷组件 | | 18 | 05010803_Washer | 洗涤器组件 | | 19 | 05010804_WasherFluidTank | 洗涤液罐组件 | | 20 | 05010805_RainSensing | 雨量感应组件 | | 21 | 050109_AntiTheftSystem | 防盗系统组件 | | 22 | 050110_HornControl | 喇叭控制组件 | | 23 | 050111_ConvertibleControl | 敞篷车控制组件 | | 24 | 050112_DefrostControl | 除霜控制组件 | | 25 | 050113_ParkDistanceControl | 停车距离控制组件 | | 26 | 050114_Immobilizer | 防盗器组件 | | 27 | 050115_BodySensors | 车身传感器组件 | | 28 | 050117_RemoteKeylessEntry | 无钥匙进入组件 | | 29 | 050118_KeyPad | 键盘组件 | | 30 | 050119_PassiveEntry | 被动进入组件 | | 31 | 050120_TerminalClampControl | 端子夹控制组件 | | 32 | 050121_SeatClimatization | 座椅空调组件 | | 33 | 0502_Powertrain | (2) 动力总成组合 | | 34 | 050201_CombustionEngine | 内燃机组件 | | 35 | 050299_VehicleMotionforPt | 动力总成车辆运动组件 | | 36 | 0503_Chassis | (3) 底盘组合 | | 37 | 050301_CrsCtrlAndAcc | 巡航控制和自适应巡航控制组件 | | 38 | 0504_OPSafety | (4) 乘员安全组合 | | 39 | 0504001_OcctPedSftySnrsPool | 乘员和行人安全传感器池组件 | | 40 | 0504002_I_OcctPedSftyActrPool | 乘员和行人安全执行器池组件 I | | 41 | 0504002_II_OcctPedSftyActrPool | 乘员和行人安全执行器池组件 II | | 42 | 0504002_III_OcctPedSftyActrPool | 乘员和行人安全执行器池组件 III | | 43 | 0504102_SeatBltRmn | 安全带提醒组件 | | 44 | 0505_MM_T_HMI | (5) 多媒体、远程信息处理、人机界面组件 | | 45 | 06_Interface_DataElements | 发送者-接收者接口定义列表 | | 46 | 06_Interface_ClientServer | ClientReceiverInterface 定义列表 | | 47 | 07_DataTypes_ContinuousValue | 连续值 DataTypes 列表 | | 48 | 08_DataTypes_Enumeration | 枚举 DataTypes 列表 | | 49 | 09_DataTypes_Array | 数组 DataTypes 列表 | | 50 | 11_DataTypes_Record | 记录 DataTypes 列表 | | 51 | 13_Units | 单位列表 | | 52 | 15_Redirected_Ports | 重定向端口的定义列表 | | 53 | 101_Description | 摘要对话框中显示的一致性检查结果的解释 | | 54 | 102_User_Documentation | 包含可用的 Visual Basic 宏及其功能的列表 | 以下工作表是管理工作表，由宏自动填充。 | # | 标题 | 内容 | |---|------|------| | 55 | Compositions | AI 表中可用的组合/组件概述 | | 56 | Compositions_Err | 组合及其分解的一致性检查失败结果 | | 57 | Instances | AI 表中可用的组合原型（实例）概述 | | 58 | Instances_Err | 组合原型（实例）的一致性检查失败结果 | | 59 | 90_ReportMSDiagram | 表示带有里程碑的模型元素的表条目分布历史的图。此数据由宏生成。 | | 60 | 90_ReportMSTable | 关于里程碑和步骤的表条目分布历史的透视表。此数据由宏生成。 | | 61 | 90_ReportMSTableNoSteps | 关于里程碑的表条目分布历史的透视表。将排除步骤信息。此数据由宏生成。 | | 62 | 91_ReportErrDiagram | 表示检测到的错误概述的图。此数据由宏生成。 | | 63 | 91_ReportErrTable | 检测到的错误的透视表。此数据由宏生成。 | --- ## 9 AI 表数据与 XML 输出之间的关系 AI 表中的数据反映了 AUTOSAR 元模型中定义的结构，用于生成 AUTOSAR 应用接口的 XML 描述。XML 描述应遵循从 AUTOSAR 元模型 [7] 生成的 AUTOSAR 模式 [3]。 ### 9.1 概述 #### 9.1.1 XML 生成的依赖关系 图 70 说明了 XML 生成过程中的依赖关系。目前，AI 表反映一个数据库中多个版本的结构，即 R3.0 和 R4.0。然后，此公共数据库由 AI XML 生成使用，以为每个支持的版本生成 XML 描述。这种方法意味着并非所有 AI 表中的数据都将反映在所有生成的 XML 文件中，因为仅考虑 R4.0 的数据。 > 图 70：应用接口 XML 生成过程中的依赖关系 #### 9.1.2 生成 XML 的内容 XML 文件包含以下元素的描述： - 公共元素 - 包结构和类别 - 引用 - 实例引用 - 类型引用 - 描述 - 组合类型，包含： - 端口 - 组件原型 - 连接器 - PortPrototypeBlueprints - PortPrototypeBlueprints 的 BlueprintMappings - 接口 - Sender-Receiver-Interfaces - Client-Server-Interfaces - PortInterfaces 的 BlueprintMappings - 应用数据类型，包括： - 具有约束的基元类型 - 数组类型 - 记录类型 - ApplicationDataTypes 的 BlueprintMappings - 数据约束 - 计算方法 - CompuMethods 的 BlueprintMappings - 单位 - 物理维度 - 关键字 - 数据约束 - DataConstrs 的 BlueprintMappings ##### 9.1.2.1 文件分发 从 R4.1.1 起，从 AI 表生成的 XML 分为以下 .arxml 文件，如下所示。这是由于 AUTOSAR 方法论的影响，要求严格分离 STANDARD 和 BLUEPRINT 类别。 应用接口域的交付结构： 官方版本 SVN 仓库的 Standard 部分提供： - `AUTOSAR_MOD_AISpecification.zip` 存档，其中包含： - `AUTOSAR_MOD_AISpecification_PhysicalDimension_Standard.arxml` - `AUTOSAR_MOD_AISpecification_Unit_Standard.arxml` - `AUTOSAR_MOD_AISpecification_DataConstr_Blueprint.arxml` - `AUTOSAR_MOD_AISpecification_CompuMethod_Blueprint.arxml` - `AUTOSAR_MOD_AISpecification_ApplicationDataType_Blueprint.arxml` - `AUTOSAR_MOD_AISpecification_PortInterface_Blueprint.arxml` - `AUTOSAR_MOD_AISpecification_PortPrototypeBlueprint_Blueprint.arxml` - `AUTOSAR_MOD_AISpecification_KeywordSet_Blueprint.arxml` - `AUTOSAR_MOD_AISpecification_Collection_Body_Blueprint.arxml` - `AUTOSAR_MOD_AISpecification_Collection_Pt_Blueprint.arxml` - `AUTOSAR_MOD_AISpecification_Collection_Chassis_Blueprint.arxml` - `AUTOSAR_MOD_AISpecification_Collection_OccptPedSfty_Blueprint.arxml` - `AUTOSAR_MOD_AISpecification_Collection_MmedTelmHmi_Blueprint.arxml` - `AUTOSAR_MOD_AISpecification_PortPrototypeBlueprint_LifeCycle_Standard.arxml` - `AUTOSAR_MOD_AISpecification_PortInterface_LifeCycle_Standard.arxml` - `AUTOSAR_MOD_AISpecification_ApplicationDataType_LifeCycle_Standard.arxml` - `AUTOSAR_MOD_AISpecification_CompuMethod_LifeCycle_Standard.arxml` - `AUTOSAR_MOD_AISpecification_DataConstr_LifeCycle_Standard.arxml` - `AUTOSAR_MOD_AISpecification_Unit_LifeCycle_Standard.arxml` - `AUTOSAR_MOD_AISpecification_PhysicalDimension_LifeCycle_Standard.arxml` - `AUTOSAR_MOD_AISpecification_Keyword_LifeCycle_Standard.arxml` - `AUTOSAR_MOD_AISpecification_Collection_AIMC_Keyword_Blueprint.arxml` - `AUTOSAR_CC_AISpecification.xml` 请注意，文件 "AUTOSAR_MOD_GeneralDefinition_Lifecycle.arxml" 将在 AUTOSAR 通用定义下发布，并且不是应用接口交付物的一部分。有关更多详细信息，请参阅应用接口交付物下的 readme.txt 文件。AUTOSAR_CC_AISpecification.xml 目录文件用于在特定工具需要时帮助解析引用。 官方版本 SVN 仓库的 Auxiliary 部分提供： - `AUTOSAR_MOD_AISpecification_Examples.zip` 存档，其中包含： - `AUTOSAR_MOD_AISpecification_Example.arxml` - `AUTOSAR_CC_AISpecificationExample.xml` (*) - `AUTOSAR_TR_AIMeasurementCalibrationDiagnostics` (pdf) - `AUTOSAR_TR_SWCModelingGuide` (pdf) - `AUTOSAR_RS_SWCModeling` (pdf) - `AUTOSAR_EXP_AIUserGuide` (pdf) - `AUTOSAR_TR_AIDesignPatternCatalogue` (pdf) (*)AUTOSAR_CC_AISpecificationExample.xml 目录文件用于在特定工具需要时帮助解析引用。 #### 9.1.3 模式结构 为了理解 XML 生成，有必要理解元模型和模式之间的关系。通常，模式为元模型的每个类包含一个 xsd:group。该组包含该类的所有属性，包括作为 xsd:element 序列的聚合和引用。具体类（与抽象类相反）还具有相应的 xsd:complexType。这些是从父元素继承的所有组的序列。 模式结构背后的一般概念将根据下图所示的示例进行描述，该示例显示了元模型中 Unit 元素的结构，包括其继承层次结构。 > 图 71：从元模型中剪切定义元素 Unit 的结构 此结构可以在 AUTOSAR 模式中的以下元素中找到： ```xml ... ... ... ``` 这种将组（适用于所有类，包括抽象类）和复杂类型（仅适用于具体类）的结构导致了一个特点，即只有具体类可以在 XML 实例级别上使用，并且继承层次结构在实例级别上不可见。以下示例显示了在实例级别上来自表 "13_Units" 的单位，该表仅包含来自 Identifiable 的属性： ```xml DegCgrd Degree Centigrade temperature, no SI unit, (degC = Kelvin - 273.15) degC 1 -273.15 T1 ``` 有关元模型和 AUTOSAR 模式之间关系的详细信息可以在 XML 的模型持久性规则 [5] 中找到。另请参见图 70。 以下各节详细描述了 AI 表如何与 XML 实例级别上的元素相关联。有关 AI 表和元模型之间关系的详细信息在第 4 章中描述。 以下所有描述都参考 AUTOSAR R4.0 模式。 ### 9.2 公共元素 #### 9.2.1 包结构 XML 内容被构造为分层包。顶级包名为 AUTOSAR，包含一个名为 AISpecification 的包。在此包下，输出被构造为 20 个不同的包，如下所列。 AISpecification 下的不同包是： - **PhysicalDimensions**：STANDARD 类别的包，包含所有物理维度 - **Units**：STANDARD 类别的包，包含所有标准化单位 - **Standard_LifeCycle**：STANDARD 类别的包，包含模型元素的生命周期信息 - **ApplicationDataTypes_Blueprint**：BLUEPRINT 类别的包，包含所有 ApplicationDataTypes - **CompuMethods_Blueprint**：BLUEPRINT 类别的包，包含所有计算方法 - **DataConstrs_Blueprint**：BLUEPRINT 类别的包，包含所有数据约束 - **KeywordSets_Blueprint**：BLUEPRINT 类别的包，包含所有关键字 - **PortInterfaces_Blueprint**：BLUEPRINT 类别的包，包含所有 PortInterface 蓝图 - **PortPrototypeBlueprints_Blueprint**：BLUEPRINT 类别的包，包含所有 PortPrototypeBlueprints - **Collection_Body_Blueprint**：BLUEPRINT 类别的包，包含"Body"视图下的所有元素 - **Collection_Pt_Blueprint**：BLUEPRINT 类别的包，包含"Powertrain"视图下的所有元素 - **Collection_Chassis_Blueprint**：BLUEPRINT 类别的包，包含"Chassis"视图下的所有元素 - **Collection_OccptPedSfty_Blueprint**：BLUEPRINT 类别的包，包含"Occupant and Pedestrian Safety"视图下的所有元素 - **Collection_MmedTelmHmi_Blueprint**：BLUEPRINT 类别的包，包含"Multimedia Telematics and HMI"视图下的所有元素 - **PL_List**：包含覆盖信号物理和逻辑类型的关键字；用于文档、测量和标定目的（AUTOSAR_MOD_AISpecification_Collection_AIMC_Keyword_Blueprint.arxml） - **SwComponentTypes_Example**：EXAMPLE 类别的包，包含所有 SwComponentTypes - **BlueprintMappingSets_Example**：EXAMPLE 类别的包，包含所有蓝图元素的 BlueprintMappingSets - **ApplicationDataTypes_Example**：EXAMPLE 类别的包，仅作为 ApplicationDataTypes_Blueprint 元素的副本存在于此包中 - **PortInterfaces_Example**：EXAMPLE 类别的包，仅作为 PortInterfaces_Blueprint 的副本存在于此包中 - **CompuMethods_Example**：EXAMPLE 类别的包，仅作为 CompuMethods_Blueprint 元素的副本存在于此包中 - **DataConstrs_Example**：EXAMPLE 类别的包，仅作为 DataConstrs_Blueprint 元素的副本存在于此包中 下面的 XML 摘录显示了每个这些类别的包结构（详细 XML 内容见原文）。XML 输出以 AUTOSAR 根包开始，依次嵌套 AISpecification 包，其下包含 PhysicalDimensions、Units、ApplicationDataTypes_Blueprint、CompuMethods_Blueprint、DataConstrs_Blueprint、PortInterfaces_Blueprint、PortPrototypeBlueprints_Blueprint 等子包。 #### 9.2.2 引用 为应用接口生成的 XML 一致地使用引用基和相对路径进行所有引用。相对路径由不以斜杠（"/"）开头来标识。以下 XML 片段显示了对组合类型的端口的引用。DEST 属性定义引用 XML 元素的类型，BASE 属性引用在任何父包中定义的最近的引用基，内容定义引用目标，在本例中为来自包 /AUTOSAR/AISpecification/SwComponentTypes_Example 的组合类型 WiprWshr 中的端口 WipgSpdIntlFromHmi。 **引用基定义示例**： ```xml SwComponentTypes false false false /AUTOSAR/AISpecification/SwComponentTypes_Example ``` **引用基使用示例**： ```xml WipgSpdIntlFromHmiToWipgSpdIntlFromHmiOfWiprWshrMgr WiprWshr/WiprWshrMgr WiprWshrMgr/WipgSpdIntlFromHmi WiprWshr/WipgSpdIntlFromHmi ``` #### 9.2.3 实例引用 AUTOSAR XML 允许使用实例引用从类型的特定实例的类型定义中引用元素。例如，组件原型不定义端口，而仅引用其组合类型，后者定义端口。如果需要引用此端口，则需要引用上下文元素。该引用包含实例和目标元素。对于端口，实例是组件原型，目标元素是组合类型中的端口定义。 ```xml WipgSpdIntlFromHmiToWipgSpdIntlFromHmiOfWiprWshrMgr WiprWshr/WiprWshrMgr WiprWshrMgr/WipgSpdIntlFromHmi WiprWshr/WipgSpdIntlFromHmi ``` #### 9.2.4 类型引用 如果目标元素被引用为源元素的类型，则 AUTOSAR XML 使用类型引用，即 *-TREF-element。例如，以下片段将元素 /AUTOSAR/AISpecification/ApplicationDataTypes_Blueprint/WipgSpdIntl1 引用为数据原型 Req 的类型。 ```xml Req WipgSpdIntl1 ``` #### 9.2.5 描述 描述不仅仅是放入一个描述元素，而是被解析并拆分为多个不同的元素。以下规则适用于描述字段的解析： - 空行分隔文档/描述的部分（提示：换行符应由 Alt+Enter = Chr(10) 引入） 在 XML 中，这些描述字段映射到以下两个不同的元素： - 第一节转到 DESC 元素，其中应包含简要描述。 - 后续章节作为单独的子元素转到 INTRODUCTION 元素： - 以冒号 (:) 结尾且完全大写（例如 REMARK:）的行开头的章节将成为 NOTE 元素，第一行是 LABEL，其余是 P 元素 - 没有标签的章节将成为 INTRODUCTION 中的简单 P 元素。可以在此处添加特定于 PortPrototype 的附加信息。 - 以星号 ("*") 或连字符 ("-") 开头的章节成为列表项。如果上一节不是列表项，则将启动列表元素 - 以空白开头的章节将成为逐字环境的一部分。如果上一节不是逐字环境的一部分，则将启动逐字环境 这些来自单元格的逐字环境将转换为 XML 中的以下结构。 **单元格中的文本**： ``` Returns the gear ratio for a given gear Theoretical transmission ratio i = ntransmission_in / ntransmission_out transmission_in = after converter transmission_out = gearbox out The gear ratio means the theoretical/physical ratio belonging to each gear and not any actual measured value (proposal for Continuously Variable Transmission(CVT): if there is a wide range for gear states, this value could deliver a theoretical value). Negative values: Reverse driving direction. Without considering the: * axle ratio * converter ratio * High/Low-Range ratio REMARK: Default value after reset is 1.0 ``` **XML 结构**： ```xml Returns the gear ratio for a given gear

Theoretical transmission ratio i = ntransmission_in / ntransmission_out

transmission_in = after converter transmission_out = gearbox out

The gear ratio means the theoretical/physical ratio belonging to each gear and not any actual measured value (proposal for Continuously Variable Transmission(CVT): if there is a wide range for gear states, this value could deliver a theoretical value).

Negative values: Reverse driving direction.

Without considering the:

axle ratio

converter ratio

High/Low-Range ratio

Default value after reset is 1.0

``` ### 9.3 组件类型 "05"-sheets 中收集组合类型的数据。顶部的行定义组合类型，而下面的行定义组合类型的端口和连接器。 每个 "05"-sheet 定义一个外部组合类型（黄色列）和多个内部组件，称为组件原型（蓝色列）。每个组件原型必须引用一个组件（组合）类型。如果此类型未在另一个 "05"-sheet 上声明为外部组合类型（由超链接引用），则在本地定义。在后一种情况下，组合类型的定义与组件原型相同，并且不应在其他工作表中重用。 > 图 72：Sheet 050108_WiperWasher - AI 表中组合类型 WiprWshr 的示例规范 #### 9.3.1 组合类型 XML 生成器为每个工作表为黄色列创建一个组合类型，并为每个没有超链接的蓝色列创建一个组合类型（具有超链接的蓝色列的组合类型稍后创建，当迭代链接的 "05"-sheets 时）。该定义写入包 /AUTOSAR/AISpecification/SwComponentTypes_Example。组合类型由其端口（绿色列）、组件（蓝色列）和连接器（带有 X 的连接器矩阵）定义。组合短名称取自黄色列中的第一行，如图 72 所示（单元格 Z1）。 以下 XML 片段显示为 WiprWshr 组件生成的 XML： ```xml WiprWshr ... (See Section 9.3.2) ... (See Section 9.3.3) ... (See Section 9.3.4) ``` 以下各节描述了 Ports、Components 和 Connectors 三个集合中的元素。 #### 9.3.2 端口 "05"-sheets 的下半部分定义端口和连接器。绿色列定义端口，右侧部分（组件下方）定义端口的存在和连接。例如，图 72 中截图的第 35 行为复合组件 WiprWshr 定义一个必需端口 WipgSpdIntlFromHmi（在单元格 AA35 中用 X 标记）。图 72 中 AA 列中的标记导致复合组件类型 WiprWshr 的端口集合中产生 R-Port-Prototype 项，如下所示： ```xml WipgSpdIntlFromHmi Wiping Speed Interval From Hmi WipgSpdIntlReq1 ``` 引用的接口必须是来自 06*-sheets 的有效接口（参见 8.1.4 和 8.1.5）。该接口通过类型引用引用。 由于图 72 中单元格 AC35 的标记，为组合类型 WiprWshrMgr 生成具有相同名称的类似端口。（蓝色）端口列 "core/cond/opt" 和 IV 当前与 XML 生成无关。 #### 9.3.3 组件 内部组件原型（实例）取自蓝色列。每个组件原型具有短名称，取自第 2 行（例如 AB2），并引用第 1 行（例如 AB1）中的组合类型，如图 72 所示。 ```xml WiprWshrMgr Wiper Washer Manager Wiper Washer Manager commands Wiper and Washers of the vehicle WiprWshrMgr ``` 通过 TYPE-TREF，组件原型引用一个组合类型，该组合类型根据原型定义生成，因为图 72 中显示的单元格 AB1 不包含超链接。 在多重实例的情况下，将为来自第 2 行中逗号分隔列表的每个实例生成这样的描述（例如 AG2）。可以通过使用不同的原型名称多次定义同一组件来实现多个实例的另一种可能性，如以下示例所示。 > 图 73：一列一个实例的多个实例 #### 9.3.4 连接器 有关连接器的信息取自连接器矩阵，从单元格 Z8 开始（在图 72 中不可见，因为第 8-34 行被隐藏）。可以使用值 X 或特定短名称本身声明连接。空单元格或字面"N/A"等特殊值不会建立连接器。连接器定义如下： **Delegation Connectors** 为蓝色列中与黄色列中的 X 具有相同方向的每个 X 创建。 ```xml WipgSpdIntlFromHmiToWipgSpdIntlFromHmiOfWiprWshrMgr WiprWshr/WiprWshrMgr WiprWshrMgr/WipgSpdIntlFromHmi WiprWshr/WipgSpdIntlFromHmi ``` 生成器根据以下规则创建 delegation connector 的短名称： `ToOf` 在上面的示例中，`` 是 WipgSpdIntlFromHmi，`` 是 WipgSpdIntlFromHmi，`` 是 WiprWshrMgr。因此，上面显示的 delegation connector 的短名称是 WipgSpdIntlFromHmiToWipgSpdIntlFromHmiOfWiprWshrMgr。 内部端口使用实例引用引用蓝色列中找到的组件原型的端口（参见 9.2.3 节）。请注意，IREF 的上下文是组合 WiprWshr 内的组件原型 WiprWshrMgr，而目标端口引用 SwComponentTypes 通用包中的组件类型 WiprWshrMgr，因此路径前缀不同。外部端口引用属于组合类型 WiprWshr 的黄色列中的端口。 **Assembly Connectors** 为每个必需端口（R 列中的标记）和来自连接器矩阵的内部组件原型的相应 P-Port 创建。 ```xml ActvnOfWshngCmdOfWshrFrntOfWiprWshrMgrToActvnOfWshngCmdOfWshrFrnt WiprWshr/WiprWshrMgr WiprWshrMgr/ActvnOfWshngCmdOfWshrFrnt WiprWshr/WshrFrnt Wshr/ActvnOfWshngCmd ``` 从片段中可以看到，两个端口都通过实例引用引用。 生成器根据以下规则创建 assembly connector 的名称： `OfToOf` 在上述示例的上下文中，`` 是 ActvnOfWshngCmdOfWshrFrnt，`` 是 WiprWshrMgr，`` 是 ActvnOfWshngCmd，`` 是 WshrFrnt。因此，assembly connector 的名称是 ActvnOfWshngCmdOfWshrFrntOfWiprWshrMgrToActvnOfWshngCmdOfWshrFrnt。 **多重实例化** 在这种情况下是一种特殊情况。端口 WipgCmdFor[Wipr]（图 72 中的单元格 B49）的名称根据由 Wipr 引用的列的实例名称进行扩展。该端口的所有组件（未在引用的列中定义）具有根据所有实例名称的多个端口，例如 WipgCmdForWiprFrnt 和 WipgCmdForWiprRe 表示 WiprWshrMgr，而对于提供实例迭代器的列中的所有组件，名称将缩写为 WipgCmd，即第一行中包含 Wipr 的第一列。 **语义约束**：为了保证 AUTOSAR XML 的语义正确生成，蓝色组件的 P 列中最多可能有一个 X。这意味着即使不满足约束，应用接口也将支持 AUTOSAR XML 的生成。 > 图 74：Sheet 050108_WiperWasher - 错误连接的 P-Port 如图 74 所示，指定了两个委托（蓝色背景上的两个标记为 X 的 P 列）。由于这表示组合中端口原型的模糊定义，因此被认为是违反语义约束。因此，P 列中存在多个 X 标记被认为是语义错误。请注意，XML 的生成仍然是可能的。 ### 9.4 PortPrototypeBlueprints AUTOSAR 应用接口的范围不包括定义完整的系统组合。所有软件组件组合类型在 EXAMPLE 类别的包中定义，仅用作标准化元素用法的说明。但是，应用接口的范围包括描述接口可以在组合中扮演的角色。这可以使用 PortPrototypeBlueprints 来完成，PortPrototypeBlueprints 定义组件类型的潜在端口，并且可以携带更多属性以预定义蓝图使用的值，例如初始值。有关 PortPrototypeBlueprints 的详细信息，请参阅标准化模板 [2]。 PortPrototypeBlueprints 收集在单个包 /AUTOSAR/AISpecification/PortPrototypeBlueprints_Blueprint 中： ```xml PortPrototypeBlueprints_Blueprint BLUEPRINT ... AbsCtrlIntvg ABS Control Intervening Antilock Braking System's (ABS) control is active (at least one wheel) AbsCtrlIntvg1 AbsFlgActv AbsControlActive Anti Blocking Systems (ABS) control is active (at least one wheel) AbsCtrlIntvg1 ... ``` 由于蓝图机制旨在帮助创建 PortPrototypes，AUTOSAR XML 还提供了一种映射机制，用于描述蓝图和原型之间的关系。此机制允许在不影响架构要求的情况下将 PortPrototype 与蓝图分离。映射被指定为包 /AUTOSAR/AISpecification/SwComponentTypes_Example 中成对序列的一部分： ```xml PortPrototypeBlueprintMappings AbsCtrlIntvg Chassis/AbsCtrlIntvg AbsCtrlIntvg Body/AbsCtrlIntvg ... ``` ### 9.5 PortInterfaces 提供或必需的 PortPrototype 引用 AI 表的 "06"-sheets 中定义的 PortInterface，分别用于 Sender-Receiver- 和 Client-Server-Interfaces。发送者-接收者接口和客户端-服务器接口都保存在包 /AUTOSAR/AISpecification/PortInterfaces_Blueprint 中。它们也是 /AUTOSAR/AISpecification/PortInterfaces_Example 的一部分，但仅作为蓝图的副本，以便它们可以用于 PortPrototypes。 #### 9.5.1 Sender-Receiver-Interface 图 75 显示了来自发送者-接收者接口表的一个接口，该接口定义了短名称、长名称、描述和所包含的数据元素（该表能够为每个 SenderReceiverInterface 捕获最多六个数据元素）。数据流的方向由端口定义。 > 图 75：sheet 06_Interface_DataElements 的结构 XML 生成器为上表行生成以下输出： ```xml WipgSpdIntlReq1 Wiping Speed Interval Request Requests the interval speed. As long as a interval wipe sequence is requested the provided value of interval speed has to be used. false Req WipgSpdIntl1 ``` 上述接口的相应 BlueprintMapping 是： ```xml PortInterfaceBlueprintMappings WipgSpdIntlReq1 WipgSpdIntlReq1 ``` 蓝图和派生元素在上述 XML 摘录中表示。此映射显示包 /AUTOSAR/AISpecification/PortInterfaces_Blueprint 提供了在 EXAMPLE 类别的包 /AUTOSAR/AISpecification/PortInterfaces_Example 中派生的蓝图接口。 有关排队和信号限定符的信息当前不用于 XML 生成。每个数据元素的引用类型必须在 DataType 工作表中定义。 #### 9.5.2 Client-Server-Interface 图 76 显示了来自客户端-服务器接口表的一个接口，该接口定义了短名称、长名称、描述和所包含的操作（每个操作一行，该表能够为每个操作捕获最多三个参数），并将具有相同接口短名称的所有操作合并到一个接口中。 > 图 76：sheet 06_Interface_ClientServer 的结构 XML 生成器为上述示例生成以下输出： ```xml TrsmRatGear1 Transmission: Gear Ratio for a Given Gear Returns the gear ratio for a given gear ... false GetTrsmRatGear Returns the Gear Ratio for a Given Gear Returns the gear ratio for a given gear Gear Gear for Which the Ratio Should Be Returned Gear for which the ratio should be returned Nr4 IN Rat Gear Ratio of Given Gear Gear ratio of given gear Fac1 OUT ``` 有关 description 和 introduction 元素生成的详细信息，请参见 9.2.5 节。 ### 9.6 Blueprint Mapping Sets BlueprintMappingSets 用于在 Blueprint 和从此 Blueprint 派生的元素之间建立连接。这有助于追溯用于创建此元素的相应 Blueprint。Blueprint Mapping Sets 用于不同的元素，包括 PortPrototypeBlueprints、PortInterfaces、Application DataTypes 等。它们在包 /AUTOSAR/AISpecification/BlueprintMappingSets_Example 中定义。 ```xml PortInterfaceBlueprintMappings TrsmRatGear1 TrsmRatGear1 ALgt2 ALgt2 ... ``` 此映射显示包 /AUTOSAR/AISpecification/PortInterfaces_Blueprint 提供了在 EXAMPLE 类别的包 /AUTOSAR/AISpecification/PortInterfaces_Example 中派生的蓝图接口。 类似地，对于 DataConstraints 的 Blueprint Mapping 如下： ```xml DataConstrBlueprintMappings TrsmTyp1 TrsmTyp1 ... ``` ### 9.7 Data Types 接口在发送者-接收者接口的数据元素和客户端-服务器接口的参数中引用 DataTypes。DataTypes 在工作表 "Sheet 07_DataTypes_ContinuousValue"、"Sheet 08_DataTypes_Enumeration"、"Sheet 09_DataTypes_Array"、"Sheet 11_DataTypes_Record" 中定义。 所有 DataTypes 保存在包 /AUTOSAR/AISpecification/ApplicationDataTypes_Blueprint 中。它们也是 /AUTOSAR/AISpecification/ApplicationDataTypes_Example 的一部分，但作为蓝图的副本，以便它们可以用于 PortInterfaces。 Application DataType 定义从应用程序角度交换软件组件之间或软件组件与测量和标定工具之间的数据所需的数据属性。 AI 表不标准化实现 DataTypes。有关更多详细信息，请参阅 [1]。 #### 9.7.1 Continuous Value Types 连续值需要缩放为整数；XML 生成器为连续类型创建三个元素：类型元素本身（引用定义比例的 SwDataDefProps 和定义整数值的限制的数据约束）。 > 图 77：sheet 07_DataTypes_ContinuousValue 的结构 以下片段定义整数数据类型 Perc8。类型元素提供名称（短和长）、描述，并使用字段"Minimal Bits Size recommended"提供建议的实现类型，以及用于单位引用的 Unit 字段。生成对计算方法数据约束的引用： ```xml Perc8 Percent 8 Generic data type for percent VALUE READ-ONLY Perc8 Perc8 0.00031 Perc ``` 此外，可以在包 /AUTOSAR/AISpecification/ApplicationDataTypes_Example 中找到上述数据类型"Percent 8"的相应 Blueprint Mapping： ```xml ApplicationDataTypeBlueprintMappings Perc8 Perc8 ... ``` 计算方法也定义为蓝图。还提供了计算方法的 BlueprintMapping 以帮助项目从蓝图创建实际的计算方法。计算方法的 BlueprintMappings 在包 BlueprintMappingSets_Example 中的集合 CompuMethodBlueprintMappings 中分组。 数据约束属于包 /AUTOSAR/AISpecification/DataConstrs_Blueprint： ```xml Perc8 -5 15 Perc ``` 对于 Float 通用 dataconstrs，范围为 [-INF,+INF]： ```xml FloatDataRange -INF +INF ***MtrPerSecSqd*** (no unit required) ``` 使用以下公式计算有符号范围的下限和上限的数据约束： ``` lowerLimit = Round((phys_lower_limit - offset) / factor) upperLimit = Round((phys_upper_limit - offset) / factor) ``` 对于无符号范围，使用以下公式： ``` lowerLimit = 0 upperLimit = Round((phys_lower_limit - offset) / factor) + Round((phys_upper_limit - offset) / factor) + 1 ``` 然后将这些 lowerLimit 和 upperLimit 用于计算表示整个信号范围所需的最小位数。 在上述模型元素（Perc8）中： - Range = [15 - (-5) = 20]，Resolution = 0.00031 - 因此最小推荐位大小为 [20/0.00031 = 64516]，因此为 'Uint16'。请注意，"最小推荐位大小"仅用作规范期间的信息，不会被标准化 计算方法属于包 /AUTOSAR/AISpecification/CompuMethods_Blueprint。 ```xml Perc8 Percent 8 Generic data type for percent LINEAR Perc -5 15 5 1 0.00031 ``` 在某些情况下，还希望规定可以实现为浮点数据类型（float）的应用数据类型。原因可能是避免物理值和内部值之间消耗资源的转换（对于 float，物理值和内部值是相同的），或实现更高的分辨率。 此类数据类型在 "Is float" 列中用 "x" 标记。 与定点表示（整数）的主要区别之一是，对于浮点表示，没有固定的分辨率。小值的分辨率优于大值的分辨率。然而，在 AUTOSAR 中，只能为 swIntentedResolution 提供一个固定值。因此，决定为 swIntentedResolution 规定单个 float 的最佳情况分辨率，即"0.0000001"。因此，所有打算实现为 float 的数据类型都将此值指定为 swIntentedResolution。 由于 float 不需要物理值和内部表示之间的转换，因此这些数据类型的 compu 方法定义物理值和内部值之间的 1:1 关系。因此，这种 compu 方法的类别是"IDENTICAL"（而不是"LINEAR"）。 此外，在这种情况下使用通用 compu 方法。由于定义 1:1 关系的所有 compu 方法对于给定单位是相同的，因此每个单位仅定义一个 1:1 compu 方法。此 compu 方法的 ShortName 为 `` + Identcl。 为了通用，这些 compu 方法也被定义为没有任何限制，即从 (–inf 到 +inf)： ```xml KelvinIdentcl Kelvin Identical IDENTICAL Kelvin ``` #### 9.7.2 Enumeration Types > 图 78：sheet 08_DataTypes_Enumeration 的结构 表中具有相同 Data Type Name 的所有（连续）行包含在一个枚举类型中。该类型引用一个定义字面量的计算方法（其大小从字面量计数计算）和一个基本类型的数据约束（也反映字面量计数）。 **注**：` ` 标记将包含 "BOOLEAN" 或 "VALUE"，具体取决于 "is boolean" 列是否用 "x" 标记。 ```xml TrsmTyp1 Transmission Type Information on standard transmission. Other transmission types on value 5 - 15 VALUE READ-ONLY TrsmTyp1 TrsmTyp1 NoUnit ``` 下面的 XML 片段显示了枚举 DataType 的 BlueprintMapping： ```xml TrsmTyp1 TrsmTyp1 ``` 枚举类型的字面量在计算方法中编码，每个字面量一个 COMPU-SCALE。字面量的描述不会像 9.2.5 节中描述的那样解析为多个元素。计算方法的 long name 从其相应数据类型的 long name 复制。 计算方法属于包 /AUTOSAR/AISpecification/CompuMethods_Blueprint： ```xml TrsmTyp1 Transmission Type TEXTTABLE 0 = Mt (manual transmission) 0 0 Mt 1 = At (automatic transmission) 1 1 At 2 = Amt (direct shift/ automated Mt) 2 2 Amt 3 = Cvt (continuously variable transmission) 3 3 Cvt 4 = Dct (twin-clutch gearbox or dual or double clutch transmission (Dct)) 4 4 Dct ``` 数据约束将基本类型的使用限制为实际需要的值，它们属于包 /AUTOSAR/AISpecification/DataConstrs_Blueprint： ```xml TrsmTyp1 0 4 ``` #### 9.7.3 Array Types > 图 79：sheet 09_DataTypes_Array 的结构 XML 生成从表条目直接进行，例如图 79 中第 5 行的 XML 将是： ```xml TirePPerWhl1 Tire Pressure per Wheel 1 Tire pressures at wheels. ARRAY

Convention is:

Index 0 = Front Left

Index 1 = Front Right

Index 2 = Rear Left

Index 3 = Rear Right

Index 4 = Spare Wheel

READ-ONLY TirePPerWhl1 P1 FIXED-SIZE 5 ``` 数组 DataType 的 BlueprintMapping 如下面的 XML 片段所示： ```xml TirePPerWhl1 TirePPerWhl1 ``` 描述根据 9.2.5 节进行解析。 #### 9.7.4 Record Types > 图 80：sheet 11_DataTypes_Record 的结构 与枚举类型一样，具有相同记录类型名称的所有连续行都包含在一个记录类型中，每个记录元素占一行。 ```xml DiagcLock1 Diagnostic Lock Diagnostic of the status of the locking. States if the lock is working or not. STRUCTURE READ-ONLY Lock LockActvn1 Diagc OnOff1 ``` BlueprintMapping for Record Data Type 如下所示： ```xml DiagcLock1 DiagcLock1 ``` 描述根据 9.2.5 节进行解析。 #### 9.7.5 Float Types Float 表示的数据类型定义如下： ```xml T6 Temperature 6 Generic data type for temperature VALUE

Examples for usage: glow plugs temperature, oil temperature, environment temperature, temperature differences Remark: use for floating point implementation

READ-ONLY KelvinIdentcl FloatDatarange 0.0000001 Kelvin ``` ### 9.8 Units > 图 81：sheet 13_Units 的结构 单位属于包 /AUTOSAR/AISpecification/Units。生成的 XML 直接从表条目派生，如下例所示。物理维度也在 XML 中生成并引用到相关单位。物理维度的短名称根据以下规则派生： - 使用现有的关键字缩写 - I 表示电流 - Cd 表示发光强度 - Ti 表示时间 - M 表示质量 - Mol 表示物质的量 - T 表示热力学温度 - Len 表示长度 - Neg 表示负值 短名称作为维度的串联创建。 长名称的构造类似于短名称，只是使用全词（例如：Length、Mass、Time、Amount of Substance 等）。负单位的长名称应使用 '-' 代替 Negative。 对于无量纲单位，将使用 PhysicalDimension "NoDimension"。 ```xml KiloGr Kilo Gram SI base unit of mass kg 1 M1 ``` 单位 KiloGr 引用物理维度 M1，在 XML 中表示如下： ```xml M1 Mass 1 1 ``` ### 9.9 Life Cycle State 生命周期信息在 AI excel 表的"Life Cycle State"列中添加，如下所示，以及要使用的替代项和过期日期。 > 图 82：Excel 表中的生命周期状态定义 这些元素在 AI 表中的生命周期状态在 XML 文件 `AUTOSAR_MOD_AISpecification_Standard_LifeCycle.arxml` 中输出。 在 LifeCycleInfoSets 下的相应类别下，每个模型元素应有一个 Life Cycle info set。每个类别下的 Obsolete 元素被标记为 `Obslt`（例如 KeywordObslt、ApplDataTypObslt、DataConstrObslt、CompuMethodObslt、PortIfObslt、PortPrototypeBlueprintObslt）。 XML 生成器识别拼写 "obsolete" 和 "Obsolete"，DEFAULT-LC-STATE-REF 指向 "obsolete"，如下所示。 对于上述示例，PortPrototype 元素 EngSpdGrdt 在 BASE "PortPrototypeBlueprints" 下设置为 Obsolete，如下面的 XML 摘录所示。PERIOD-BEGIN 用于描述元素的过期日期（在本例中为 R4.1.1），即相应元素首次设置为"obsolete"的第一个 AUTOSAR 版本。 Comment 和 Use Instead 列分别转换为 XML 描述中的 REMARK 和 USE-INSTEAD 部分。 ```xml EN English AUTOSAR AUTOSAR AISpecification LifeCycleInfoSets STANDARD PortPrototypeBlueprintObslt AutosarLifeCycleStates/obsolete EngSpdGrdt 4.1.1

Port short names consolidation: receivers should use short name of providers.

 EngNGrdt AutosarLifeCycleStates ``` 类似地，其他元素（例如 PortInterfaces、Keywords 等）的生命周期状态也在 XML 中生成，并引用相应的 BASE。此外，DataConstrs 在 PrimitiveDataTypes 范围内处理。如果 CompuMethods 链接到过时的数据类型，则将其标记为过时。如果 PortPrototypeBlueprints 在 05_Sheets 中标记为过时，也将其标记为过时。标记为 Obsolete 的元素将不会出现在 Examples 包或 BlueprintMappings 中。 在某些情况下，属性 "Use Instead" 下可能有多个条目（参见下图）。 > 图 83：生命周期状态定义（多个条目） 对于这种情况，条目在 "Use Instead" 列中使用逗号 (,) 分隔。在上述示例中，关键字短名称 "Wind" 对于 "Windscreen" 渲染为 Obsolete，并且需要从 "Wind" 和 "Screen"（Scrn）的缩写分别构造。 相应的 XML 摘录结果如下： ```xml KeywordList/Wind 4.1.1

correction according naming rules, To use Windscreen, please build the short name of the keyword abbreviations of Wind and Screen.

 KeywordList/Wind1 KeywordList/Scrn ``` ### 9.10 Views 如"视图概念"一章所述，可以为模型元素添加视图信息。 要在 AI Excel 表中实现视图概念，向所有端口表（05* Sheets）和所有数据类型表添加一列。 视图应输出为 `AUTOSAR_MOD_AISpecification_Collection__Blueprint.arxml` 文件。 使用以下视图（ShortName/longName）： - Truck (Truck) - Body (Body) - Pt (Powertrain) - Chassis (Chassis) - OccptPedSfty (Occupant and Pedestrian Safety) - MmedTelmHmi (Multimedia Telematics and HMI) AI 表宏生成一个标记为 REF-ALL 的集合。此集合仅包含在 AI 表中为此视图指定的元素，即主要是 PortPrototypeBlueprints。 第二步将创建一个标记为 REF-NONE 的集合。因此，需要存储包含标记为 REF-ALL 的集合的生成的 ARXML 文件，并且需要运行其他自动化作业。它使用带属性 REF-ALL 的集合来构建带属性 REF-NONE 的集合。这意味着对于集合中包含的所有元素，如果尚未包含引用的元素，则也将添加引用的元素。 通过这种方式，将构建带属性 REF-NONE 的集合并将其放入同一 ARXML 文件中的同一包中。之后，新文件将再次存储回来。 REF-NONE 的集合包含指定属于此视图的所有元素以及所有派生元素，例如，如果 PortPrototypeBlueprint（DoorSts）属于某个视图，则此集合的相应 PortInterface、DataTypes 等也被列出。 视图的类别应为 "SET"，元素角色应为 "PART_OF_SUBSET"。 逗号分隔的视图列表将解析为列表中各个视图的条目。为每个视图，将创建一个 arxml 输出文件。 因此，XML 生成器输出如下： ```xml AISpecification Collections_Blueprint BLUEPRINT ….... Body SET REF-NONE PART_OF_SUBSET DoorSts DoorSts1 DoorSts1 DoorSts1 NoUnit NoDimension DoorSts1 ….. BodyRefAll SET REF-ALL PART_OF_SUBSET DoorSts ……….. ``` --- ## 10 参考文档 在本节中，列出了本文档中使用的参考文档。 ### 10.1 标准文档 - [1] Software Component Template（软件组件模板） - [2] Standardization Template（标准化模板） - [3] AUTOSAR XML schema（AUTOSAR XML 模式） - [4] Generic Structure Template（通用结构模板） - [5] Model Persistence Rules for XML（XML 的模型持久性规则） - [6] AI Specification（AI 规范） ### 10.2 辅助文档 - [7] AUTOSAR Metamodel（AUTOSAR 元模型） - [8] Application Interface table（AI Table）（应用接口表） - [9] SW-C and System Modeling Guide（SW-C 和系统建模指南） - [10] AUTOSAR Methodology（AUTOSAR 方法论） - [11] AUTOSAR domain explanation Body and Comfort（AUTOSAR 域解释 车身和舒适） - [12] AUTOSAR domain explanation Powertrain（AUTOSAR 域解释 动力总成） - [13] AUTOSAR domain explanation Chassis（AUTOSAR 域解释 底盘） - [14] AUTOSAR domain explanation Occupant and Pedestrian Safety（AUTOSAR 域解释 乘员与行人安全） - [15] AUTOSAR domain explanation Multimedia, Telematics, Human Machine Interface（AUTOSAR 域解释 多媒体、远程信息处理、人机界面） - [16] Unique Names for Documentation, Measurement and Calibration（用于文档、测量和标定的唯一名称） - [17] AUTOSAR Glossary（AUTOSAR 术语表） --- ## 翻译说明 本文档是 AUTOSAR 经典平台（CP）4.4.0 版本中关于应用接口（Application Interfaces）的用户指南（EXP）。文档详细描述了 AI 表（Excel 电子表格）的结构、其在 AUTOSAR 元模型中的表示、与 XML 输出之间的关系，以及向后兼容性、生命周期状态、视图概念等关键概念。翻译过程中： 1. **保留**：所有 API 标识符、模块缩写、协议名（CAN、LIN、BSW、RTE 等）、XML 模式标签、ARXML 元素名、元模型类名、文档标识符（如 AUTOSAR_EXP_AIUserGuide）。 2. **翻译**：所有章节标题、说明性文字、表格内容、图形标题。 3. **术语**：按照《翻译术语表》进行统一，如 BSW（基础软件）、RTE（运行时环境）、VFB（虚拟功能总线）、ECU（电子控制单元）、SWC（软件组件）等。 4. **格式**：将原文页脚和"X of 102"页码指示符合并到章节结构中，所有图表（Figure）以引用方式列出。 5. **代码块**：原文中的 XML 模式代码使用代码块保留，便于读者参考对照。 6. **特殊处理**：AUTOSAR 方框符 `⌈⌋` 用于标记需求条目（本文档中较少使用，主要用于报告性描述）。原文中"X of 102"等页码标识被移除。 7. **缩略语表**：将原文中的缩略语列表以 Markdown 表格形式呈现。