AUTOSAR_EXP_ARAComAPI.pdf的第4章笔记

2024-08-25 04:04
文章标签 笔记 pdf autosar exp aracomapi

本文主要是介绍AUTOSAR_EXP_ARAComAPI.pdf的第4章笔记，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

4 Fundamentals

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

AUTOSAR_EXP_ARAComAPI.pdf的概述

因此，ara::com不提供任何类型的组件模型或框架，这些模型或框架将负责组件生命周期、程序流管理或根据相应应用程序的正式组件描述简单地设置ara::com API对象。所有这些都可以很容易地构建在基本的ara::com API之上，并且不需要标准化来支持典型的协作模型。 在API的设计阶段，我们不断质疑我们草案的每一部分，它是否允许来自AP供应商的高效IPC实现，因为我们知道，您可以很容易地在API抽象级别上破坏它，这使得很难或几乎不可能实现性能良好的绑定。 中心设计点之一是——如导言中所述——同样支持轮询和事件驱动编程范例。 因此，您将在后面的章节中看到，应用程序开发人员在使用ara::com时，可以自由选择最适合其应用程序设计的方法，而与他是实现通信关系的服务消费者还是服务提供者无关。 这允许支持严格实时调度的应用程序，其中应用程序需要完全控制在何时何地做什么(量),不必要的上下文切换是最关键的。 另一方面，也完全支持更宽松的基于事件的应用程序，只要通信层有数据可用，这些应用程序就会收到通知。 AUTOSAR决定真正支持C++11/C++14 for AP非常适合ara::com API设计。 为了增强可用性、舒适性和优雅，ara::com API利用了C++的一些特性，如智能指针、模板函数和类、异步操作的成熟概念以及合理的操作符重载。

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的应用程序解释.

这篇关于AUTOSAR_EXP_ARAComAPI.pdf的第4章笔记的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/1104486。

相关文章

Python实现合并与拆分多个PDF文档中的指定页

Python实现合并与拆分多个PDF文档中的指定页

《Python实现合并与拆分多个PDF文档中的指定页》这篇文章主要为大家详细介绍了如何使用Python实现将多个PDF文档中的指定页合并生成新的PDF以及拆分PDF,感兴趣的小伙伴可以参考一下... 安装所需要的库pip install PyPDF2 -i https://pypi.tuna.tsingh
阅读更多...
Python实现PDF与多种图片格式之间互转(PNG, JPG, BMP, EMF, SVG)

Python实现PDF与多种图片格式之间互转(PNG, JPG, BMP, EMF, SVG)

《Python实现PDF与多种图片格式之间互转(PNG,JPG,BMP,EMF,SVG)》PDF和图片是我们日常生活和工作中常用的文件格式,有时候,我们可能需要将PDF和图片进行格式互转来满足... 目录一、介绍二、安装python库三、Python实现多种图片格式转PDF1、单张图片转换为PDF2、多张图
阅读更多...
java导出pdf文件的详细实现方法

java导出pdf文件的详细实现方法

《java导出pdf文件的详细实现方法》：本文主要介绍java导出pdf文件的详细实现方法,包括制作模板、获取中文字体文件、实现后端服务以及前端发起请求并生成下载链接,需要的朋友可以参考下... 目录使用注意点包含内容1、制作pdf模板2、获取pdf导出中文需要的文件3、实现4、前端发起请求并生成下载链接使
阅读更多...
基于Python开发PDF转PNG的可视化工具

基于Python开发PDF转PNG的可视化工具

《基于Python开发PDF转PNG的可视化工具》在数字文档处理领域,PDF到图像格式的转换是常见需求,本文介绍如何利用Python的PyMuPDF库和Tkinter框架开发一个带图形界面的PDF转P... 目录一、引言二、功能特性三、技术架构1. 技术栈组成2. 系统架构javascript设计3.效果图
阅读更多...
基于Python实现一个PDF特殊字体提取工具

基于Python实现一个PDF特殊字体提取工具

《基于Python实现一个PDF特殊字体提取工具》在PDF文档处理场景中,我们常常需要针对特定格式的文本内容进行提取分析,本文介绍的PDF特殊字体提取器是一款基于Python开发的桌面应用程序感兴趣的... 目录一、应用背景与功能概述二、技术架构与核心组件2.1 技术选型2.2 系统架构三、核心功能实现解析
阅读更多...
基于Python开发PDF转Doc格式小程序

基于Python开发PDF转Doc格式小程序

《基于Python开发PDF转Doc格式小程序》这篇文章主要为大家详细介绍了如何基于Python开发PDF转Doc格式小程序,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起学习一下... 用python实现PDF转Doc格式小程序以下是一个使用Python实现PDF转DOC格式的GUI程序，采用T
阅读更多...
使用Python创建一个能够筛选文件的PDF合并工具

使用Python创建一个能够筛选文件的PDF合并工具

《使用Python创建一个能够筛选文件的PDF合并工具》这篇文章主要为大家详细介绍了如何使用Python创建一个能够筛选文件的PDF合并工具,文中的示例代码讲解详细,感兴趣的小伙伴可以了解下... 目录背景主要功能全部代码代码解析1. 初始化 wx.Frame 窗口2. 创建工具栏3. 创建布局和界面控件4
阅读更多...
Python进行PDF文件拆分的示例详解

Python进行PDF文件拆分的示例详解

《Python进行PDF文件拆分的示例详解》在日常生活中,我们常常会遇到大型的PDF文件,难以发送,将PDF拆分成多个小文件是一个实用的解决方案,下面我们就来看看如何使用Python实现PDF文件拆分... 目录使用工具将PDF按页数拆分将PDF的每一页拆分为单独的文件将PDF按指定页数拆分根据页码范围拆分
阅读更多...
Python如何实现PDF隐私信息检测

Python如何实现PDF隐私信息检测

《Python如何实现PDF隐私信息检测》随着越来越多的个人信息以电子形式存储和传输,确保这些信息的安全至关重要,本文将介绍如何使用Python检测PDF文件中的隐私信息,需要的可以参考下... 目录项目背景技术栈代码解析功能说明运行结php果在当今，数据隐私保护变得尤为重要。随着越来越多的个人信息以电子形
阅读更多...
使用Python实现批量分割PDF文件

使用Python实现批量分割PDF文件

《使用Python实现批量分割PDF文件》这篇文章主要为大家详细介绍了如何使用Python进行批量分割PDF文件功能,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起学习一下... 目录一、架构设计二、代码实现三、批量分割PDF文件四、总结本文将介绍如何使用python进js行批量分割PDF文件的方法
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2