AUTOSAR_EXP_ARAComAPI.pdf的第4章笔记

为了理解AUTOSAR_EXP_ARAComAPI.pdf的第4章内容，生搬硬套的翻译了一把，准备先囫囵吞枣，再仔细理解。因为这些内容的理解也不是一时半会儿的。所以先放上来。

1.AUTOSAR_EXP_ARAComAPI.pdf的介绍

通常，阅读正式的规范并不是学习和理解某项技术的最简单的方法。对于AUTOSAR AP中的通信管理API (ara::com)来说尤其如此。因此，本文档不仅可作为Adaptive AP软件组件开发人员(他们将使用ara::com API与其他应用程序或服务组件进行交互)的切入点，也可作为Adaptive Platform产品供应商(他们将在其平台上实现ara::com API的optimizedIPCbinding)的切入点。我们强烈建议读者在进入相关SWS的正式细节之前将此文档作为阅读的手头文件。

4 Fundamentals

4.1 Proxy/Skeleton Architecture

如果你曾经从程序员的角度接触过中间件技术，那么Proxy/Skeleton架构的方法可能对你来说很熟悉。看看使用Proxy/Skeleton(有时甚至称为存根/框架)范例的中间件技术的数量，称之为“经典方法”是合理的。所以对于ara::com，我们也决定使用经典的 Proxy/Skeleton 架构。

该模式的基本思想是，从正式的服务定义中生成两个代码工件:

服务代理:从远程服务的服务消费者的角度来看，该代码是在代码级别上表示该服务的门面。在面向对象的语言绑定中，这通常是一个生成类的实例，它为服务提供的所有功能提供方法。因此，服务消费者端应用程序代码与这个本地facade进行交互，本地facade知道如何将这些调用传播到远程服务实现并返回。
服务框架:从根据服务定义提供功能的服务实现的角度来看，该代码是允许将服务实现连接到通信管理传输层的代码，以便分布式服务消费者可以联系服务实现。在面向对象的语言绑定中，这通常是生成的类的实例。通常，应用程序开发人员的服务实现通过子类关系与这个生成的类相连接。

因此，服务端应用程序通过实现生成的类的抽象方法或调用生成的类的方法来与AutoSar CM中间件进行交互。

4.2 Means of Communication

现在，我们已经讨论了Proxy/Skeleton体系结构，让我们继续讨论如何在Proxy/Skeleton之间进行通信。ara::com定义了四种不同的机制来在服务器和客户端之间进行通信

Methods
Events
Fields
Triggers

在使用这些机制之前，必须实例化服务，并且服务器必须向系统提供自己(OfferService())。然后，客户端需要使用代理( FindService() 或StartFindService())找到并连接到服务实例。

4.3 ara::com Event and Trigger based communication

当Client Application连接到服务器时，它可以订阅(subscribe())服务器提供的服务中的事件，如图4.2所示。

Figure4.2:ara::com eventbased communication

当事件数据可用时， Sever Application将事件数据发送( send())到CM中间件，通知所有订阅的Client Application。然后，订阅者可以使用 GetNewSamples()直接或通过由通知触发回调(由 SetReceiveHandler()定义)获取事件样本。特定条件下，服务器使用Trigger来通知用户何时获取事件样本。它不传输任何数据。它使用与事件相同的订阅-通知机制.

4.4 ara::com Method based communication

使用基于Method的通信，Client Application调用远程服务器上的Method。该Method可能会向客户端返回值。如果提供了返回值，ara::core::Future和ara::core::Promise模式用于为通信提供非阻塞行为。服务器可以针对方法调用的不同处理模式进行配置。这些选项包括:

事件驱动，并发(kEvent): 传入的服务方法调用以基于事件的方式处理。
事件驱动，顺序(kEventSingleThread):与单线程基础上的kEvent相同。
轮询(KPoll):传入的服务方法调用需要通过调用ProcessNextMethodCall以轮询方式进行显式处理。

4.5 ara::com Field based communication

通过基于Field的通信，服务器可以为一些数据（即：变量）提供值，客户端可以随时访问或更新这些值。Field的功能可以被视为事件和方法的组合:

像事件一样，客户端可以订阅值的变化。将使用与事件相同的通知机制通知客户端(由SetReceiveHandler()定义)。
使用方法，客户端可以通过调用get-operation (Get())来检索值，或者通过为代理中的字段调用Set-operation(Set())来更新值。

