AUTOSAR_EXP_ARAComAPI的7章笔记（6）

☞返回总目录

相关总结：ara::com 与 AUTOSAR 元模型的关系总结

7.4 ara::com 与 AUTOSAR 元模型的关系

在本文档中，我们一直在不涉及具体的AP元模型（其清单部分）的情况下解释 ara::com API的思想和机制，AP元模型是正式描述服务接口签名（以及部分行为）的基础，而从这个签名中生成了像代理类和骨架类这样的ara::com API 工件以及通信中使用的数据类型。在 5.1 中，我们甚至引入了一个过于简化的IDL，只是为了让读者免受真实元模型/IDL 的复杂性的影响。

本章绝不是对 AUTOSAR元模型的全面解释，AUTOSAR元模型在其自己的文档中有完整的描述，但它将阐明 ara::com 与 [2：AUTOSAR_TPS_ManifestSpecification] 中描述的元模型部分之间的关系。所以请记住，以下部分仍然是比较高层次的，并试图对这种关系提供一个基本的理解。

7.4.1 与 AUTOSAR_TR_AdaptiveMethodology 的关联

建模元素概述以及它们如何相互关联：服务接口、部署、实际生成取决于提供的部署信息（例如，稍后将生成的服务接口元素以及与服务实例清单的连接）。

AUTOSAR 自适应平台方法学解释了构建自适应 AUTOSAR系统所需的过程方面以及它们如何相互关联 [TR_AMETH_00100]。它定义了交付或使用的活动和工作产品 [TR_AMETH_00102] 以及由原始设备制造商和供应商执行的角色。

AP软件开发的主要步骤包括：

架构和设计。
AP软件开发。
集成和部署。

AP应用程序在ARA层之上运行，并使用服务接口和端口交换信息。AP方法学的集成和部署步骤对ara::com API的工作贡献重要。它支持生成服务接口描述 ARXML文件，该文件聚合了服务接口和端口。面向服务通信的服务接口由事件、方法和字段定义，这是独立于底层通信的软件组件或传输层完成的。

AP平台支持两种类型的端口，即提供端口和所需端口。提供端口细节和服务接口用于生成服务骨架类，所需端口细节和服务接口用于生成代理类。代理类和骨架类使用 ara::com API 与其他AP平台集群和AP应用程序进行通信。

服务实例会进行配置，尤其是将服务实例绑定到选定的传输层，确定某个具体的服务实例是提供服务还是需要服务，以及是否有到特定机器的映射关系。服务实例的配置情况会在服务实例清单中体现出来。

自适应软件的Executable通过执行清单来进行实例化。这里的实例化指的是将Executable绑定到操作系统特定进程的上下文环境中。根据机器模式的不同，每个进程可能会以不同的启动配置来启动。此外，执行清单还定义了软件进程之间的依赖关系。

7.4.2 服务接口

从ara::com的角度来看，最重要的元模型元素是服务接口（SI），因为它从签名方面定义了 ara::com代理或骨架。服务接口描述了一个服务接口由哪些方法、字段和事件组成，以及这些元素的签名（参数和数据类型）是什么样子。所以，5.1 基本上是元模型服务接口和真实元模型数据类型系统的简化。

元模型元素服务接口与 ara::com 之间的关系很清楚：ara::com的代理类和骨架类是从服务接口生成的。

7.4.3 软件组件

AUTOSAR方法论定义了一个比接口更高层次的元素，就是软件组件。软件组件的理念是用定义良好的接口描述一个可重用的软件部分。为此，AUTOSAR清单规范定义了一个模型元素 SoftwareComponentType，它是一个抽象元素，有几个具体的子类型，其中子类型 AdaptiveApplicationSwComponentType对于AP应用软件开发人员来说是最重要的。一个 SoftwareComponentType 模型元素由 C++代码实现。这样一个组件 “向外部提供” 或 “从外部需要” 哪些服务接口是通过端口来表达的。端口由服务接口进行类型化。提供端口（P-ports）表示类型化该端口的服务接口是被提供的，而所需端口（R-ports）表示类型化该端口的服务接口是被 SoftwareComponentType所需要的。

图 7.6 给出了一个大致的概念，即模型视图如何与代码实现相关联。

图的上部分表示两种不同软件组件类型A和B（元模型层面），在实现层面（图的下部分）存在具体的实现。软件组件类型A的所需端口（R-Port）的实现基于实现层面上的ara::com代理类的一个实例，而软件组件类型B的提供端口（P-Port）的实现则使用ara::com骨架类的一个实例。代理类和骨架类是从服务接口定义生成的，相应的端口引用了这个服务接口，例子中，它是我们一直使用的服务接口 “RadarService”。

SoftwareComponentType实现的代码片段显然可以被重用。AdaptiveApplicationSwComponentType的实现，在C++实现层面上，通常归结为一个或几个 C++的类。所以，重用仅仅意味着在不同的上下文中多次实例化这个类或这些类。在这里，我们基本上可以区分以下情况：

在代码中显式地多次实例化C++类。
通过多次启动 / 运行同一个Executable进行隐式地多次实例化。

第一种情况仍然属于 “实现层面” 的范畴。

上图展示了一个示例，其中 A 和 B 的实现被实例化在不同的上下文中。左下角有一个Executable 1，它直接使用了两个 A的实现实例和一个B的实现实例。与此相反，右侧展示了一个Executable 2，它 “直接”（即在其最顶层）使用了一个B的实现实例和一个复合软件组件的实例，而这个复合软件组件自身 “在其内部” 又实例化了一个A的实现实例和一个B的实现实例。注意：这种从其他组件组成软件组件以形成复合品的自然实现概念在 AUTOSAR元模型中以组合软件组件类型（CompositionSwComponentType）的形式得到了充分体现，它本身就是一个软件组件类型，并允许软件组件的任意递归嵌套 / 组合。