在服务器端，Field的处理在Skeleton实现中：

定义回调：当客户端更新值时调用回调(由RegisterSetHandler()定义)。
当需要向客户端发布新值时，调用更新方法(update())。

4.6 Data Type Abstractions

4.7 Error Handling

4.8 Service Connection Approach

4.8.1 Instance Identifiers and Instance Specifiers

在Proxy和Skeleton端使用的Instance Identifiers是一个非常重要的概念，所以在接下来的章节中，在详细描述ara::com的Proxy和Skeleton之前，在这里给出它们的解释。

在ara::com中，当在客户端/代理端需要搜索服务的特定实例时，或者在服务器/框架端创建服务的特定实例时，会使用Instance Identifiers。

在ara::com API级别，Instance Identifiers通常是特定于技术绑定的标识符。

因此，构成这种Instance Identifiers的具体内容/结构完全是技术特定的:

SOME/IP使用16位无符号整数标识符来区分同一服务类型的不同实例，而DDS (DDS-RPC)使用String< 256 >作为service_instance_name。

与绑定技术无关，任何具体Instance Identifiers的抽象外观都应适用于ara::com命名空间中ara::com API级别的签名:

class InstanceIdentifier 
{
public:
    static ara::core::Result<InstanceIdentifier> Create(StringView serializedFormat) noexcept;
    explicit InstanceIdentifier(ara::core::StringView serializedFormat);
    ara::core::StringView ToString() const;
    bool operator==(const InstanceIdentifier& other) const;
    bool operator<(const InstanceIdentifier& other) const;
    InstanceIdentifier& operator=(const InstanceIdentifier& other);
};

正如您所看到的，实例标识符接口ara::com::InstanceIdentifier,提供了一个接收字符串的ctor（代表构造函数），这意味着它可以由字符串表示来构造。它还提供了一个ToString()方法，该方法允许获取与ara::com::InstanceIdentifier的字符串。

这对接收字符串表示的ctor和写出字符串表示的可能性使得ara::com::InstanceIdentifier“可序列化”。这允许它被传输、保存、以后重用(稍后将详细介绍潜在的使用案例)。

对于ara::com的用户来说，反省这个字符串(试图解释内容)是没有意义的。如上所述:内容将高度特定于中间件产品/绑定！

由于基于ara::com的应用程序所使用的技术绑定是由集成商在部署期间定义/指定的，因此ara::com软件开发商对其内容/结构的任何期望通常都是无效的。然而，将它记录/跟踪到日志通道可能有助于调试分析。

那么，软件开发人员从哪里得到这样一个高度绑定的ara::com::InstanceIdentifier来用于ara::com API调用呢？

答案是:通过ara::com提供的功能，该功能将软件开发人员在其领域中通常使用的逻辑本地名称转换为特定于技术/绑定的ara::com::InstanceIdentifier。这种间接控制了两种挑战:

使用ara::com的开发人员不需要了解任何关于绑定及其细节的知识
集成商可以在部署中调整绑定

构造ara::com::InstanceIdentifier的本地名称基本上来自AUTOSAR元模型(描述软件组件模型)。对这个本地名称的要求——从现在开始我们称之为“instance specifier”——是它在可执行文件中是明确的。它的基本形式是:

 <context 0>/<context 1>/ ... / <context N> / <port name>

这种“instance specifier”的C++表示是ara::core::InstanceSpecifier类。从结构上看，它类似于ara::com::InstanceIdentifier:

class InstanceSpecifier final
{
public:
// ctor to build specifier from AUTOSAR short name identifier
// with ’/’ as separator between package names
static Result<InstanceSpecifier> Create(StringView metaModelIdentifier);
explicit InstanceSpecifier(StringView metaModelIdentifier);
InstanceSpecifier(const InstanceSpecifier& other);
InstanceSpecifier(InstanceSpecifier&& other) noexcept;
 InstanceSpecifier& operator=(const InstanceSpecifier& other);
 InstanceSpecifier& operator=(InstanceSpecifier&& other);
 ~InstanceSpecifier() noexcept;
 StringView ToString() const noexcept;
 bool operator==(const InstanceSpecifier& other) const noexcept;
 bool operator==(StringView other) const noexcept;
 bool operator!=(const InstanceSpecifier& other) const noexcept;
 bool operator!=(StringView other) const noexcept;
 bool operator<(const InstanceSpecifier& other) const noexcept;
 };