另一方面，第二种情况属于 “部署层面” 的范畴，并将在下面的子章节中进行说明。

7.4.4 AP应用程序/Executable和进程

AP 中的可部署软件单元被称为AP应用程序（相应的元模型元素是 AdaptiveAutosarApplication）。这样一个AP应用程序由 1 ~ n 个Executable组成，而Executable又是通过CompositionSwComponentType（具有任意嵌套）的实例化构建而成，如前一章所述。通常，集成商然后决定到底启动哪些AP应用程序（以其 1 ~ n 个Executable的形式）以及启动某个AP应用程序/其相关Executable的次数。这意味着这种隐式实例化，不需要编写特定的代码！而是需要集成商必须处理机器配置，以配置应用程序的启动次数。一个启动的AP应用程序然后会变成 1 个到 n 个进程（取决于它由多少个Executable组成）。我们将此称为 “部署层面”。

上图展示了一个简单的例子，其中有两个 AP 应用程序，每个应用程序恰好由一个 Executable 组成。具有 Executable1 的 AP 应用程序 1 被部署两次，在 Executable 启动后启动进程 1 和进程 2，而由 Executable2 组成的应用程序 2 被部署一次，在启动后启动进程 3。

7.4.5 基于 ara::com 的应用程序代码中使用元模型标识符

到目前为止对元模型 /ara::com 关系的解释应该有助于理解在 4.3 中描述的 ResolveInstanceIDs 中使用的 instance specifier 的结构。如前一章所述并在图 7.6 中描绘的那样，instance specifier 以某种方式与 SoftwareComponentType 模型中的相应端口相关联。如果你阅读了前面的章节，仅模型的端口名称不足以在其最终实例化中明确地识别它，因为相同的组件实现可能在代码中被多次实例化，然后最终在不同的进程中多次启动。实例 ID 显然必须分配给对象，这些对象在部署中最终具有独特的标识。

上图用一个简单的例子概述了 “问题”。在Executable 2 中，在不同的上下文中（嵌套级别）有三个SoftwareComponentTypeB 实现的实例化。所有实例都提供了一个特定的服务接口 “RadarService” 实例。应用于进程 2 的服务实例清单的集成商必须在 ara::com级别上进行技术映射。也就是说，他必须决定在每个 B实例化中使用哪种技术传输绑定，以及随后的哪种技术传输绑定特定实例ID。在我们的例子中，集成商希望在右侧嵌套在复合组件中的 B实例化的上下文中通过 SOME/IP 绑定提供服务接口 “RadarService”，并使用 SOME/IP 特定实例 ID “1”，而他决定在左侧的 B 实例化的上下文中通过本地 IPC（Unix 域套接字）绑定提供服务接口 “RadarService”，并使用 Unix 域套接字特定实例 ID“/tmp/Radar/3” 和 “/tmp/Radar/4”，这些 B实例化没有嵌套（它们在Executable的 “顶层” 实例化）。在这里很明显，在服务实例清单中，它允许指定进程内的端口实例化到技术绑定及其具体实例ID 的映射，仅使用来自模型的端口名称是不够区分的。为了在Executable（以及因此在进程中）获得唯一标识符，必须考虑SoftwareComponentType的嵌套实例化和重用的性质。每次SoftwareComponentType被实例化时，它的实例化在其实例化上下文中都会获得一个唯一的名称。这个概念适用于 C++ 实现级别和 AUTOSAR元模型级别！

在我们的具体例子中，这意味着：

顶层的B实例化在其级别上获得唯一名称：“B_Inst_1” 和 “B_Inst_2”。
复合组件类型内的B实例化在这个级别上获得唯一名称：“B_Inst_1”。
顶层的复合组件实例化在其级别上获得唯一名称：“Comp_Inst_1”。
从Executable /进程的角度来看，我们因此对B的所有实例都有唯一标识符：
- “B_Inst_1”。
- “B_Inst_2”。
- “Comp_Inst_1::B_Inst_1”。

对于AP软件组件开发人员来说，这意味着：如果你构建一个实例说明符并通过ResolveInstanceIDs()将其转换为 ara::com::InstanceIdentifier，或者直接与 FindService ()一起使用（R端口），或者作为骨架的构造函数参数而使用（P端口），那么实例说明符的形式应该是这样的：

< 上下文标识符 >/< 端口名称 >

端口名称从AdaptiveApplicationSwComponentType的模型中获取。由于你不一定是决定你的组件在哪里以及部署多少次的人，你应该预见到，你的AdaptiveApplicationSwComponentType实现可以接收一个字符串化的 <上下文标识符>，你可以：

在构建ara::core::InstanceSpecifier 以实例化反映你自己的组件端口的代理/骨架时直接使用它。
“传递” 给从你自己的AdaptiveApplicationSwComponentType实现中实例化的其他AdaptiveApplicationSwComponentType实现（即创建一个新的嵌套级别）。

注意：由于 AUTOSAR AP 没有规定元模型级别的组件模型应如何转换为（C++）实现级别、组件实例化（组件的嵌套）以及 <上下文标识符> 的 “传递”，这取决于实现者！对于可多次实例化的AdaptiveApplicationSwComponentType，通过一个 <上下文标识符>构造函数参数来解决这个问题可能是一个 “自然” 的解决方案。