如果确保了明确性，集成者/部署者可以通过“manifest file”将具有其特定实例id的专用技术绑定分配给那些“实例说明符”，该“manifest file”专门用于Executable的不同实例化/执行。这显式地允许N次启动同一个Executable，每次使用不同的“manifest file”，以不同的方式映射同一个ara::core::InstanceSpecifier。关于ara::com与元模型的关系以及嵌套内容的性质的细节可以在后续章节中读到。API ara::com提供了以下函数，用于将ara::core::InstanceSpecifier(软件开发人员领域中的本地名称)转换为技术ara::com::InstanceIdentifier:

namespace ara {
 namespace com {
 namespace runtime {
 ara::core::Result<ara::com::InstanceIdentifierContainer> ResolveInstanceIDs
 (ara::core::InstanceSpecifier modelName);
 }
 }
 }

为什么这个API确实会返回一个ara::com::InstanceIdentifier container，它代表一个ara::com::InstanceIdentifier的集合, 需要解释一下: AUTOSAR支持集成人员可以在一个软件组件开发者可见的抽象标识符后面配置多个技术绑定。这种特性称为多重绑定，在本文档的不同部分都有提及(在AUTOSAR_EXP_ARAComAPI.pdf 7.3节中有更详细的解释)。在Skeleton/Server端使用多重绑定是一个常见的用例，因为它只是允许不同的客户机在联系服务器时使用它们的首选绑定。相反，在Proxy/Client使用多重绑定是一种非常奇特的方法。例如，它可以用于支持一些故障转移方法(如果绑定A不起作用，则求助于绑定B)。

因此，调用ResolveInstanceIDs()的可能结果是:

空列表:集成器未能提供抽象标识符的映射。这很可能是配置错误。

单元素列表:常见案例，映射到一个具体技术绑定的一个具体实例id。

多元素的列表:映射到可能具有多个技术绑定的多个技术实例。

从技术上讲，ResolveInstanceIDs()的中间件实现从捆绑在Process中的service instance manifest中查找ara::core::InstanceSpecifier。因此，ara::core::InstanceSpecifier在捆绑的service instance manifest中必须是明确的。

4.8.2 When to use InstanceIdentifier versus InstanceSpecifier

根据前面的解释，可能会产生这样的印象:在使用需要InstanceIdentifier 信息的ara::com API之前，软件开发人员总是必须首先手动(通过调用ResolveInstanceIDs())将ara::core::InstanceSpecifier解析为ara::com::InstanceIdentifier。正如我们已经提到的，对于软件开发人员来说，AutoSar AP SWC的“典型”方法是使用来自软件组件模型领域的抽象“instance specifiers”,这确实有点尴尬。正如您将在接下来的章节中看到的，这些章节详细介绍了Proxy/Skeleton端的API，ara::com提供了典型的函数重载，这些重载要么采用ara::com::InstanceIdentifier，要么采用ara::core::InstanceSpecifier，从而使开发人员在最常见的用例中解放出来，只需使用ara::core::InstanceSpecifier就可以显式调用ResolveInstanceIDs() 。这意味着，ara::com::InstanceIdentifier的直接使用和ara::core::InstanceSpecifier的手动解析更适用于具有特定/特殊用例的高级用户。各章中将给出一些例子，其中讨论了代理/框架端的相应ara::com API重载。这两种变体的根本区别是ara::com::InstanceIdentifier可以更容易地在AP应用程序/进程之间交换！

因为它们已经准确地包含了所有特定于技术的信息，并且不需要通过service instance manifest的内容进行任何进一步的解析，所以这种序列化的ara::com::InstanceIdentifier可以在不同的进程中重新构建，并且只要该进程能够访问ara::com::InstanceIdentifier所基于的相同绑定技术，就可以使用它。

4.8.2.1 Transfer of an InstanceIdentifier

如前所述，ara::com::InstanceIdentifier应该只用于“高级用户”,因为它的格式依赖于供应商，并且包含技术绑定信息。因此，ara::com::InstanceIdentifier的传输或存储可能非常危险。因为在传输或重新存储之后传输绑定可能不再存在，或者供应商A的ara::com::instance标识符可能被使用供应商B的应用程序解释.